Scrum Gathering 2012 Notes

I used to attend Agile and quality related conferences years ago and have saved notes from many of them. While some topics have become overtaken by events since then, there still seem to be some useful ideas that I’d like to pass along.

Keynote — Clarke Ching

Ching declared Agile to be a “progress-driven” development approach. By this, he meant assessing development work through the XP approach of have a test run be red (it fails because the code isn’t there yet), then testing with the code working (“green”) with both using a traffic light metaphor. Next, refactor to achieve the best design result. All of this means lots of frequent meaningful progress.

He also said that likely less than 5% of development teams know the revenue [or savings] their work brings. [I view this in today’s terms as not really knowing the value proposition for their work.]

Product Owner Role — Bob Galen

The team should feel responsible to delight the customer from the inside out.

Galen said the Product Owner role can be done by many standard “roles”: Product Manager, BA, leader, Project Manager. They are, however, a singular voice for the team, though multiple people can “help” with the PO responsibilities.

Galen also addressed the question of “Is the PO part of the Team” and said they should be as defined in Scrum.

Regarding the levels of stories in the backlog, he said 20% should be proper stories (“are we ready”, table), 30% can be epics (“are we getting clearer”, refrigerator), and 50% are themes (“what’s the future look like”, freezer).

Galen advocated having planned backlog “grooming” (1 hour?) each week to reduce planning meeting length, but still getting strong results. He did say nthat teams ahould be expected to estimate a story if it did not have Conditions of Satisfaction or Done criteria. And he viewed the Definition of Done as part of the development DNA which (new) people learn through working with others, not [just] because it is written [and] on the wall.

Keynote — Tanner Corbridge

Corbridge suggested there is a problem of externalizing change, that is, we see a need for change seen others, not ourselves. This can be manifested by an emphasis on “my job” and its activities rather than a sense of accountability for achieving overall results. In this way, people get sucked into the daily minutiae of the job. Results focus is forward looking whereas asking “Who’s accountable for achieving; Who’s responsible for failing to achieve” is backward looking.

Regarding motivation and culture he mentioned a few things:

· People will work hard for $, harder for a leader, hardest for a cause

· When results are not happening, go to the plan, but culture eats strategy for lunch and always wins

· Shift belief by changing experience

· What are the beliefs on your team? In your company?

· People self-select actions based on beliefs

Dysfunctions of a Team — James Scrimshire

Used Zombie Apocalypse video game with four players to observe what happens and what is learned about interaction:

· Absence of trust — unwillingness to appear vulnerable; reliance on a person maybe not the same as trust [human pyramid with one person off to the side with hands up as if saying No and ducking a bit]

· Fear of conflict — can’t get to healthy debate; not just professional courtesy [hands up warding off, backing off from a fight]

· Lack of commitment — feigning buy-in rather than real support for decision (even if you have doubt) [lag behind as others move forward]

· Inattention to results — rock star mentality, did “my” job [on a pedestal with others below]

· Avoidance of responsibility — [two people in back of boat, one person steering, sharks and iceberg ahead]

Keynote — James Grenning

Demand technical excellence, e.g., fix what’s wrong after 2 times or you are out (air force pilot training).

Sequential workflow is structured to produce bugs — debug later programming

As Td (time developing) increases, so do Tfind and Tfix (defects); as Td approaches 0, so do Tfind and Tfix.

Get good at being careful, then you can get good at being fast.

Anyone can write code the compiler understands, but only good programmers can write code that other people can understand.

There’s no optional scope, until we’re late.

Developer ToDo:

(1) become and expect in your craft;

(2) be willing to learn and try new things;

(3) become an advisor to your organization;

(4) make things visible.

Reflect; take ownership for your skills

ScrumMaster ToDo:

(1) make sure your team knows the state-of-the-art practices;

(2) encourage people to be problem-solvers, not dogma followers

Management ToDo:

(1) Don’t try to motivate teams, try to avoid demotivating them.

(2) Motivation is hard; demotivation is easy.

[Change comes from some level of dissatisfaction — what are people dissatisfied with? If nothing, why should they can about change?]

Story Splitting — Chris Sims

As a <WHO>, I want <WHAT>, so that <WHY>.

By linguistic conjunctions/connectors (including commas and other punctuation)

By generic words, i.e., collective nouns (base vs derived classes), maybe verbs

By acceptance criteria

By time line analysis (talk about sequence of events in actual use of the feature, i.e., the workflow) [maybe use cases]