Over the years I have worked with, talked to and/or read about many agile teams. Almost none of the teams did agile software development the same way which has reinforced my belief that there is no "one way" of doing agile. One aspect of agile development I have always been drawn to is iteration length. Most teams seem to be falling in the 2-3 week range. In fact, recently a friend of mine said they were doing scrum with 3 week iterations becuase "any thing shorter caused too much overhead." I tried to point out that that isn't always the case as it depends of what overhead you are doing. I am a firm believer in minimuzing overhead as much as possible. I have always found ways to decrease or shift overhead to take less time in an iteration than previously believed possible. My favorite technique is process impedance matching.
I believe that lean thinking should be applied to software development. Given the principles of flow and value along with agile development practices it is obvious to me that the shorter the iteration the better. One of the competing forces is as the team size increases so does the overhead. To combat this I recommend capping team size to 9 (I am a slave to the magic number :-) Another consideration is the team's schedule. All the agile teams I know of work Monday to Friday and have a daily standup in the AM (9AM seems to be a popular time). People also like to forget work on weekends...some would argue it is the point of the weekend. Given these factors releasing on a Friday make the most sense to me. Monday's typically are hard... catching up on emails from people you didn't get to on Friday, remembering what it was you were doing when you left Friday...so planning meetings are best suited for Monday's. As you plan you are refreshing your memory as to the features you plan on bulding. All of this seems to point to a week long schedule of Monday mornings are planning and Friday afternoons are releasing. It's a nice package for an iteration in my opinion. I am open to shorter, but longer seems wastefull.
Many people will immediately think some version of the following: "That can't be a good idea becuase I'm not doing. If it was a good idea I would have thought of it when we decided to do >1 week iterations" or "I am sure it is >1 week here for a good reason...I just don't know exactly what that reason is." Given that I would like to convince you that my belief should be your belief (one of my many weaknesses) let me try and lay out common arguments against the one week iteration.
A1) One week iterations will have too much overhead.
I have found that the most people say this because they they they have to cram all the overhead they currently do in 3-4 weeks into one thus it is obvious to them this makes no sense. This assumption does not hold because of the lean principle of waste reduction and thus the goal is to minimize overhead. I challenge everyone to examine what overhead is actually needed in EVERY week? We already have blocked of 2 half days (Monday morning planning and Friday afternoon release & retrospective) as well as the 15 min stand up every day. Everything else should be avoided or at least minimized. If your organization requires a weekly status report and meeting. Use process impedance matching (e.g. let the team lead do it for the whole team; rotate through the team). Most all obstacles can be overcome if you use a brainstorm session with you team. If you have trouble solving a problem use the many internet sources (websites, groups, blogs...) If you seem stuck it is probably due to a lack of true teamwork (The Core has some iteresting ideas).
A2) Weekly releases are wasteful
Usually this comes from a management type who is thinking that all releases must have the business customer present (or some overhead thing like A3). If your business customer isn't engaged enough to commit to 2 half days a week then improvise and have a team member play a surrogate customer in those meetings. Different people have different skills, but hopefully one member of your team can think from a customer's point of view long enough for you to move forward. Once the customer makes time then re-validate. I am not saying it isn't ideal to have a fully committed business customer, but don't throw the baby out with the bath water.
A3) We can't do X in one week iterations
X is usually some localized practice that has evolved from a problem that wasn't solve, but is now. Like passing all releases to some QA team. If your organization is one with a separate QA team that must "sign off" on all external releases then simply use process impedance matching and send them your final release (the one that has all features needed in the time allowed) and then they test and they few if any defects (if you used proper agile development techniques) . You fix them as they find them and send them one more release when they are done (if they can manage to test in one week...doubtful if your organization hasn't embraced continuous testing..then send them one per week without needing to change your process much). Pretty simple if your team thinks about how to fit what needs to be done for organization reasons with what has to be done for agile development reasons.
I am sure there are more arguments out there that don't neatly fit into one of the above. Please comment with them. I think Tom Gilb once challenged an audience that over lunch he could figure out a way to release early then they currently do (Gilb's guidance was 2-5% of budget/schedule for each release). He got at least one free lunch out of that challenge. I am willing to take the few who read this on :-)
4 comments:
It is incredibly amusing and annoying that software professionals continue to spout off on this topic, each believing that they have the right answer. I say that it does not matter!!!
The general consensus is that any form of agile development is better than traditional waterfall development. Let each agile team pick a sprint duration - any duration - and try it out. Let them find what works best for their team, their organization and most importantly, their delivery targets. Let them apply agile principles to their development process, and refine it as they mature. Just like a pendulum, they will eventually get to an equilibrium state. Some will get there sooner rather than later, but they will be better off for having gone through this journey.
I do not recall seeing anything in the agile manifesto principles regarding the exact duration of a sprint (http://agilemanifesto.org/principles.html). Why not embrace diversity in this area just like we should everywhere else? Haven't we learned from our past mistakes elsewhere (capitalism versus communism, republican versus democrat - the list goes on) to not make the same one here? Obviously not :-)
Mostly, I agree. But quite often in my experience I run into problems that simply cannot be finished in one week with good enough quality - especially when working on legacy code bases. I just finished refactoring the company rules system - that took a month to get stable and work out all the edge cases.
I think that if you force yourself into breaking up problems in a way that value added functionality can be accomplished in one week you will be more productive and have better quality that doing the work in a month long chunk. I am not saying that what you did was wrong, but that if you try it you will be surprised.
I have never run into a problem that can not be sliced into week long pieces. Where there's a will, there's a way. BTW did you know that that was used by Charles Dickens?
I completely disagree that the sprint size do not matter. In many re engineering projects, usual tasks exceeds the 1-3 weeks recommended by most of people. In general, I would say that the sprint size must be as short as possible, but there are many situations where the team do not found a reasoning way to develop part of a shippable product, test it and report progress in a 2-3 week sprint, because it would not be easy to adapt a system to a complete a necessary database change in the client's company.
Post a Comment