By Daniil Barvitsky, Practice Leader
Scrum continues to be popular management methodology for software development projects. By some reports, 92 percent of teams that claim to use agile development methods use Scrum.
For those not familiar with the Scrum Framework, it was introduced in 1995 as a way for teams to collaborate in delivering software iteratively and incrementally, rather than using traditional waterfall (top-down) project management approaches. The work of Scrum teams is divided into time periods, typically a month or less, known as sprints, which are supposed to result in the creation of complete, working functionality for each sprint. The simplicity of the methodology has made it popular with software development teams and their clients.
While nearly every management methodology, including Scrum, has self-balancing practices to remain on track and induce results, the whole thing can fall apart pretty quickly if it is not implemented correctly, if teams operate in a vacuum, and steps or results are not integrated or are omitted. For example, teams that start doing agile can self-balance by equating quickly with quality. Conversely, the process can overwhelm problem solving and become a Möbius strip of efforts that lead nowhere.
The CTO of technology management consulting firm Ten Mile Square, Alden Hart, noted in a recent blog post that "Agile development (specifically Scrum) is not about engineering best practices, it's a project management discipline." Hart emphasized that companies employing it "need to get your best practices elsewhere and bring them to Agile. Once you do that, it's a really powerful combination."
Scrum is not an acronym. It actually comes from rugby, where it is an ordered player formation used to restart play. The forwards of a team line up with interlocked arms and their heads down and push forward as a wedge into a similar formation from the other side. In software development, there are key aspects to the scrum process, which, if omitted, can make the whole project formation fall apart in the long run. Particularly, there are several R's tied to any project management process, but, if you take an "R" out of your Scrum, the unpleasant results speak for themselves.
Here are several frequently omitted practices in projects, the key "R"s that without which you can wind up with unpleasant results:
"R" is for Responsibility. If Responsibility is lacking, sprint planning falls by the wayside. Stories wind up carried over from sprint to sprint without resolution. A key cornerstone to Scrum success is commitment, i.e. breaking the work into chunks you "die-hard promise" to deliver both at the team (via sprints) and individual levels (through tasks and stories). The methodology's "self-balancing" only works when people take personal responsibility for their role and the group's success seriously. In an old-school waterfall culture, common excuses for not delivering are when insufficient requirements were provided or the plan was unrealistic. For Scrum, you either commit and do, or you don't commit. If you commit to something, getting it done is your responsibility: pick the brain of the product owner, torture your architect, call a customer - do whatever it takes to deliver.
"R" is for Requirements. Do your stories look like "As X I want Y so that Z" with no further information? Alternatively, do your stories take more time to define than execute? There are two behavior patterns here that are detrimental to scrum success. People either believe they don't need requirements ("because we can always just ask Product Owner") or the opposite ("I need detailed behavioral requirements or no commitment."). The first spawns over-communication between a team and PO and creates delays waiting for clarifications. The second harkens back to overblown, overly precise requirements (those lengthy spreadsheets!) that preclude agility. Avoid formal, overly detailed requirements in agile. It's better to make them short and visual (narrative, storyboarding, with some business context, infographics that work through the process), and produce one document per epic. If need be, for documentation purposes, add a Q&A section under each requirement.
"R" is for Roadmap. You wouldn't go on a European road trip without a map to avoid going in circles. To see more, you need to know where you are going, what you might like to see at each stop, and the "nice to do" items if time and money allow. The same is true for your software development efforts. Too often, scrum teams wind up with a random looking backlog, half of which will never be done. A well-defined, prioritized backlog is a must have. It helps you know where you are on the road and the possible things to do. The backlog helps teams grasp where they are and where they need to go, especially along the way on a big project that's been started, with hundreds of stories or issues already created. To keep it under control, grooming must be a continuous task, so it's best to define all epics upfront and detail them as you go. In Mike Cohn's book on Agile Estimating and Planning, he notes "Agile planning balances the effort and investment in planning with the knowledge that we will revise the plan through the course of the project." Grooming and changes will happen, and you can assume given the velocity of the team that the roadmap needs grooming too.
NOTE: Include charts from outline here for visual emphasis.
"R" is for Real. Does your burn-down look like this?
Seriously? This burn-down chart is deceptive and unrealistic. This is no way to manage a project, but, all too often, this is what transpires:
The lesson here is to track the "real" work as it is done and not commit to start new efforts when you aren't ready or adequately staffed.
Here is another example:
Really? In this example, it's possible the team knew from the onset that they were not going to make it all along, but nobody either spoke up or cared. We hope not. Perhaps the team encountered impediments and bugs and didn't review the board or estimate. In either situation, you are better off being "real" and acknowledging and entering issues as they arise. The board should be an accurate snapshot and communications tool for the project's credibility and yours.
"R" is for ..err aRRRchitecture. Do you carry a lot of technical debt? Is refactoring taking 40 percent of your backlog? Does your team complain about or encounter bad code all over the place? Defining your architecture on the fly in ad-hoc mode is tantamount to malpractice. I am not advocating an analysis/paralysis or "big design first" approach; however, it is imperative to produce componentized design with the various component responsibilities and interactions outlined clearly before undertaking a serious development effort. Then ensure that everyone on the project understands and is on the same page about the principles of your application design and "the right way to do things." These things change rarely, and, if they do, you'd better be aware of the change you are incurring and act proactively.
"R" is for Rhythm and Ritual. Have you skipped a demo or two? Are you failing to update the board regularly? Are people skipping the stand-ups? Are your stand-ups running longer than 15 minutes? When was the last time you did a retrospective? Scrum is very sensitive to how regular your routine is. The "self-balancing" features in scrum only work when you regularly use the full methodology. Here are some ideas:
"R" is for Respect. Scrum comes with very strict responsibility boundaries for every role. The ScrumMaster should be a "servant leader" who helps the rest of the Scrum team follow the process. If a PO commits to delivering a backlog and fails miserably, or, if a team fails the sprint, assume they did their best and try to help them get back on track wherever possible. If that happens too often, respectfully replace people who are not up to par. Likewise, give your people credit and autonomy to determine how and when to get work done. As long as the team finishes its work by the deadline and under budget, give the team the respect and trust to determine how that happens.
"R" is for Ready for change. Does your PO wrestle with the team over new stories? Does the team skip top-priority stories in the backlog? Do you hear "it cannot be done" often? Are your estimates escalating significantly? These are all indications that the organization - or at least the scrum team - isn't ready for or accepting of the change being developed. Change management and its mismanagement is the bane of far too many software implementations. It's important to remember that change management isn't just about the end user or stakeholder. The Scrum teams working on the project must embrace the need for change, be willing to think differently, eliminate any sacred cows and acknowledge that anything can be improved upon.
Tech projects can be a lot of work and require a lot of hours. They can also be fun and rewarding. That requires solid management. Good managers, particularly when implementing a collaborative methodology like Scrum, need to support, encourage, reward, mentor and bolster their efforts. As noted above, this calls for Servant Leadership to ensure the scrum teams are allowed to and given what they need to succeed.
At the CIO or CTO level, scaling scrum to more teams requires ensuring dependencies and coordination is in place, but don't second guess efforts. Make sure your development teams are cross-functional and have all the necessary competencies. Let individuals be accountable and be there to coach and guide. Another best practice for larger Scrum efforts is to encourage the scrum teams to plan together to detect and iron out dependencies as early as possible.
Management needs to ensure that scrum teams deliver iteratively and incrementally. Make sure to support deliveries of "Done" efforts and make sure they know perfection is great, but delivering quality software that is valued by its users is the top priority for all.