Stop Blowing Up Sprints!!

Posted on January 18, 2018 by Sean

If you are using scrum successfully, this is probably obvious to you. I’ve been doing a fair amount of consulting lately and I’ve worked with a lot of teams where blowing up sprints is common practice. Let me define what I mean by blowing up a sprint.

A sprint blow up is when you have a fixed length sprint, we’ll call it two weeks, and midway into the sprint you decide to change scope. This could be due to a defect coming in from the field. This could be because the CEO wants to work on something different. It could be because the product owner changed their mind about a feature.

Regardless of the reason for the blow up, it is typically done with little forethought. It’s almost never done with maliciousness. The primary reason for a sprint blow up is ignorance. The person blowing up the sprint will typically ask, why can’t I just replace this 3 point story with that 3 point story? Pretty reasonable question right?

As software engineers, it is up to us to educate why it is such a bad idea to blow up a sprint. There are two overarching reasons why sprint blow ups are so disruptive. The first reason is cultural, the other(s) is technical.

When business leaders decide to use agile, they are often told that one of the benefits is that their developers will commit to hitting each sprint. For business leaders that have any memory of the old waterfall days where being six months over estimate was more common than inappropriate yoga pants at a Walmart, this sounded like a pretty good deal. The problem was, no one told these leaders the full story.

A sprint is a contract

The folks building and testing product are committing to hitting a sprint. In return, the rest of the company is committing to not changing the contents of that sprint for the duration of that sprint. That is the contract. I can tell almost immediately when I walk in to a dev shop where blowing up sprints is commonplace. The developers and QA all have a defeated, hang dog look about them and the rest of the company has very little respect for them. The rest of the company ends up blaming the development team for not hitting their commitments without the slightest understanding that they are the ones in breach of contract.

You know what happens to good developers in this type of toxic culture? Yep, they leave. Nobody wants to work in a culture where everyone is blaming them for failure.

Before we get to the technical challenges around sprint blow ups let’s first answer the question – why can’t I just swap out this 3 point story with that 3 point story? The answer to that is estimation is not an exact science. Story points estimates are no more accurate than t-shirt sizes. We’ve all experienced putting on an XL t-shirt that wears like body paint, while putting on another XL that fits like a moo moo. I have anyway. When the team is doing their estimates, everybody in the room knows which story is a heavy 5 and which story is a light 3. When they commit to the sprint, they’re all doing the inner calculus that says ‘I may fall a little behind on that heavy 5 but I’m sure I can pick it up on that light 3.’

When you blow up the sprint, that inner calculus disappears. You have invalidated the development team’s commitment. Once the sprint is violated, those commitments can no longer be honored.

What if we have no choice?

The most common complaint I get when passing on this advice is – well what about issues coming in from the field? We can’t just leave our customers high and dry. I agree, you can’t leave your customers hanging especially if you’re dealing with high priority defects.

The best answer to this is to have a team that is dedicated to customer issues that is outside of the sprint development cycle. This is typically only one dev and one QA person and that QA person can even be part time. When that dev is not fielding high priority issues from the field, they are fixing defects or refactoring tech debt. This should be a rotating position. When doing two week sprints, dev support should only be for two sprints at a time. This is a great way to spread the burden, so you don’t get one developer who ends up being the go to guy for all defects coming in. It is also a great way to make sure everyone is familiar with the majority of the code base. There’s no better way to train new developers than to throw them into that hot seat. Sure, they’ll get help from other members of the team, but when it’s your ass on the line you will learn that code quickly.

What happens if your team is not big enough to field even one developer to handle these issues coming in from the field? Please don’t try to half ass this. I’ve worked with a couple of teams where they said – “we just budget x% of the sprint to manage defects coming in.” This will never work. You can’t budget for chaos. When defects come in, they might take up 5% of the sprint, or more commonly, they end up taking more like 50% of the sprint. Not to mention that defects are damn near impossible to estimate in the first place. If the devs knew what the problem was, they wouldn’t have written the defect into the code in the first place. Either way, the defect kills that inner calculus and the sprint is destroyed.

The short answer is if your team is too small to handle field issues outside of the sprint, you shouldn’t be using scrum. Scrum only works when the contract is upheld. I’d recommend Kanban instead.

What are the engineering reasons you shouldn’t blow up a sprint?

I’ll list several more reasons here if you still need to articulate why blowing up a sprint is a bad idea. This list could easily be expanded and I recommend you to do so. It’s cathartic. When swapping out stories or throwing in defects to blow up a sprint, outside of the estimation issue, you are also not accounting for:

