Another agile correction

If you're trying to find information about agile on the internet, I hope you've found that there is a lot of wrong information out there. Let me give you an example.

Here's a response based on the question of lean relating to agile.

"Many of the principles will find an echo in a Lean principle too, but one fundamental difference to keep in mind: Lean does NOT talk about iterations - only about reducing work-in-progress and delivering early. So you can be Lean without doing any iterations, but you cannot be Agile without iterations."

This is an interesting statement: "you cannot be agile without iterations". I think Mary Poppendyke, David Anderson, and many, many other agile leaders would find this untrue. The Scrumban approach as well many of the articles I've read about Kanban focus on flow and still claim they are agile without iterations. I think Mary Poppendyke believes that lean is agile dispite not having iterations.

I suppose saying that agile requires iterations really depends on what you would define agile as. In my world, an agile project deals with plan/do/inspect/adapt which requires doing, inspecting, and adapting, iterations are keys.  But I can also see a flow approach that inspects and adapts on a per story basis.

Small stories

If your stories are small, discrete pieces of work, Kanban fits well – no one story choked the backlog and stories didn’t need to be completed in groups. The business then has the flexibility to change the backlog of any story not on the Kanban board which means the process allowed the business to keep up with the development team. The business focuses on fewer stories, meaning that the stories they did focus on are of much higher quality. Keeping only 2 critical stories in the product backlog at any one time (limited by WIP), enables a fluid prioritization of the rest of backlog. The business team, who determines the content of the stories, is able to focus only the top few, leading to better time management and clearer stories.

Correction on Agile

If you're trying to find information about agile on the internet, I hope you've found that there is a lot of wrong information out there. Let me give you a couple of examples.

In a study group about agile certification, the question came up about iteration length. One of the participants posted the following;

"Sprint duration is fixed ONLY after some smiler (sic) Sprint cycles have finished so there is no such duration fixed (sic). Books may recommend some durations for understanding purposes and in practical (sic) smaller the Sprint, more effective it is.Once the Sprint is longer than 1 month or so, then again it effects its agility anyway(sic)."

Where did that come from? What does this mean? I wonder. Scrum.org paints iterations as time boxes of fixed length. Varying sprint lengths make it difficult to judge how much can be completed or do any type of forecasting. Sprint lengths are set and shouldn't vary - based on Schwaber, Cohn, Fowler, and more.

I have other examples I'll explore next month

Successive Refinement of Requirement/design

In agile, requirements are progressively detailed, with the finest details being developed as late as feasible. There are three main reasons for this just in time requirements detailing: no time is wasted on requirements that are possibly not going to be developed, decisions about requirements can take into account lessons learned in prior sprints and the requirements fresh in the mind of the team when they begin developing because the lag time between specification and implementation is short. Enabling flexibility in the requirements backlog and minimizing wasted work are just as important as detailing the requirements.

Design documentation has its highest value in helping work out the details of the software under construction, not as post implementation documentation. As a post-implementation artifact, documentation must be kept up to date with the software which adds to the cost of any software changes. If the documentation is even slightly out of date, the documentation looses credibility – the code becomes the ultimate documentation. Unless the documentation is automatically generated, design documentation is of limited value and should be prioritized low.