Discussions on agile or distributed agile between experts or practitioners usually end with unanimous experiential epilogues that resonate with – “Agile has never been a cakewalk but, we have seen results …”. Ken Schwaber, who co-invented Scrum with Jeff Sutherland and presented it in OOPSLA’95, has radiated similar thoughts on the success rate of Scrum in his blogs and other forms of writings.
From project teams involved in software product engineering to participants at agile conferences and workshops, I have come across several questions related to the ‘size’ and ‘content’ of iterations or Sprints.
Some organizations or practitioners do have firm beliefs based on what has worked for them. They may emphasize on a 1-month Sprint or a 2-week Sprint all the time. However, the essence of a Sprint is the concept of Time-box. You decide on what works for you. A Sprint can be of any size provided you maintain sustainable pace. In practice a viable Sprint size is 2 weeks or more. If you want to plan for 1-week Sprints, it is going to be too aggressive. Try, inspect and adapt!
What can be the ‘content’ of an iteration or Sprint? I have observed several projects to think through and find an answer for this question. Iteration content is project specific. Also, all iterations in a project need not have the same type of content. There can be several types of iterations. Let me share some of them in this blog.
Architecture Sprint: If your project has architecture centric activities such as development of sub-systems and integration of frameworks, it is a good practice to plan one or two sprints for this purpose.
Architecture Overhaul Sprint: Sometimes, when you foresee the need to overhaul an existing architecture dedicate a Sprint or two to focus on this theme.
Product Stability Sprint: When you work on a complex product with interdependent modules you may come across the need to plan for one or two product stability Sprints. Whether or not you work with distributed product engineering teams this situation can arise purely based on the nature of your product or project. Typically, you focus on fixing bugs in order to improve product stability.
Environment Stability Sprint: In projects that require complex environments you may come across issues related to environment stability. Depending on the quantity and severity of such issues it is worth considering one or two Sprints to make the environment stable. Typically environment issues are resolved during such Sprints as environments are validated.
QA Sprint: In product development environments, a couple of Sprints for QA activities alone is worth considering, in order to detect as many issues and improve product quality.
Reenergizing Sprint: If your product engineering team stretches too much continuously for several months this can help them reenergize. This came up during my discussions with practitioners in one of the workshops. ‘If your team is stretching for months together, why not a 1-week reenergizing Sprint?’ asked one of the senior members in the workshop. Why not? We have seen this happening after major releases. The team gets some warm-up time before they start on the next project. In case of minor releases, we collaborate with the customer and provide some time-off that overlaps with weekends and provides sometime for relaxation. Some of our teams plan a 1-day picnic, go to a resort or a hill station or a dense forest and reenergize themselves.
In essence, the ‘size’ and ‘content’ of iterations can be tailored to your project ecosystem. Though you may hear prescriptive answers or approaches, it is logical to apply it to your context and follow agile principles. Make iterations work for you! That is the recipe for success!
What has worked for you?