The work already started (half of story B is left unfinished)
The de-risking required for the new stories (which is normally just skipped and you wing it)
Context switching
The environmental set-ups (things like supporting data sets, integration points, etc.) required to build certain stories
The branching required to quarantine started work
The branching required to start new work
New dependencies introduced by the new work
New integration testing and merging required by the new work
Changes in release strategies if necessary

You want to bring dignity back to a development environment and culture? Stop blowing up those sprints!

The horrors of context switching (and how to beat them) – Part 2

Posted on April 12, 2017 by Sean

Part Deux

The first post on this topic covered many of the ways that context switching can destroy the productivity of your day but most of the post was aimed at developers. This one reaches out to everyone that works in an office. Scott Adams has made a career out of ridiculing the pointlessness of workplace politics. In no setting is this ridicule more pronounced than the pointless meeting.

Agile best practices

Multitasking meetings?

Have you ever been in a meeting and looked around the table while someone is giving a presentation? What do you see? Too many times I would see a scene like this: John is looking at his phone, Betty is trolling the web while Michael is writing on a post-it in front of Margaret. Sound familiar? Exactly, the workplace has regressed back to fifth grade.

Agile best practices

Even worse, I once had a CEO that would regularly take phone calls from his wife while we were in a meeting and would talk with her on the phone for a good 5-10 minutes while everyone would be sitting there waiting. Sometimes, he would even lapse into baby talk. It was a fantastic use of time. This happened in executive leadership meetings all the time. Let’s look at the economics behind this. If he took a call with eight of us in the room, each of us making an average of $250/hr, each 10 minute phone call he took would cost the company roughly $500. This accounts for the 5 minutes it would take for us to get back to where we were in the meeting. Granted, this guy was a world class asshole but these types of things happen all the time in meetings across the globe.

Luckily, there is a cure for the pointless meeting.

7 tips for a productive meeting

The best way to deal with distractions if these are your meetings is to be honest with your teams. Be very clear that you are not going to waste their time but be just as clear that you will not tolerate them wasting yours or other people’s time. When people aren’t paying attention, most of the time it is because they are not engaged. That’s on you as a leader. These are 7 tips that I have found to be incredibly effective for holding a highly engaged meeting:

Have an agenda and stick to it
ONLY invite people that can contribute to the topics on the agenda
Lids down. Phones down.
Start on time
Don’t take up the full meeting time if you don’t have to
At the end of the meeting ask the attendees if they thought it was productive or not
Write down action items and send them out with a summary after the meeting

Make it about respect

The strongest statement you can make that the meeting will be productive is to have an agenda. Having an agenda means that you have enough respect for your team that you prepared in advance. If it is not your meeting, it is perfectly acceptable to ask what the agenda is. If the leader of the meeting doesn’t have one, make sure you get that person to cover the points they hope to get done in the meeting before the meeting starts. I’m at a stage in my career that I will typically leave a meeting if there is no agenda. The end result of this action is that I either don’t get invited to, in my opinion pointless, meetings or the leader of the meeting puts together an agenda before inviting me.

Always run the numbers

Run the numbers. If somebody is not going to be contributing in the meeting and you invite them to it anyway, ask yourself, how much do they make an hour? If they’re not contributing am I willing to burn $100 of the company’s money to have them there doing nothing? Many times people are invited to meetings not to contribute but just so they don’t miss out on information being passed in the meeting. This is a terrible use of their time. A simple summary email once the meeting is over is far more effective and will not require context switching.

Once the agenda is briefly covered, expect all participants of the meeting to be engaged. The best way to enforce this is by asking for lids down and phones down. It is far more difficult to be engaged if the distraction of a laptop or a phone is staring you in the face.

Start your meetings on time. Do not wait for stragglers that are rolling in late. Start on time and either end on time or end early. Respect your people by treating them like adults. If somebody rolls in late, let them catch up on the topic in their own time. Do not keep stopping the meeting to fill folks in on what they missed. That’s a waste of everyone’s time. Even if it is somebody who is higher than you in the corporate hierarchy. If somebody asks for a summary after showing up late, you can handle this with tact. Say something along the lines of, “I’ll be happy to fill you in later but with respect to everyone’s time we need to stay on topic.”

I used this approach with a former COO of mine. This COO would roll into every meeting 5 to 10 minutes late. I could tell he was annoyed with my approach but, very professionally, he waited until the meeting was over to let me know. He explained that he was incredibly busy and that most other meetings he had ran over. I let him know that I understood that frustration but then I went to the numbers. If I interrupted the meeting every time someone came in late, I not only risked disengaging the rest of the team, but we would be forced to go off topic, then context switch back to the topic on hand. If there were 10 people in the room each making roughly $100 an hour, that 5 minute interruption costs almost $100. If we do that twice a meeting, it starts to get very expensive. The other point I made was that if I only were to do this for him because he outranked me, I would be showing my team that we have two different standards in the company in regards to respecting people’s time. We would basically be saying that it’s ok to waste other people’s time as long as you outrank them. To his credit, he just nodded. I would love to say that after that conversation, he was never late to a meeting but that just wasn’t true. He never asked me for a summary again however.

