Sunday, January 15, 2012

Agile Training with Mike DePaoli from VersionOne

Last week I attended a two day workshop with Michael DePaoli on agile processes. It was very enlightening and we were lucky to have such a great speaker.

Here is my partially organized brain dump of the concepts that stuck with me from my notes. It will be interesting to see how some of the concepts might be incorporated in my current work environment and what the effects will be. Thumbs up to continuous improvement and re-factoring!

Process Overview
Typical daily scrum questions:

  • What did I learn?
  • What am I going to learn?
  • What are the impediments?

The goal is to remove impediments and keep forward momentum going.

Agile Lifecycle
Key agile points:

  • individuals and interaction over processes & tools
  • working software over comprehensive docs
  • customer collaboration over contract negotiation
  • responding to change over following a plan

While there is value to the items on the right, put higher value to the underlined items on the left.

Management and Leadership
Agile leadership must learn to manage teams and coach individuals.

The kaizen process ("good change") from Toyota, shows how many small changes amount to big change without evoking a fear response.

Don't be fooled by a waterfall process within an iteration. (A "scrumfall" or "wateration".)

Expose problems as soon as possible to give product owners the maximum number of choices for how to react.

Reactionary behavior is a handicap of corporate America.

Learn what it means to be a "servant leader".

Facilitative management role is not done by review, rather by actively observing teams and helping remove impediments.

Task Estimation
An estimate involves a range. A single value/date is a commitment.

Agile estimation drives down cost.

Important to have team agree on the reference example during the sprint planning process to start the relative estimation process of other tasks. It is much like a keystone, which should not be updated since other tasks will be estimated in relation to this entity.

Identify assumptions and boundaries for which task estimates are based on.

Estimates should not be in days. Use T-shirt sizes or fibonacci numbers for your estimates, to reinforce that these numbers are estimates.

Problem-solving
The marshmallow challenge taught us to prove key assumptions as soon as possible. Check out Tom Wujec's TED talk about the challenge.
  • remember the objective
  • become familiar with the materials
Think about the challenge as it relates to gathering requirements.

Learn the power of the intuitive mind for problem solving and estimation.

Team
As soon as you assign blame you stop learning.

Team cadence should be kept regular, but not set in stone. The general rule is to work to get the cadence smaller and always keep it consistent.

A self-organizing team does their own resource leveling. The highest definition of this is that the team can overcome obstacles and reach agreement through conflict. This is a high performing "team smell". Take tasks based on importance and priority.

The team has to honor the process throughout. If it is not working analyze, change, modify, but don't give up what you've started.

Meetings
The daily stand-up is about re-planning based in what is known TODAY. Stand-up meetings are not for problem solving, but rather problem identifying. The daily stand-up meeting is the way to implement active issue management.

During the sprint retrospective inspect the process, not the people.

Agile Tips
Velocity defined: Stabilized number of estimation units a team can accomplish with a high value, that can be marked as being done. Velocity should be averaged based on the team over a number of sprints and also takes into account capacity.

Velocity is observed. Team capacity changes and is flushed out during sprint planning, which then affects the velocity.
  • size (complexity) is estimated
  • velocity is measured
  • duration is forecast
Then enemy of predictability is variability. Add buffers to remain predictable.

Burndown - how much work do we have left?
Cumulative flow - how much value have we delivered?

A burn-down chart can be analyzed for trends:
  • how many hours remain on tasks
  • what has changed
  • who needs help
The easiest lowest cost way of dealing with defects is to fix them when found, in the current sprint and take out a similar sized lower priority task. This reduced technical debt.

Focus of the agile process isn't starting new work, it is about finishing what was begun.

Mnemonic for writing good stories:
  • Specific
  • Measurable - can we mark it as done
  • Achievable - task needs to be do-able
  • Relevant - needs to contribute to the story's bottom line
  • Time boxed - limited to a specific duration

Task switching overhead
Time yourself for this exercise, it has two parts. Write the phrase "Multitasking is worse than a lie" and after writing a single letter write the index number of the letter below of the letter itself. Now repeat the exercise by writing the sentence to completion first and then labeling the numbers below the letters from 1 to 27. The resulting output is the same, but the exercise highlights the high cost of task switching in the completion time difference.

Work in process limits: A single piece of flow results in highest quality and will surface bottlenecks.

Good Thoughts
Software development professionals understand the whole system.

Focusing on learning will create energy and fight lethargy.

If you take an action without direct add value you have to think carefully about the transaction cost and coordination cost.

No comments:

Post a Comment