2019 — Tim Casasola — Tim Casasola

Originally published on Sanctuary Computer’s Medium publication.

When it comes to choosing a framework, I’m cautious of comparisons.

“Agile is better than waterfall!”

“Kanban is more effective than Scrum!”

“Trello is better than JIRA!”

I enjoy exploring the similarities, differences, and nuances between frameworks, but comparison seems to lack discussion around what problem we want the framework to solve. Debating scrum vs kanban is pointless if we aren’t aligned on our goal. Do we want to deploy software more frequently? Increase our throughput? Respond to changing requirements in a less costly way? We’re otherwise arguing why cauliflower is better than broccoli when we’ve yet to decide what’s on the menu.

Framework debates also take forever. And they often result in indecision or escalation (as well frustration and intelligence theatre). Who wants a three-hour meeting with no end decision made?

What I’m not suggesting is to treat frameworks like silver bullets. Be skeptical when you read yet another article written by a Big 3 consultancy about Spotify’s Squads Model. Or when you’re told that your team is “not doing scrum right” by someone who’s scrum master certified.

What I am suggesting is this: instead of choosing a framework, pick a practice from a framework and map it to an outcome.

Choosing Practices Instead of Frameworks

The next time your team discusses what framework to use, ask this:

“What practice from this framework will help us reach the outcome we want?”

There are three impactful parts to this idea:

It prompts us to start with the outcome.Our instinct as people is to start with the solution (Trello vs JIRA) instead of the outcome (increasing our throughout, identifying blockers more quickly). However, aligning on the outcome gives us a shared goal to ideate towards.
It lowers the barrier for your team to experiment with new ways of working. Trying sprint planning meetings or biweekly retrospectives is much less daunting than being tasked by your boss to get Scrum certified because he wants your team to fully adopt Scrum.
It makes pivoting from failure less costly. A friend of mine who works at a tech company we all know and love mentioned to me that a colleague of his went through six reorgs in the past three years. Six reorgs in the past three years. If we discover that the practice didn’t give us the outcome we want, we can easily adjust our approach. Full framework implementations, on the other hand, are irreversible.

Even Banks Can Be “Agile”: An Example of This in Practice

I was once contracted by a financial services company to help them work in more adaptive ways.

Like many banks, this one was embarking an “agile transformation.” Agile, in their context, was a customer-centric, iterative, and co-creative way of working that challenged their linear, command-and-control, and process-driven ways.

While their ambition to become more agile was laudable, “agile” also meant different things to different people. Some believed it meant having a “Product Owner” and a “Scrum Master” for every team. Others believed it meant having a specific workflow (backlog -> this week -> in progress -> ready for review). Others believed it meant doing work faster even at the expense of quality (yikes!).

My team and I knew we had to steer clear from this language. Rather than implementing a full-scale intervention, we invited teams to try three practices: action meetings, strategy statements, and integrative decision-making. We based these choices on four desire outcomes they identified:

Decreasing the need for meetings.
Getting more input from the folks being affected by decisions being made by management.
Decreasing the time it takes to make a decision.
Increasing the shared understanding of strategy.

After our pilot teams experimented with these three practices, we saw some differences. Meetings were both more productive and inclusive. Decisions were made more quickly and inclusively. Escalations decreased, and folks reported feeling more empowered. The company’s strategy was clearer to more people. And some of the toughest skeptics became the biggest champions of these practices.

By identifying outcomes and picking practices that served these outcomes, the bank unlocked change much more quickly than if they were to do an agile transformation writ large.

Frameworks come and go

While this bank perceived it as a new way of working, agile methods can be traced back to as far as 1957. Some say agile is ending. Original signers of the agile manifesto say that it’s dead and that it’s become big business. Others still defend that it isn’t dead.

How is that one group of folks consider agile to be an innovative way of working while others consider it to be dead? My suspicion is that frameworks follow a similar adoption pattern to technology.

At the risk of pulling out another framework, the technology adoption life cycle can help us understand this:

It suggests that when it comes to people adopting new technology, we fall into one of the five groups above.

If we were to think of agile as a “technology,” agile’s critics would likely be innovators or early adopters, while our bank would fall into the late majority.

Applying this technique in practice

If we aligned on an outcome and picked a practice, our discussions would be much easier:

Will trying a design sprint help us invalidate our hypotheses faster than how we invalidate them today? Yes? Cool, let’s pick a project we can try this on.
Will a Sprint Planning Meeting improve our ability to respond to changing requirements? Great, let’s try it.
Will skipping wireframing and going straight into visual design allow us to deliver good design work faster? Nope? Let’s kill the idea, then.
Will doing a pre-mortem at the beginning of our projects help us better meet our deadlines? Yes? Let’s get one on the calendar.

For open-minded teams, set up an experiments workflow

If you have an open-minded team who is stoked to try new practices — great! Now your job is to help them visualize this work and establish WIP (work in progress) limits.

There’s a temptation for open-minded teams to try tons of practices. However, trying too many at once can lead to chaos and not reaping the full benefit of each practice. Trying new practices is an experiment, and experiments need a workflow.

Kanban, a workflow methodology made famous by Toyota, encourages two principles:

Visualize your work
Limit work in progress (WIP)

By visualizing our work, teams reduce confusion and duplicative efforts. By agreeing on what our work in progress limits are, teams prevent overload and stay focused.

From what we’ve observed, Kanban is a common way for product teams to set up their workflow. This is why we encourage teams who are stoked to try new ways of working to design an experiments workflow. A good example is PopcornFlow:

The workflow would start with noticing problems. We then generate options for tackling those problems, craft them into possible experiments, and actually pick one or two to commit to based on the experiment’s impact and feasibility. We’d set a WIP limit on the amount of experiments we committed to and experiments that are ongoing. We’d then assess whether the experiment achieved the outcome we wanted and decide what to do next based on what we learned.

Regardless of whether you use Popcorn Flow as your experiments workflow, the point is to establish some way to visualize your experiments and limit experiments in progress—especially if you’re an open-minded team.

There is no right way

Implementing a framework off the shelf sparks useless debate. If we pull practices from frameworks, we get clear on our shared goals, lower the barrier for experimentation, and make failure less costly.

Let’s take every framework for what it is: a frame to work within. As statistician George E. P. Box remarked:

“All models are wrong, but some are useful.”

Every framework is flawed in some way. It’s up to us to discover what’s useful for our unique context.

Thank you Matt Strom, Josh Petersel, and Hugh Francis for your feedback on earlier drafts of this piece! And thank you Darin Buzon for the rad first image.