Transcending Scrum & Breaking Bad
Its been almost two years since FreshBooks switched from Waterfall software development to Agile Scrum. The transition to Scrum was a painful one, but by sticking with it, we feel we’re executing as a team now better than any time in our history. When we made the switch to Scrum, it came with consultants, training, and a very detailed user manual that explains all of the “rules of Scrum” and an edict that tells you that you must follow all of the rules or risk seeing your adoption of it fail.
We followed this edict for nearly two years. Eventually, some of our teams demonstrated (to themselves) they were ready and willing to move beyond the rules, so they began (and we supported them) to ‘break bad’ in order to move faster.
It’s important to understand that we are not purposely devolving out of scrum and into chaos. Many teams here continue to operate under strict Scrum rituals and artifacts, while they work themselves into capable and self-organizing teams. Once a team demonstrates (to themselves) that they can consistently deliver high quality code to production quickly, they take their own training wheels off and start moving faster.
As high performing teams deliberately break the rules of Scrum, we like to think of it as Transcending scrum. This may sound holier-than-thou, but we want to encourage other software development teams to let go of their fears, break the rules of Scrum, and know that the world (probably) won’t fall down around them. What we’ve learned is that many of the “rules” are in-place simply to ensure certain behaviours are exhibited by the team. But once those behaviours become natural tendencies, we remove the rules or change them, in order to focus more and move faster.
What are some of the rules we now break every day?
Velocity Reporting:
- What it was good for in the early days: Telling us the health of a team for that week. Attempting to spot trends in rising or decreasing velocities (which we were never able to do, and in hindsight was a fruitless effort).
- What’s Changed: Teams no longer report their velocity on a per-sprint basis at Sprint Reviews. We’ve replaced velocity reporting with specific delivery dates based on project Burn-ups. These Burn-Up reports include both backlog growth, and velocity to triangulate the most likely date we’ll be done with the project. We don’t show the Burn-ups, or the backlog growth at Sprint Reviews except in exceptional circumstances. We now are comfortable with the fact that teams are executing as fast as they possibly can, and just seek to understand the team’s prediction for when they’ll be done with the project.
- Why it’s Better: We spend less time fretting over an individual sprint’s performance. Bad things happen, teams go fast, go slow — it doesn’t really matter. What matters most is that the team is moving quickly, and predictably as measured over an average of several sprints, and that we understand the close relationship between velocity, scope creep, and ship-dates.
Stand-ups:
- What it was good for in the early days: Getting people to show up on-time for work, identifying blockers, getting people to talk about their work, keeping teams in-sync.
- What’s Changed: Stand-ups have become more ‘Sprint board centric’, focusing more on the status of work, and related blockers. They are more of a check-in for risk; are we at risk of not getting certain tasks to QA in time for testing? Are we at risk to complete our sprint stories/commitments? Do we need more eyes on certain Pull Requests’?
- Why it’s Better: We don’t need an artifice of questions to draw out the potential blockers and risks for the sprint. We’re able to spend less time talking around the issues, and more time talking directly about them.
Sprint Retrospectives:
- What they were good for in the early days: Micro-improvements to a team’s working processes.
- What’s Changed: Retrospectives have been expanded to be much more than mining for process improvements. They’re also used as opportunities to improve the team in other ways such as knowledge sharing, giving individuals opportunities to help others grow. We’ve learned that getting better isn’t always about fixing problems as they arise. It can be so much more and we’ve started to be creative in the retros to use that dedicated time for more.
- Why it’s Better: Eventually futzing around with micro-improvements becomes an exercise in process experimentation for experimentation sake. You waste time trying to get 1 point faster, when you could be spending that time to actually work, or focusing on bigger issues that would have more impact beyond process improvements.
Rules We Never Adopted, But Should Have:
Here are a few rules that we never adopted, know we should, but are having trouble adopting now because they aren’t part of our culture:
- Assigning User Value to all User Stories: We invest heavily in writing great user stories, and estimating their complexity using story points, but have trouble articulating the value we’re creating each sprint beyond what we see in the demo.
- All User Stories are thin slices of potentially shippable user value: We still have what we call “Developer stories”, which are not vertical slices, but rather chunks of work with no specific value to the user. We do this because we feel like it’s sometimes just faster to ship code in components rather than vertical slices. We know there may be some gold if we simply refuse to ship components and assemble them later, but again our culture has allowed the breaking of this rule for so long, it’s hard to see us attempting to enforce it.
One more thing about “rules” is that we were very fortunate in the beginning to have the support of the organization to adopt nearly every single aspect of Scrum from the very beginning. We were given carte-blanche to do away with all of our old ways of developing software so we could fully embrace Scrum, and were given several months to iterate and improve on our Scrum adoption. We cancelled all of our “project status” meetings, threw away the Gannt charts, and ended our “change management” process. My only regret at this point is not adopting every single rule from the beginning, and finding our way beyond them later, because we believe we may have developed some bad habits around things like “thin slices of customer value” and “highest ROI work gets built first” concepts.
What’s Most Interesting
The thing we’ve noticed since we’ve started to transcend the rules, is that the Principles of Scrum remain intact, but the Rituals and Artifacts of Scrum are what evolves. So if you’ve been practising Scrum for a while, and feel like you’ve gotten good at executing the mechanics of it… next time you find yourself in a Scrum Ritual or creating a Scrum Artifact, ask yourself if you can be moving faster by evolving those things while still being principle- based and focusing on what matters most to your company right now.
Casey McKinnon is the Head of Product @ FreshBooks.com
