Recommended
More Related Content
Recently uploaded
Recently uploaded (20)
Featured
Featured (20)
Twice the Burnout in Half the Time: How not to Plan a Sprint
- 1. Twice the Burnout in Half the Time HOW NOT TO PLAN A SPRINT @jonfazzaro
- 18. Agile?
- 19. 🐎💩 Agile.
- 32. VALUE DEBT
- 37. Update Logic in GravyPourer Add IsPoured column to Gravy table Write unit tests for GravyPourer
- 39. Track whether the gravy has been poured Alert the user if there is no more gravy to pour Automatically refill the gravy boat
- 45. You’ve got this.
- 51. Twice the Burnout in Half the Time HOW NOT TO PLAN A SPRINT @jonfazzaro
Editor's Notes
- So, I’m here to talk about Scrum.
- Hm. No thunderous applause. That’s right. Here we are at a capital-A Agile conference. And I’m not repping anything hipper than that. No organizational culture change. No shiny new scaling framework. No microservices. Nope. Scrum. Because there’s still something to say, 20+ years in.
- What’s left to say, though? I mean, we’ve got this, right? We’ve got it down. Stand up, Planning, Review, and Retrospective. Burn down that backlog two weeks at a time. Simple. Scrum is simple. But simple doesn’t equal easy. Simple doesn't equal valuable. Here, let me show you a simple sprint planning meeting. (Presented, btw, with nothing but the finest google image stock photography, so, you know. Buckle up.)
- "Welcome to the sprint planning meeting, everyone!”
- “Now, the business is pretty disappointed in our velocity from last sprint, so let’s dig deep and put in some extra hours to see if we can’t get that up this time. Make them feel like they’re getting their money’s worth.” “Also, as you know, we’ve got the trade show coming up right on the tail of this sprint…”
- “So, that means our Sprint Goal is to finish the rest of these features.”
- ”Okay. Let’s talk capacity. Now, we had few surprises last sprint with those sick days. Is everyone feeling better?” “Is anyone taking any time off? Bob and Steve, both on Thursday. Got it.” “Okay. So we’ve got Bob, Steve, other Steve, and Mary, for ten days each, minus two. Let’s see, that’s eight hours per day, times 38. 304 hours. Right?” “Yes, Mary?”
- "We were going to try to write unit tests again this sprint. Is that a thing we should plan for?”
- “So, these are the stories that have to get done. And I need you to commit to them. Not to writing tests, those are for you.”
- “Well, and who has time to write tests now, with all of the bugs we have to fix?” “And those bugs will have to wait, too. We have functionality to build out.”
- “Those stories are over 550 hours worth of work, according to our estimates. And we only have 300 hours of capacity.”
- ”Look, I don’t know why we are even doing this. There’s a trade show, these features have to be in there, the business has been firm about that. If there’s this much work to get done, what are we doing in this meeting? You could be coding right now!”
- “Okay, so we’ll plan to finish all the stories, put a freeze on bugs, no tests, and… go from there. Does everyone agree to the plan?”
- What happens after a planning meeting like that? You know what happens.
- The team breaks their backs to try to get everything done. Works the weekend. Maybe they even come close to succeeding.
- But in the process, they introduce at least as many bugs as stories they finish. And those are just the bugs QA has found so far.
- And the same scene plays out again in the next planning meeting, two weeks hence. The team thinks this mess is the product owner’s fault. The stakeholders think the team is incompetent. More than one VP thinks IT is a cost center that should be outsourced.
- Is this agile? Sure. I mean, if that’s what the kids are calling it these days.
- I’d prepend a few adjectives. Scrum is a framework for agile behavior. It's a framework not of answers, but of questions and conversations.
- Is it any wonder that we’re in a dysfunctional place with Scrum? Contents of this book notwithstanding, this title sends a hell of a message. More, better, faster. How do we move forward? It’s not the framework. It’s how we’re using it. I am picking on the planning meeting today because it’s the place to start when your project is a tire fire. it has the most impact, because it’s where you set expectations and try new things. The planning meeting is the one that causes the most pain when it goes wrong. There’s a lot we could do better. I’m up here, and I’m still not great at this. But I do have three things I want you to stop doing when you plan a sprint.
- Heads x hours x days equals capacity? Is that your team’s capacity? Is that what you should plan to? That is 100% of your team’s time. Is the goal here 100% utilization? Of course it is. The company pays you for every minute of that time, don’t they? Here’s the problem, though.
- This is what 100% utilization looks like. Now, as taxpayers, we know we paid for all of that asphalt. But is occupying every inch of it how we get our money's worth? This isn’t a highway. This is a parking lot. When you work out how many hours your people are in the office, and you seek to fill that time with work, this is your goal. Busyness is your goal. Busyness != productivity. And all of the value your team could be delivering is trapped somewhere in the middle of this. Well, okay then. How about instead of 8h, we put some padding in there? Let’s plan for 6 hours instead. Anybody doing this at their company? Well, that’s better mechanically. But it completely misses the point. It’s hard to explain to the company that pays the people on your team for 8 hours of work. It looks like a fudge factor to cover for the fact that they’re simply bad at our jobs. That we can’t/won’t just get 8 hours of work done in a day. That sends the wrong message. That’s enough rearranging the deck chairs on the Titanic. Let’s stop just fine-tuning the wrong idea. Let’s zoom out.
- Hours*heads*days is a way to measure capacity for manual work. At the risk of being super-reductive, you can plan for turning bolts on an assembly line by counting hours/heads/days.
- But to build software, we don’t just sit down and type out code. We hold conversations, write user stories, Ask questions, debate ideas, Rewrite stories, And occasionally type in some code and test it. All of these activities contribute to the right code getting written. Only the right code is valuable. Software is not Manual Work. It is Knowledge Work. Knowledge work capacity is so much more complex than how long your team is sitting at their desks typing. Ironically, it is simpler to measure than hours at the desk.
- Just count. Count how much the team got done last time. Last time, they held conversations, Wrote user stories, Asked questions, Debated ideas, Rewrote stories, And occasionally typed in some code and tested it. They did the work of software. And it took the time it took to get it done. The number we get to takes into account the full complexity of the work, and that makes it hard data on what you can expect in the next iteration.
- Sprint 4, the team finishes 2 stories and fixes 7 bugs. So, how many work items should we plan for Sprint 5?
- 9? If we plan for 9 more stories, we may hit it. But something doesn’t smell right about that. Bugs are work, for sure.
- Work != value This incentivizes the team to be sloppy. If we ship loads of bugs to fix next time, we could have the highest velocity you’ve ever seen without delivering any value. That backlog we’re trying to plan is full of stories that represent value. This is a good way to measure work. But what we really want to measure is how much value the team can deliver in a sprint.
- So, if it’s value we want, let’s only count valuable work items.
- Only count the stories.
- That means we ask for ONLY TWO STORIES in the next sprint plan. What? I'll get fired! No, you won't. Hold your ground, point to the data. This is about building trust. And building trust where there isn’t any comes down to setting expectations. Plan for two stories, while setting the clear expectation that once you're done with those stories you will continue to ask for new stories, not sit on your hands. Parkinson’s law only applies in low-visibility, low-trust environments.
- This is how a team finds its true velocity. And a true velocity is data you can trust when you’re trying to predict what a complex system like a knowledge work team is going to do next. This is not a performance metric as much as it is a planning tool. The team delivers value in the form of completed user stories, slices of new features delivered in working software. We don’t count bug fixes and other technical debt toward this velocity, though, because debt is a force that works opposite to value. We can count on bugs being fixed. Count on sloppy code being cleaned up. Count on testing gaps to be closed. This is also part of the work of software, and it does take time to do. But it is best measured as value not delivered. The team will want to fix them, and so will the PO. Any time spent fixing bugs takes away from time spent on valuable story work, and this incentivizes the team to pursue enough quality to keep the value flowing. Speaking of which.
- The only way to go fast is to go well. Clean code with good automated test coverage brings a stability and predictability to the work of software. But this doesn’t come for free—this work has a cost. Quality is expensive. Not doing this work is more expensive. It feels efficient, because the team is not putting that up-front, conscious effort into writing and maintaining tests, automating builds and deployments, and refactoring code. But if you add up the costs of unplanned work--bug fixes, context switching, fragility--it’s obvious which side of this thing you want to be on. In light of this, you would think that skipping the tests would be unattractive to your stakeholders.
- But your stakeholders have beer goggles for skipping the tests. They’re under pressure, and they see relief from that pressure. They see the short-term gain. And because they are human beings, they discount the long-term cost. They frame this in assertions like…
- “I'm not paying you to write tests. Clean code is for the developers. We have business value to deliver.” “Let’s just get through this sprint, we can do the tests later.” Oh, your mean old boss just doesn't get it. Now, if you're not on board with practices like TDD, you've got a whole other problem. But your boss/client/muse may not be on board. And that's nothing for them to be bashful about--this is a counterintuitive aspect of software development that, frankly, it's not their job to get. Not right away. In general, this is behavior you want to encourage. Every project has a budget, and every PO needs to ensure that that project stays on budget. They are naturally and rightfully looking for fat that can be trimmed in order to do this. They are thinking in an agile way. It's in your hands, our hands, to shepherd them through this complex process, to help them fall into the pit of success. As part of that fall, we should never knowingly present an option that we know will take the work in the wrong direction.
- Let’s talk about healthcare. Doctors probably spend hours every day, scrubbing their hands up the elbow. Can you imagine the cost savings for our bloated healthcare industry if they just, you know, skipped all that? And yet, as a patient, you’ve never been asked. You’ve never seen a box on a form in a doctor’s office for a hygiene option. Your doctor would never offer you a “no-hand-washing” discount. Why, then, would we ever leave it up to a Product Owner, manager, or project stakeholder whether we include the work of quality? Whether we practice good code hygiene?
- We communicate what can be trimmed by how we divide the work. When we divide it along technical lines, we force the PO to make technical choices in order to keep the project on track. This is not their area of expertise.
- Putting them in the position to make these choices presents a host of conflicts of interest, each with its own damage to the end product.
- When we divide the project work along functional value lines, as with well-written user stories, we keep them in their area of expertise. No one knows what stories the product needs next better than the PO. No one knows what practices the code needs better than the team.
- Remember when I told you to count your stories? I didn’t say estimate. That’s weird.
- I mean, how would a count help us if we had a sprint of big stories, and then a sprint of small stories? There’s no question that some stories are bigger than others. But most of the time, we can do something about it.
- Big user stories are usually made of several smaller stories stacked on top of each other to get into R-rated movies. If we can spot one of these and break it down before we plan it into a sprint, we win on a couple of fronts. Your stories are more consistent in size, making your effort to forecast by velocity more accurate. The PO gets more control over what doesn’t get built yet. This makes features ship sooner. This makes user feedback available earlier. This eliminates waste.
- What does this look like in practice? Before you plan a story, read it aloud to the PO, and discuss its acceptance criteria. When you do this, the PO may suggest additional criteria. Most of the time, these additional criteria are new stories trying to stow away. This is the gold-plating. When there’s a ”this too” request, write a new story, and add it to the product backlog. Split your stories by value. Look for “and”, “or”, or wording that is awkwardly generic, stretching to include multiple cases which could go separately. Awkward phrasing is a telltale smell of a clustered user story.
- This applies to the code, too. If a small MVC web app that saves state to a file will do the job, don’t build a hive of microservices.
- So that’s what I’ve got for you today…
- But hang on…
- There’s one more thing.
- If there’s anything you’re doing as part of sprint planning that doesn’t have to do with delivering value, rolling with change, or building trust, stop doing it. More on that here: http://blog.apterainc.com/value-change-and-trust