Three ways to avoid unplanned work

When a team is creating software it has to take into account that there is more than only feature development. During Sprint Planning work is pulled from the Product Backlog, a Sprint Goal is drafted and an actionable plan is made. 

But what about work that shows up after the Sprint is started? Stakeholders might be in dire need to get stuff done and ask the team to drop what they are doing to get something fixed real quick. Unplanned work can break commitment on the Sprint and demotivate a team.

Welcome change, even late in development

One of the agile principles is to welcome change. As developers we want to deliver beautiful solutions to our users. We can allow change, but we need to think about implementing it as well. All changes have consequences. Consequences on time, effort, capacity and knowledge. In short, we need to refine first to understand what needs to be done so we won't create technical debt (technical debt is work that needs to be done after the solution is delivered). The impact of a late change can be huge. So, we welcome change, even late in development but not late in our commitment (of the Sprint).

Refinement

To minimize unplanned work a team can improve on refining. If unplanned work arises because of incomplete refinement, we should focus on improving that. Using the INVEST acronym can help improving the quality of the story and make it more transparent for the stakeholders. Transparency helps the stakeholders to reflect if they told the right story so that they can change the story before the sprint instead of during one, reducing changes and unplanned (extra) work.

Sprint length

The closest Scrum comes to a project development method like SDM is when we talk about the Sprint. A Sprint can be seen as a mini project, with a fixed planning, a fixed team and a fixed budget. The longer the Sprint takes, the longer stakeholders need to wait to get what they asked for. So the longer the stakeholder needs to wait to see if the story was correct. A longer Sprint length will therefor limit inspectability and adaptability. To reduce unplanned work, improve those by reducing Sprint length. If there is a lot of unplanned work, try a Sprint of a week.

No

The hardest part of being a Product Owner seems to be to say no. There are many stakeholders and a limited time to do work in. Naturally not all work can be done at once, so there needs to be some order of importance. The Product Owner has a Product Backlog in which the work is ordered at the PO's delight. And naturally not everybody agrees with the PO's priorities. It is important for the PO to say no to the items that don't match the scope of the product or are not opportune at the moment. In hybrid Scrum implementations where managers of the PO or Scrum team are responsible for work and HR, this can be a real pain. They can break into the Sprint and wreak havoc if a PO doesn't stand it's ground.

To improve on reducing unplanned work, keep track of it. Find out how much time is spent on unplanned work and compare it to planned work. Find out how much extra time is lost because it is unplanned. Be transparent, present it during review and talk about it with stakeholders. The goal is to reduce unplanned work and become more predictable and deliver on your promise.

To whom much is given, much will be required

"Ils doivent envisager qu'une grande responsabilité est la suite inséparable d'un grand pouvoir". - (Comité de Salut Public ('Committee of Public Safety') during the 1793 French National Convention)

Teams are getting more and more autonomy and like parents, managers are sometimes reluctant to let go. And for a good reason, management is used to have authority on product development and HR. Now they are supposed to trust the teams but still feel responsible.

A lot of teams are in pubescence, finding their way in a world where they have more autonomy about how the product is developed and how they as developers should keep on developing themselves. With a greater power of self-determination also comes the responsibility to make something out of it all. This shifts the authority of the team, the product and the persons involved away from the managers.

What is there for management left to do when the chicks fly out into their adolescence? First of all, less. Second, other stuff; or better put, the same stuff in another way. A manager has become a facilitator instead of a commander. A manager helps the teams perform better. As the teams continue to grow and learn, they still will have troubles facing them. In parallel of growing up: kids are getting married, going to buy their first house, getting kids and so on. Parents don't dictate their children should, at least I hope so, they help them in finding the way. They are becoming more equal all the time.

Toddlers

Small, new teams need parenting, they are toddlers, asking questions, not sure what to make of the world. They need to find a way of working for them, the team and within the organisation. They need help in getting a work location, using different facilities et cetera. A manager helps them on their way. Perhaps even deciding for them. The manager also helps Scrum Masters and Product Owners in understanding the Scrum framework, the people and the organisation.

Puberty

When a team has worked some time together they understand each others perks and start to perform better. They are ready to take on more ownership. They can ride their own bikes to school and they can, and should, start experimenting. The team will start learning the deeper understanding of Scrum, they will improve on inspection and adaption. They will become more and more transparent. As a manager you can see what the teams do, when you do your Gemba Walk and learn about what your teams need.

"The Gemba Walk is an opportunity for staff to stand back from their day-to-day tasks to walk the floor of their workplace to identify wasteful activities. The objective of Gemba Walk is to understand the value stream and its problems rather than review results or make superficial comments."

Adolescence

Teams are almost grown up, they will perform very well. Delivering on time, caring about customers and running experiments as a daily practice. Teams will demand full authority on everything they do. This is the time for the management to let go. After 21 years of raising the kids, let's hope it's shorter for teams, they are ready to fly out and settle, to have their own Lean Startup in the company.

Adulthood

When has a team become adult? When they are able to decide their own future and understand that with great power comes great responsibility. Do the teams still need managers? Well, it depends. It is like asking if kids ever stop asking their parents. Some do, some don't. But as a parent, a manager will always be there to help the team evolve and improve. And get invited to parties!

Three habits of an effective standup

Most teams have adopted a daily meeting, be it a standup or daily start, to sync their work. In these meetings people share what they have been doing, are going to do, what went well, what went wrong and they ask for help if they need it. A lot of meetings are becoming a drag where people only tell about their schedule yesterday and today. They inform about big pieces of work they are still working on, or about all the small details that they spend hours on.

What can we do to make these meetings more effective? How can they deliver value to our work?

One: talk about work, not persons

If you have an overview of the work that is in progress and the work that needs to be done, talk about when work in progress is done or what we need to do to get it done. We don't really care at this point in time when our peers have meetings with the dentist, we care about the work we committed to.

Two: work from right top to left bottom

If you have a Kanban system in place with a board and swim lanes and such, start on the top right lane of work that is not done (typically the last lane is the done-lane, so start in the lane before last). Decide with the team how the top item can be completed today, then work your way down that lane. If the lane is done, move a lane over to the left, rinse and repeat. With this system you focus on getting work done, to really deliver the work. Only the stuff that is done counts, the rest cannot be used by our customers and is therefore not done.

Three: limit work in progress

Set a limit on the maximum number of items per swim lane. A rule of thumb is here to put a WIP-limit in of half the team size. A team of six persons would have a WIP-limit of three per lane. When you limit the work that is being worked on, people need to focus on delivering current work. It is possible that not everybody is "working"; perhaps someone is idle. That is not a problem. As long as the work is done what the team committed to, being idle is fine. We are being effective and that is not efficient per se.

These methods focus on getting work done, to live up to the commitment we give our customers and stakeholders when we start a sprint. Being effective is focusing on the outcome of our work. The daily standup is an event we can use to inspect the results of that focus and adapt where needed.