When you get through your points, end the meeting

Once you are through with the agenda, END THE MEETING. Nothing is more infuriating than having a leader of a meeting look at the clock and say, “Oooh look, we still have 20 minutes left, let’s try to get this done too!” Why is that so infuriating? Because of tip #2. You put the attendees of that meeting together ahead of time to contribute to the topics on the agenda. Once you go off of those topics, somebody, if not everybody will feel like you are wasting their time. Ending early is a sign of efficiency and your team will respect you for it. Throwing pointless filler in at the end of a meeting is a waste of resources.

Incorporate the feedback loop. At the end of the meeting ask the group if they thought the meeting was an effective use of their time. Make sure you get an answer from each attendee. It is critical that you are open to this feedback or else it just comes across as lip service. If an attendee says they think that it was an ineffective use of their time, make sure you get them to give you a couple of ideas of how they would make the time more effective. If the majority of the attendees say the meeting was an ineffective use of time, you need to be ok with cancelling similar future meetings especially if they are scheduled weekly.

Finally, make sure to write down the action items that come up during the meeting. When the meeting is over, take five minutes to write up a summary that gets sent out to the attendees and anyone else that needs to know what was discussed in the meeting. This summary should also contain the action items that came out of the meeting. This is critical because this is a written record of the commitments that people made in the meeting.

Conclusion

I would say that at least 60% of all meetings are a complete waste of time. Not only do you lose the time that is spent in the pointless meeting, you also lose all the time around the meeting when you have to context switch and try to get back in the flow of what you were actually working on. It doesn’t have to be this way:

Agile best practices

The horrors of context switching (and how to beat them) Part 1

Posted on March 27, 2017April 12, 2017 by Sean

Context Switching

Context switching is the bane of productivity. For those of you not familiar with the term: context switching is when one is forced to switch from one topic or work item to the next. This is also known as multi-tasking. Sadly, too many people believe they are excellent multi-taskers. This is nonsense. Nobody is an excellent multi-tasker.

The brain is single threaded. We are not processors that can be running two tasks in parallel. We don’t have the internal CPU for such a job. Every time we switch tasks, we have to rebuild our mental architecture. We have to tear down the thought processes for our current task and replace them with the thought processes for the new task. This takes time when we are working in a vacuum. But when’s the last time you worked in a vacuum? Think about how much more time this takes when we are getting interrupted on a regular basis.

This is the famous chart that Gerry Weinberg put together to illustrate the waste caused by context switching.

Context Switching Chart 1

If the numbers aren’t working for you in the first chart, that is because several assumptions are being made. The chart below explains those assumptions in a little more detail.

Context Switching Chart 2

If you don’t find these graphs shocking, you’re not reading them right. If you are working on two projects at one time, then you are losing a full 20% of your productivity. If you are working on 5? 75% of your productivity goes straight in the shitter. To say that another way, when you are working five projects, each project gets 1/20th of your time. Rebuilding your mental architecture each time gets 3/4ths of your time.

That doesn’t apply to me, I’m a great multi-tasker

Oh yeah? If you are such a good multi-tasker do these two simple tasks for me: recite the lyrics of your favorite song and calculate the square root of 2,116. The hitch? You have to do these two tasks at the same time. Start the lyrics now and do not pause. Before you finish those lyrics, come up with the answer to the math problem.

In my personal experiments, one of two things happen here. The person gives up OR they come up with the right answer to the math problem but keep losing their place in the song. Humans are NOT capable of multi-tasking. Unless you are a cyborg or have figured out how to split your brain, please stop claiming that you are a good multi-tasker. My crappy personal experimentation aside, the science is in. You can start here for more info: http://www.npr.org/templates/story/story.php?storyId=95256794.

There is always some wise-ass at this point that asks the question: if that is true how can I drive and hold a conversation? OR, how can I chew gum and walk at the same time. The answer: habits don’t count. The things that you have done so many times where your lizard brain takes over and the action gets moved to auto pilot don’t rely on higher level thought. We are only talking about those tasks that take higher level thought. Which, hopefully, is most of the tasks you do every day at work.

Interesting sidebar edit: It took me an hour and a half to write 80% of this column. I received a phone call when I was almost done writing that I had to take. It took me another hour and a half to write the final 20%. Context switching in action.

So what do we do about this loss of productivity?

One of my old bosses had a great philosophy: you want to move faster? Do less at one time. This is another way of stating the old maxim that less is more.

