Notes on Interesting Agile and Lean Things
From SquadLimberWiki
One well-optimized team I worked with can do a demo and review (restrospective) of a 2-week iteration in an hour,
take a break,
and then plan their next iteration in an hour.
(They do a longer retrospective every month or so).
"Thou Shalt Not Covet Frameworks Until Thou Absolutely Needest Them"
Resign Patterns Ailments of Unsuitable Project-Disoriented Software
Notes From Are Iterations Hazardous To Your Project
- Danger grows when the results of the iteration are not directly linked to delivering the product to the end user.
- "... endorphins get released when you do all the tasks assigned to the current 2-week planning period and tick them off the wall ..."
- For agile development to work, each person's activity must be visibly linked to delivering value to consumers.
- The underlying problem is that the work is not connected to delivering (that is the key word) running, tested features to users.
- The repair is simple: connect every activity to a release or delivery to real users (delivering to even one real user makes a difference). Evaluate the team's work based on how often they deliver to real users and how long it takes a new requirement to reach the users. Replace the fuss around iterations with fuss around deliveries.
Cannot Measure Productivity by Martin Fowler
Burn-Down Charts - Five Signs of Trouble in An Iteration
Context-Switching - How 2 hours can waste 2 weeks?
More on Context-Switching - The useful thing I took from this, was the value assessment, this is a useful tool for deciding when to interrupt a dev team from normal flow. Any outside force which can threaten to interrupt or context-switch the dev team can be assessed by it's value. For example, maybe their is a production support issue, a bug which needs fixing or a feature that someone is really pushing for. I think it is really important that a group of people get together, most likely the dev team leader, any managers and others involved, and decide if it is worth performing a context-switch before this reaches the dev team. In my experience, context switches are bad for an iteration but sometimes they are necessary. It is OK to accept the necessary ones, but the danger is that the value of each possible switch is not assessed and often these switches reach the dev team directly before being assessed. Their needs to be a filter in place between the team and outside forces, to push back against the low-value interruptions and accept the high-value ones.
