You’ve gone to the classes. You’ve passed the test. You have your Scrummaster certification. Now what?
When it comes time to move past merely understanding scrum in principle and having to implement it in practice, most development teams quickly realize they still have a lot of questions that need answering. The temptation at these points is to simply continue going through the motions.
Unfortunately, agile development isn’t one of those areas where the best thing to do is swallow your doubts and forge ahead. Poorly managed agile projects are often bigger disasters than poorly managed waterfall projects.
To some degree, the open questions are by design. Within the scrum framework, there are many opportunities to tailor your processes to the specific circumstances of the project. That means no two teams will ever be—nor should they try to be—exactly the same in their approach to agile development.
Still, there are some issues nearly every team runs into as it’s honing its own processes and learning how best to implement them. Not every team will have as much difficulty with every one of these obstacles, but if you have any experience at all with scrum, we’ll wager you recognize elements from all of the descriptions below.
We’ll try to take them on sequentially, but keep in mind they can arise at various times. And some of them, like budgets, present challenges at every stage.
Scrum provides a framework that, once mastered at the team level, leads to a much higher likelihood of project success. This is because, first and foremost, scrum results in software with more value to the company. But, if you want to see these results, you’ll need to go beyond simple adherence to the prescribed practices and get at the underlying principles.
Let’s take one of the ceremonies as an example: the sprint planning meeting. For the next two weeks (or thereabouts), your team is going to be working on developing a small component of the overall project, and these meetings are when you determine what precisely each team member will be doing.
Simple enough, right? But there are a couple questions you need to answer before holding these meetings:
There’s a case to be made for inviting everyone from business stakeholders to the entire development team, including Quality Assurance. And there’s a case for having everybody show up with nothing but a blank sheet of paper to jot down notes.
You need to be aware, however, that inviting everyone and having them show up emptyhanded is a formula for starting over again from scratch at the outset of every project iteration. It’s about as agile as you can get, but it’s also apt to get chaotic (and managing the budget and timeline will be murder).
Different circumstances call for different answers to these questions, but we’ve found things go more smoothly when we work out who will get invited to each meeting upfront—as in, before the project kickoff.
Also as part of the preliminaries, we work out the process whereby each participant will seek input and approval from any key players whose buy-in is important but who won’t need to attend every meeting. The participants can then bring this input on what the sprint should focus on to each planning meeting. That way, everyone gets a say, but there aren’t too many cats to corral.
Before the start of a project, we also tend to work out a high-level plan of where we’ll be going over the course of the ensuing iterations. You can think of this as establishing a destination for your next trip and having a rough idea for a route before you get started. You’ll probably make some adjustments along the way based on minute-by-minute road conditions—or scenic detours—but you won’t be re-envisioning the entire trip from scratch every time you stop for gas.
How detailed of a plan each participant should bring to sprint planning is likewise a matter of balancing priorities. If the whole thing is planned to the minutest detail beforehand, then you’re doing waterfall, not agile. But if you have no idea where you’re going or how you’re going to get there, well, the accounting people will probably be paying you a visit. (More on this point below.)
Now, these are just a few of the basic questions that come up for just one of the ceremonies. You’ll be faced with several more decisions like these as you arrive at all the other routine stages of a sprint.
When accountants first hear about agile development, they often think the IT people are trying to trick them into signing over a blank check. The question of how you manage the budget is tied to the question of how detailed your initial plans are before getting into the first sprint.
But having a highly detailed plan is no guarantee against budget overruns—the frequency of change orders or major rebuilds being the main impetus behind the widespread adoption of agile methodologies in the first place. So, here again, we’re asking what the proper balance is.
The high-level plan for where the project is ultimately headed should serve as the foundation for your original budget estimates. The people on the dev side work out the main business priorities for the application through discussions with people on the client side. Then the team gives the accountants their best projection for what it’ll cost to achieve all those priorities.
The mistake beginning scrum teams often make is losing sight of the budget waterline after they’ve worked out that original estimate. The product owner describes a new feature during sprint planning, and the team follows through on the request. The project is agile after all; there are supposed to be ideas for new features, or other revisions to the product backlog, cropping up as you progress.
But then one day, either you or the product owner opens a file and discovers that you’re on course to go way over the negotiated budget, without achieving all the main priorities that were established at the outset.
No big deal, right? Just have the product owner go to the CFO and ask for more money. Of course, doing this confirms what the accounting people suspected all along, that scrum is really a trick to get them to sign off on an open-ended spend.
What more experienced scrum teams do instead is incorporate budget impact into their discussions of backlog revisions. Rather than simply listening to the product owner and saying, “Sure, we’ll do that next,” they’re more apt to say something like, “Sure, we can do that, but then we may not be able to get to this other priority feature before using up all the funds.”
To get to this point, though, your team needs to have the tools to accurately track progress. They need to have a keen sense of how changes to the backlog will affect the timeline. Beyond that, the role of developers must change somewhat as they participate more in these discussions of backlog adjustments and their downstream impact.
You know you’re supposed to focus on user stories and delivering business value. But at some point your team is going to have to sit down and write some code. By the time you figure out how to turn an abstract concept like a user story into a detailed description of a software feature, well, you have something that looks a lot like a requirements list.
You can call them acceptance criteria, and you can tackle them in two-week intervals. But this isn’t exactly agile; you’re still checking requirements off a list. On the other hand, if you demo a feature to the product owner without ever having specified what it should do and how it should work, you risk having to go back to the drawing board after every sprint.
The best scrum teams have a system in place for gathering and keeping track of acceptance criteria. But the important thing when it comes to descriptions of functionality is to align expectations between the people on the client side, particularly the product owner, and the people on the development side.
Here again, we’ve found the best approach is to work off of a high-level plan and use both our grooming process, in which the product owner plays a central role, and our sprint planning to come up with a list of detail-level criteria. One of the dangers to look out for here is that many people, even many IT people, have vastly different definitions of agile.
It’s critical for product owners to know exactly what role they’ll be playing in backlog grooming, sprint planning, demos, and user acceptance tests. If your agile isn’t the same as my agile, we need to work out a compromise before moving forward.
For more on user stories and functional requirements, check out: What Experienced Scrum Teams Wish They'd Known about User Stories from the Start
Testing is a tricky topic when you’re doing agile because there are so many questions you have to answer.
There’s no hard-and-fast answer to any of these, but you’ll need to address them one way or another. In general, we’ve found that the earlier you involve the QA specialists the better. The main reason for this is that agile defines quality in terms of business value, so the QA people should know what goals the feature will ultimately be serving.
We’ve also found that Test-Driven Development ends up more than making up for the time you spend on coding the unit tests. This is primarily because the cost of fixing buggy code later is usually orders of magnitude higher than the cost of fixing it sooner. TDD helps you avoid baking in a heavy burden of technical debt. And testing in general, automated or otherwise, both early and often helps to keep small problems from turning into big catastrophes.
For more on QA in Scrum, check out: Are You Doing Waterfall Quality Assurance for Your Scrum Software Project?
When it comes to measuring the performance of scrum team members, it seems like most of us are still living in the early 20th Century. Widgets created per unit of time—that’s how Frederick Taylor measured workers’ productivity. In the context of an assembly line, that’s all you really need to measure: volume and speed.
Many scrum team managers likewise start out trying to measure productivity in terms of velocity. But, if one developer completes two points in a sprint while another completes ten, you can’t conclude the one has added any more value to the project than the other. In fact, you’d probably better check the code the faster developer wrote for bugs.
Using speed and volume as proxies for developer or team performance makes no sense when you’re doing agile development. So how do you keep everyone accountable? It can begin with something as simple as a Kanban board, which lets the whole team see who’s doing what and how well the project as a whole is progressing. But that’s not usually enough.
One of the team performance metrics we’ve been using, one that’s gaining popularity especially among DevOps teams, is the C/A percentage. The C stands for complete and the A stands for accurate. You’re essentially factoring a proxy for quality into your measure of speed, putting the one data point into the context of the other and thus making them both more meaningful. And you could of course factor in still more context using different measures. The important point to keep in mind is that there is no single metric that can tell you everything you need to know.
As with all the other questions you’re working out answers for, you have to experiment to determine what works best for your team and what works best for each project.
Also check out: