Evolving With Our Clients: The Great Scrumban Experiment

Identifying the need for change

In early 2016, Metal Toad fully adopted Agile Scrum methodology. We'd been dabbling in it for a while, coopting some of the ceremonies but lacking any real consistency or a well-defined process. That served us well enough for a few years, but in a growth organization committed to maturing both our processes and our client relationships, it just wasn't enough. We understood that a change needed to occur, and as Metal Toad is want to do, we jumped in with both feet.

By all objective measures, going Agile has been a success. It has allowed us to be more productive as a company, more predictable for our customers, and for our development teams to feel significantly more supported. It's a powerful thing to see morale and output increase as a result of our willingness to evolve.

Toward the middle of the year, we ran into our first major snag with our scrum model: we were underserving our ongoing support and maintenance clients. Scrum is a tremendously useful framework for managing active projects. Active projects have a beginning and an end, allowing for a consistent sprint-to-sprint cadence. Support work is far more unpredictable, particularly when individual teams are managing sometimes a dozen-or-more support engagements in addition to active project work. Even the best juggler can only keep so many balls in the air.

If Agile teaches us anything, it's that iteration isn't something to be feared. Our clients made it clear that they needed more from us. A faster turnaround time for development work, greater overall output each month, and more flexibility in getting their time sensitive needs prioritized and resolved. It was time to evolve again.

Getting on the same page

The first step in implementing scrumban was agreeing on a definition. What is scrumban? Like other Agile disciplines, scrumban is a broad term for any process that marries the flexibility of scrum methodology with the first-in-first-out sensibilities of kanban. Some Agile teams meld these related methodologies by simply applying WIP limits to the various issues statuses, or by planning for commitment variances in their sprints based on changing priorities. The permutations are limitless, and within that incredible space, we found our individual approach.

As I hinted at earlier, Metal Toad’s contracts roughly fall into two broad categories. We have active projects with defined timelines, budgets, and scopes. These are inherently waterfall in nature, but iteration and scope horsetrading is welcome. Afterall, a project that doesn’t meet the needs of our clients isn’t really successful even if it does stay within the iron triangle. By retaining the general size of the scope, but allowing iteration therein, we retain timeline and budget while pivoting with our clients. If the methodology wasn’t meant to be dynamic, it wouldn’t be called “agile”.

The other contract category is ongoing maintenance and support. These are clients that have an existing product, most often built by us, that they wish to continue maintaining and enhancing. The work that falls under these support engagements varies widely, anywhere from user documentation to security updates to entirely new features. The clients that enter support arrangements with Metal Toad also vary, particularly in terms of their level of service needs. For those clients that move at the speed of retail, serve an engaged fanbase, react to Hollywood’s changing landscape, or simply want their vision realized quickly, we developed our own flavor of scrumban to meet their needs.

Putting theory into practice

We piloted scrumban with our biggest development team, Team TMNT, because nearly all Drupal support contracts fall under their purview. To prove out scrumban, it needed to touch many clients, increase the team’s overall productivity, and return measurable results. Like all things Agile at Metal Toad, we started by building a better JIRA process.

TMNT was utilizing a single scrum board that filtered individual project boards into one intimidating marass. Active project work and support issues were treated equally with support naturally taking a backseat to project work when push came to shove. During backlog grooming and estimation, TMNT would size all of the issues. With so many stakeholders represented on the same board, these were daunting meetings that stretched on for hours. Progressing against such a large backlog was nearly impossible.

Sprint planning was no better. These were long affairs where the enormity of the work meant support issues got the short end of the stick. It was triage in every sense of the word: whichever client was shouting the loudest got a seat on the boat. Everyone else had to wait for the next sprint, which was just as crowded as the last. Putting it mildly, it was a completely unsustainable cadence that we tried to make work for several months.

