While I recommend following the core tenets of Scrum Agile, I have designed and implemented extensions to the Scrum process that increase the effectiveness of Agile development in product companies and reduce overall risk.
If you have already adopted Scrum Agile, you will be familiar with the following:
- Self-organizing, cross-functional teams
- Scrummaster to oversee and facilitate the process for all the teams
- 2 (or at least, fixed) week Sprints
- Relative sizing
- Sprint Planning and Commitments
- Breaking down committed stories into tasks of 1 day or less
- Iterating development deliverables to QA in ‘QAable chunks’
- Tracking status with physical and/or technology scrum boards and daily standups
- Steering Sprints to a successful conclusion
- Hosting Sprint Reviews and Retrospectives
Adapting for improved effectiveness
While the core principles of Scrum are highly beneficial in their own right, companies developing products or solutions that have to meet rigorous goals of scale, performance, backward compatibility, quality, etc. need to evolve their Agile practices to incorporate techniques that provide a basis for architectural evolution, design consistency, and team optimization.
Needs more information or NMI TM stories
Needs More Information or NMI stories are an extension to the Scrum process that account for research, architecture, design and prototyping activities that are often necessary before a large story or group of stories can be effectively sized. By spawning an NMI during Story Sizing (Backlog Meet and Greet) and prioritizing it high in the backlog (typically for the next sprint), Agile teams can increase their confidence that the implementation story (or stories) can be committed to and delivered upon.
NMI’s are expressed as a series of questions that need to be answered before the related story (or stories) can be sized. NMIs are typically small in size relative to the original story or group of stories and can employ technical prototypes, white board sessions, architecture reviews, technical research, etc. to answer the open questions.
NMI deliverables include
- Additional story breakdown (if the work is able to be broken down further)
- Sizing of the story or group of stories
- Task breakdown
Once the NMI is complete and the related story or group of stories are sized, the team can confidently commit to delivery based on their velocity in the Sprint Planning meeting.
In an effort to ensure a potentially shippable product increment at the end of each Sprint (and to optimize the team’s efforts) it’s important that all members of a ‘story team’ stay on the story until it’s ‘done’. This can at times result in team members being idled for periods during the sprint.
In the event that this is a developer, the last thing you want as an Engineering leader is for them to open another story and start checking in code that may or may not be QA-ed by the end of the sprint (since it will lead to more technical debt.) Instead, have your Developers, QA and Designers each create and manage a Slacklog. A Slacklog is a list of items that an idled team member can work on that does not create debt for anyone else. For example, writing or improving unit tests, prototyping with new technologies, writing QA automation tests.
While at first blush, having your team ‘idled’ during a Sprint seems counter-intuitive to productivity, the opposite is actually true. Creating some ‘pain’ in the process will help it improve. No-one likes to be idled, especially Engineers, and the team will find ways to optimize their efforts. For example, if Developers are idled because they held onto all the tasks until the story was almost complete – and now are waiting for QA to finish – they will seek ways to better phase delivery of the work. If QA Engineers are idled because they are waiting for something to test or for bugs to be fixed on a story, they and the Developers will be motivated to invest in unit testing and QA automation scripts. Trust me, it works…
Handling Unplanned Escalations
In an ideal situation, Sprint Planning and execution would proceed without any surprises – and all committed stories would be completed in the Sprint. However, we live in a (necessarily) imperfect world. One where customers, partners and the vagaries of software and infrastructure often lead to unplanned escalations that the team has to deal with.
“Above the Line”
Rather than build in a bug fix contingency, I prefer to create a section at the top of the scrum board to track and manage items that are introduced after Sprint Planning. I call this section ‘Above the Line’. Stories, tasks and bugs can only be introduced to an active Sprint by the Product Owner or Scrummaster and are added ‘Above the Line’.
By following this model all unplanned items introduced after Sprint Planning will be very visible, allowing you to measure the team’s actual velocity, quantify the impact of unplanned work on committed stories, and most importantly, look at where the exceptions are originating from in order to reduce them.
Managing ‘Above the Line’ Work
There are two approaches I have found to be effective in managing unplanned work in a Sprint. The approach you choose will depend on the complexity of your product, the degree of shared code knowledge and your team’s ability to switch gears.
Leveraging the entire Scrum team to work on escalations carries the implicit understanding that work placed ‘Above the Line’ takes precedence over committed stories and could cause one or more committed stories to be dropped from the Sprint.
With this approach, ‘Above the Line’ items fall into two categories and should be treated differently to reduce context switching:
- Critical – Fix Immediately: Developers and/or QA should drop whatever they are working on and immediately swarm to find, implement and test a resolution.
- Fix In This Sprint: Developers and/or QA continue to work on their current tasks. As they complete a task and move it across the board, before they pick up the next task for their current story, they look to see if there is a task ‘Above the Line’ that needs to be picked up.
2. “Assigned Resources”
Another approach to handling escalations is to assign ‘Above the Line’ to a small ‘swat team’ for the duration of a Sprint. In essence, you reduce the velocity of the team to allow for escalations to be handled. While this approach dramatically reduces ongoing interruptions on the Story team, depending on skillsets/experience, it may require pairing with Story developers for knowledge transfer. Also, it’s likely that the ‘swat team’ will be idled at some point during the Sprint, creating an opportunity to work on Slacklog tasks.
Agile for Desktop IT, Build and Release, and Technical Operations
Teams that have a high degree of interrupt-driven work every sprint (a big part of their responsilbities is responding to exceptions), such as Desktop IT, Build and Release, or Technical Operations benefit from planning with a reduced velocity.
Begin by tracking and sizing all the ‘Above the Line’ items and maintaining an open mind to what was committed. When your team has completed 3-4 sprints, average the counts for ‘Abolve the Line’ and Story points. This will provide you with a reasonable estimate for the #interrupt points per Sprint and #availablevelocity. When Planning, use the #availablevelocity.
Taking this approach will ensure your IT, Build and Release and/or Technical Operations teams are able to respond in a timely way, but are not purely interrupt-driven. They are also able to move key initiatives forward in a planned and predictable way.
Terms ‘NMI’ and ‘Slacklog’ are trademarks of Shirley A. Foster