Let’s get specific and address one of two primary issues where context switching is a huge killer: software development. We’ll cover the other productivity killing issue, meetings, in the next post.

Cut your WIP (work in progress) ASAP

This is where the less is more rubber hits the road. When it comes to agile, one of the questions we need to be asking ourselves all the time is how much we can cut our work in progress. This questioning is where Kanban can be incredibly effective. Kanban translates to ‘visual signal’ and was pioneered on the floors of Toyota plants back in the fifties. Most people will use Kanban to give the team and folks outside of the team insight on the progress of work. Boards like the one below can be seen in almost every agile shop out there:

Kanban Board 1

Unfortunately, for most teams, that’s where the utilization of Kanban ends. This is a shame. If you end with just the visual representation of the work moving from stage to stage you are missing out on the critical improvements that Kanban can offer you and your team. As you dive deeper you realize that much of the benefit of Kanban comes from identifying and eliminating bottlenecks.

One of the ways to tell if you have bottlenecks is to identify where most of your cards are backing up on your Kanban board. If most of your cards are in your backlog (to do) or sitting in Done, this isn’t much of a problem for your team. If however, most of your cards end up sitting in develop or test for most of the sprint right up until the last day: you’ve got WIP problems.

WIP problems typically fall into two categories: context switching and process problems. These categories have a ton of overlap, so we’ll talk about both together.

Set fixed limits for WIP

In a previous life, one of the teams I worked with had six devs, three QA and a product owner. Our rule for this group was the team could only have six WIP cards that were between the backlog and the done swim lanes.

The reaction to this early on was unexpected. The developers complained that they would be sitting on their hands a lot waiting. Granted, there was some hand sitting but not nearly as much as you would think. Instead, the team gelled better than ever before. A lot of agile teams pay lip service to the idea that no matter the task, the whole team pitches in to move product through the pipeline. So dev will help with QA, QA will help with requirements definition, etc. The sad reality is that these teams almost always get siloed. Developers just work on dev and QA just works on quality.

What happened with our team after instituting very strict WIP limits is that the devs got a lot more involved with the QA process and helped test other developer’s stories. In doing that testing, they gained a much better understanding of how QA was writing test cases. Most QA folks can’t code so QA didn’t implement any stories but the QA team got much more involved in the definition of these stories. Our devs also learned how valuable a good unit test is.

In the end, the numbers told the final story. That team went from an average push rate (work items being pushed at the end of a sprint) of 17% to under 5%. And their overall velocity increased by 10%. What we found was that keeping the whole team focused on a small number of items at one time caused us to move a lot faster. Less is more when you limit context switching.

You will need to play around with what your WIP limits are but err on the side of less work items at first. Even though it may feel like some people are sitting around waiting to work, people generally like to work. Chances are, you will find them helping out with other jobs and understanding the process as a whole a lot better. You will also quickly identify your bottlenecks. For us, the bottleneck was QA. Having developers finish more stories was only backing up the QA machine in the production line. Having dev help out with QA made everyone faster.

Segregate the issues coming in from the field

Another issue that can completely destroy your team’s productivity is adding work items to the sprint after the sprint has started. This is agile 101. Most of you know this and know that most product owners would never dare to add a new work item mid sprint. But what happens when a defect comes in from the field? This issue turns out to be bad enough that the customer is genuinely pissed off and now you have your CEO breathing down your neck.

The most effective way I’ve found to deal with this issue is to build a dev support team. We had a rotating dev support team that was made up of one developer with another on back up. The person on the dev support team was only on that team for two sprints at a time. Then they would move to the backup position. When they were the primary support dev, their only job was to handle issues coming in from the field. When there were no issues coming in from the field, they would fix defects. They were never assigned story work.

This is another great anti-silo approach. This forces all of your developers to become familiar with the entire codebase. It also shows you as a leader, how your different devs react to stress.

What if I’m on a custom software team?

If you’re building custom software for clients, context switching comes with the territory. It can be managed but not eliminated. The most effective custom or outsource teams that I have worked with manage this in a couple of ways. First, they budget for the context switching costs. Most of these teams have been doing this long enough that they understand the impact of context switching WAY better than product development teams so they incorporate it into their estimates. They also mitigate some of the risk by trying to keep their resources on one project and only one project as long as they can. When that is not a possibility, the best outsource teams that I have worked with try to limit their resources to working on only one project per day. It’s easier to rebuild that mental architecture if you only have to do it once per day.

Conclusion

None of us can multi-task effectively which is why context switching is such a killer. Acknowledging that multi-tasking is the problem is the first step in the healing process. The more you can eliminate context switching from your life and the lives of your team, the more productive you will be. This is part one of the context switching topic wherein we covered the mechanics of context switching in the agile product cycle. In the next post we will cover the other big context switching time thief, meetings.