One of my favorite little management blurbs, seen on the door of an SVP at a major financial services company: “Processes don’t write software, people do!” And of course, the Agile Manifesto states: “… we have come to value: Individuals and Interactions over Processes and Tools…” Here’s an interesting little writeup about people and process. My own take is quite similar: a process can be more or less helpful, but only if people are willing to learn and change can true progress be made.
My first experience with any process that was similar to an Agile approach was in a startup ten years ago. We did 3-day-long iterations on a software project with a three person development team. That experience, followed by its antithesis, shaped the rest of my life. And yet, short iterations aren’t always the best way to go.
A short iteration length for a given type of work will depend on the horizon of predictability for that work. In software development, anything five working days or less could be considered short. In daily newspaper publishing, fifteen minutes or less could be considered short. As a rule of thumb, “short” simply means that it is possible to fit two or more iterations in the length of the horizon of predictability.
Pros of Short Iterations
– deliver work fast: the first potentially shippable features are available after only a very small amount of time
– people keep focused on the goal(s) for the iteration; there is no chance to get distracted
– very tight learning feedback loop allows for quick discovery of optimal solutions
Cons of Short Iterations
– intensity of work can lead to burnout
– strategic thinking can be hard to fit into the “schedule”
– overhead tasks that must be done every iteration take a larger proportion of the time in the iteration
– waiting for resources or people outside of the team can make it more likely for work to span iterations
Guidelines: Choosing Iteration Length
1. Start by understanding the horizon of predictability in your environment. This is the maximum length for your iterations. In most IT organizations, this is somewhere around four weeks, whereas in web environments, it is usually much shorter.
2. Consider your constraints for delivering potentially shippable work units. Also consider the team size and the communication overhead that results. These two factors can guide you to determine a minimum iteration length. Identifiable overhead should not account for more than 25% of your time.
3. At the start of a work effort with a team new to Agile Work, consider erring towards shorter iterations. Shorter iterations can shock people into discarding bad habits by changing people’s mental model of how to work effectively. Teams with successful agile experience may consider longer iterations.
4. Consider your ability to automate overhead work tasks and testing tasks. If you can develop a highly automated environment, shorter iterations are possible. If on the other hand, manual efforts will be required (no pun intended), consider a longer iteration length.
5. Consider the overall amount of schedule/funding. For a team to learn the domain and stabilize their velocity, consider trying to fit eight or more iterations into the overall schedule. The first three our four iterations include a lot of learning about the team, the process and the domain.
Some people recommend other methods of choosing the length of your iterations: How Long is a Timebox.
(UPDATE) Here is a more recent article I wrote called “21 Tips on Choosing a Sprint Length“.
What We Did Way Back When…
The three day iteration length was largely determined by how frequently the sales folks could bring in potential customers for a demo. Every time we demoed, we were using working software. We would do a fairly complete walkthrough of the software and gather feedback. We would balance the feedback with outstanding features and make a call about what to add/change over the course of the next iteration. This constant involvement of customers and the requirement to have always-working software set my expectations for software development in a way that my experience up to that point had not even hinted at. When I went to my next job (which was at Sun Microsystems), I was appalled by the long cycle time to produce working software and the almost complete lack of customer involvement in the process. I vowed never to work that way again…
… and became a consultant and an agilist 🙂
Agile Work requires that we align our perception of reality in order to understand each other and do work that is considered valuable by everyone. One very blunt and seemingly simple way to do this is with metrics. But metrics need to be in context and that is the part that is hard to get right. Does your organization get it right?
The latest Carnival of the Agilists has two references beck to Agile Advice… and of course lots of other great reading. Have fun!
Tobias Mayer has written a brief comment about the poem “Cutting Up an Ox“. I haven’t encountered this poem previously so here’s a “Thanks!” to Tobias. I’ll also throw in my own two bits…
Scrum is one of the Agile Methods that can be applied in many different fields of work. Last year, I was able to present the basic Scrum framework in a two hour session to a class of media students at Keyano College in northern Alberta. They used Scrum for their class project – a documentary video. One of the students really took to Scrum, and used it in his next class to save another group project… and get the best mark in the class! Full story follows…