Protecting the Sprint

By Cindy on September 11, 2013 • ( 0 )

Chaos is not Agile
While Agile encourages change and adaptability to better meet the current needs of the customer and the business, the sprint is a boundary that, when respected, protects the team from distractions and allows them to focus on getting things done productively. Protecting the sprint from excessive change provides the team with the stability and sense of direction they need to get things done. Often times people use Agile as an excuse for indecisiveness but if you’re constantly changing direction you’ll have difficulty getting anything done, and if you don’t get anything done then you’re not delivering any value to your customer.

Of course this doesn’t mean that all requirements are known at the beginning and that requirements won’t change, but rather that the goal posts aren’t shifting while we’re running towards them. The team is able to take the ball and run with it, and then, at the end of the sprint we can adjust our course as necessary. The Scrum Master tries to protect the team from distractions and unnecessary changes from the outside but this is easiest when the team and the organisation are also supporting and protecting the sprint. We need to work together to achieve our goals.

Focus
There are two main reasons why focus is important for getting things done. The first is that human’s aren’t great at multi-tasking, or more specifically, q we multi-task in a completely different way. (I found this article: http://www.bryanbraun.com/2012/06/25/multitasking-and-context-switching on multi-tasking and context switching especially enlightening). While we may be able to walk to work while listening to podcasts and eating breakfast, there’s no way we can work on complex software development tasks simultaneously. Instead, if our attention is split, we’re forced to multi-task by jumping from one task to another, and we’re no good at that.

The reason we’re no good at it is the second reason why focus is important. Context Switching is expensive. A computer can switch from one task to another with almost no overhead but human’s can’t switch that fast. It takes time for us to move from one location to another, open different software or at the very least rebuild our mental models of the problems we’re trying to solve. It’s been suggested that we spend 20% of our time on context switching for each additional project that we’re splitting our brain power across. That means that as we split ourselves across tasks and increase our context switching, we end up with less and less time for actually getting things done. In truth it’s even worse than that since different tasks require different amounts of time to get back into the zone of productivity and unfortunately, software development tasks generally run high on context switching costs.

Focus Golden Time on Golden Tasks
So how can we minimise context switching costs? The first step is to schedule things so that team members have long periods of distraction free time. Try to book meetings or chase up on questions around the periphery of the day or cluster them together (without overloading anyone of course).

As a development team member it can also be helpful to identify your Golden Time. That is, the time when you are the most productive. Some people work better in the morning or in the afternoon. Work out what you are and try to keep that free. You can even consider booking out spaces in your calendar to keep people at bay. If that doesn’t work, ask the Scrum Master to be the first line of defence against distractions during those times. You might still get interrupted but hopefully it will only be for emergencies. Once you’ve identified your Golden Time and achieved some amount of distraction free time, try to focus on spending that time on the work with the highest context switching costs. Overall this should reduce the time you spend context-switching and help you to complete those important tasks.

Focus on Done
In most cases it is better to have one thing Done and ready to be delivered, than to have 50 things in progress and nothing deliverable. A bird in the hand is worth two in the bush. Focusing on getting one thing done at a time also means less attempting to multi-task and less context switching. The focus of a sprint is getting all the items in the sprint backlog into Done so each item that moves across, gets you closer to that goal. Working on tasks that don’t help get a sprint item into Done is a threat to the sprint and needs to be identified.

Focus on Priorities
When new pieces of work appear it’s important that they are prioritised by the Product Owner before the team is distracted by it. If it’s not important we can save the teams time. If it is urgent then the Product Owner can take it to the team knowing how that importance compares to their current work.

It’s important to be aware that extra work can only be added to the sprint backlog if both the Product Owner and the team agree. Everyone needs to be clear what the consequences off adding that work is, usually this will mean swapping it out for something else, but the additional consequence is of course, lack of focus and increased context switching. This is why the sprint backlog shouldn’t be changed except for in emergencies. It’s important for the Product Owner to honestly consider whether it can wait until the next sprint.

There may be times, such as the (ideally avoided) stability/regression period before release where urgent bugs are more common. Such periods indicate a weakness in sprint quality standards that need to be addressed. However, in the meantime, it may be wise to put aside sprint capacity during these time and meet regularly, with the team and the PO, to review the sprint backlog and the emerging bugs.

No matter what, the sprint backlog needs to be put in order. If you prioritise then even if the sprint is not completed, the items that are Done will be the most important ones. Protecting the sprint doesn’t mean emergencies won’t happen or that every sprint will go smoothly and everything will get done every sprint. It does mean that everyone did their best to get the most important things Done for that 2 week period.

Focus on Controling Scope
Another, more insidious, threat to the sprint is that of scope creep. Developers often get so wrapped up in delivering the perfect system that we forget – customers don’t need the perfect system. Or at least, it’s more valuable for them to have an adequate system first. Don’t do more than necessary to deliver what the customer and the Product Owner have asked for. Things could all change the next sprint making your extra work superfluous.

All scope changes or emerging scope should be treated as extra work and prioritised by the Product Owner. Keeping a close watch for scope creep protects the sprint by stopping it from growing out of control. A sprint that grows out of control may block everything from being delivered while fixing issues the customer may not even care about when given the choice between getting something or nothing.

Focus on Quality
Keeping control of scope doesn’t mean that we should start cutting quality controls as ‘unnecessary extra scope’. Quality is fundamental to keeping things moving in a sprint. Every sprint we skimp on quality will come back to haunt us and threaten future sprints in the form of increased bugs and unnecessary complexity. We need to protect future sprints from our current selves and focus on quality.

Raise Impediments
Finally it’s important to raise impediments when they occur and start blocking sprint progress. Even better is when you can raise them before they start blocking progress. The earlier impediments are identified, the sooner the team can get help removing them. The longer they are left unnoticed, the greater the chance that the delay will have an impact on the sprint delivery.

Some team members will keep quiet about impediments, hoping they will resolve themselves or that the team member is question will be able to deal with it personally, but broadcasting this information makes sure everyone is aware of the threats to the sprint. Many can defend the sprint much better than one alone. If impediments have been raised but no-one seems to be actioning them, communicate the consequences if the impediment isn’t cleared. The scrum master can also help by getting the people responsible for the impediment and the people affected by the consequences to the stand up so they can receive the same communication. Usually bringing these people together can get things moving more quickly.

Protecting the sprint is essential for delivering the greatest value but it’s not just the Scrum Masters job, nor should it fall to the scrum team alone. The whole organisation needs to work at clearing the way for sprint if they want to maximise the value that outputs from them.

Related Books: