Don’t adopt frameworks. Test practices.

Tim Casasola
Dec 13, 2019 · 6 min read

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:

  1. 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.

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:

  1. Decreasing the need for meetings.

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.

Image credits: John Cutler (Source)

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

Source

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.

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:

  1. Visualize your work

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, Hugh Francis, and Darin Buzon for your feedback on earlier drafts of this piece!

Sanctuary Computer Inc

The Safest Place on Earth.

Tim Casasola

Written by

Product + org development. Product Strategist at Sanctuary Computer. Sometimes a bboy. // timcasasola.com

Sanctuary Computer Inc

The Safest Place on Earth.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade