Software Engineering Thoughts

[A very short post today. May be a few days before I organize some older ideas for future posts.]

I ran across these while looking at some older article ideas. I’ve listed the sources for most of them, but did not have them for the first two.

The Product Owner should (be allowed to) act like a real team member, e.g., at daily meetings and retrospectives.

What do we need to have trust in technology, people, process? Then what do we need to have trust in the software that these three, in combination, produce?

Regarding trying to teach software engineering ideas in a classroom setting: “Many problems don’t manifest themselves until the scale of the software project reaches a certain level, making it difficult to convince the student of the importance of the teaching (or to even comprehend the teaching, for that matter).” (The Software Practitioner, 1991)

“The question of whether computers can think is no more interesting than the question of whether submarines can swim.” (Edsger Dijkstra)

Tricia Broderick, “How Healthy Conflict Goes Wrong”

· “No conflict means no collaboration” and discovery (work) needs collaboration.

· Drama vs conflict — do people use the same words for both?

· In drama: the persecutor wants something resolved but phrases it as “It’s your fault.”; the victim wants to succeed but feels “it’s not fair”; the rescuer wants to help but may seem like “sneaky behavior.”

· People may switch roles and not acknowledge them which generates drama. (from Dr. Cartman (sp?)) so engage conflict before switching starts (step back and coach).

· Recognize what you agree on (where’s your 2% truth), then embrace differences.

Richard Lawrence — Backlog refinement ideas:

· Every backlog item should represent an increment of value for the customer.

· Goldilocks detail — just right; progressive elaboration as items move up the backlog.

· Don’t do refinement in iteration planning as that is too late.

· Refinement as a “meeting,” but it’s the POs job and they collaborate with others just as developers collaborate with others.

· Estimation is a whole team refinement activity.

· View acceptance criteria as a contract, but also expect things to emerge.

· Avoid the illusion of certainty based on what is known.

· Have enough details to start; not enough to finish.