Innovating a new approach was was necessary to provide an outstanding experience to our clients. The first thing we did was peel all those support client projects off into their own JIRA board. We had a scrum board for active projects and a kanban board for support. As luck would have it, Altassian built a new feature into their kanban board view: the kanban backlog. This turned out to be a critical feature for the pilot in that it allowed the project management team to prioritize issues on the fly and only serve up to the team what was ready for development.

We also adjusted the grooming and estimation process, deciding that only the active projects board really needed that level of scrutiny. We continued to size tickets as a team, but without the noise of support tickets filling the backlog, these meetings shortened significantly. From a tools perspective, we were set up for success.

Iteration, iteration, iteration

Building an efficient workflow from these JIRA boards was a process unto itself. The key for us as project managers, and defacto product owners for our support contract clients, was prioritization. We kept revisiting the same question: how do you we let our development team know that tickets are on deck for them to begin working? It turned out that the answer was in the question: we create an On Deck status and make that the first column in the kanban board.

This had two benefits. One, it allowed multiple project managers to prioritize their clients' needs in a transparent and visual way. The other key benefit was that it focused the backlog so that the team wasn’t overwhelmed with so many issues showing all at once. This was terrific for morale as it presented a list of deliverables that was achievable. We extended this idea of achievability by imposing a WIP limit on the On Deck status. If our development team had to scroll to see the entire On Deck list, it was too long.

We also iterated in the way we used swimlanes to flag high priority issues. By making careful use of issue priorities and building an applicable swimlane, any issue that was of Major or Critical priority rose right to the top. There were certainly those that abused the visibility of this swimlane, myself chief among the guilty, but after coming to an agreement on how these priorities should be defined in this context, even this became intuitive.

Building a coalition

None of these mechanisms would have been successful without a team to support the process. In practice, our approach to scrumban meant splitting the team into a two subteams: a project team and a support team. They would still participate in all scrum ceremonies together and of course back each other up as needed, but a natural division would be present nonetheless. This was the part of implementing this process that we dreaded the most. The members of TMNT are more than just colleagues, and nothing triggers PTSD in the dev pit more than the idea of siloed developers.

We were thoughtful and careful thanks in large part to TMNT’s born-for-this team lead, Slavko Pesic. His genius solution was to allow the subteams to rotate as needed. If someone on the support team felt burnt out or simply wanted to spend some time working on an active project, or vice versa, that’s entirely okay. We try to keep these rotations on a two week sprint schedule just to avoid confusion, but the freedom to chose is always there.

An additional benefit was having the ability to size the project and support teams according to the contractual and budgetary needs. Rather than dealing with the overhead of six developers grinding on a particular project, we set the project subteam to a size that the budget could maintain. That afforded us significantly better budget control.

Even with all these morale safeguards in place, maintaining team cohesion has been key. Everyone attends morning standup together, everyone participates in backlog grooming, and everyone contributes to sprint planning and retro. Treating the team as equals helped solidify the notion that support work isn’t less-than. We’re all striving toward the same end as one cohesive unit.

Putting a W on the board

We’re still measuring the results of our great experiment, but I can happily report the following facts:

• The team did not openly revolt

• We’ve achieved our contracted number of support hours for our clients for the first time in months

• Metal Toad’s support clients are happier than they’ve ever been

• Our active project enjoyed an almost identical velocity despite limiting the number of developers

That last point illustrates an important benefit. By creating this soft division and carefully resourcing the subteams, we effectively reduced context switching across the board. The project team was able to focus almost entirely on the active project without having to endure a lot of extra noise. The concept of the Mythical Man Month clearly came into play here as well. We were simply more efficient having the right subteam sizes.

What comes next is further iteration. We need to get a good production deploy process down so that it isn’t so disruptive, we have a new project coming online next sprint which will require a different mix of project and support subteam talent, we need to keep an eye on team morale and connectedness so we don’t lose the vital camaraderie we’ve built, and we need to continue carefully managing support priorities so we don’t overwhelm the team.

Look for more findings and metrics in part 2.