At the XP2019 conference in Montreal I had the privilege of giving the opening keynote. The title of my keynote was “#NoFrameworks: How We Can Take Agile Back” and if you click on the link you can access my slides on SlideShare.net. My keynote worked through the following topics:
During my keynote Ankur Saini created a sketch note and as you can see below he’s been kind enough to share it with us. This blog explores the key ideas captured in the sketch (click on it to enlarge).
There are a collection of points about frameworks, most of which question the value of frameworks:
To summarize, there are many very good reasons to question the value of “agile scaling frameworks.” We can do better. We must do better.
As you can see in the picture above I made several suggestions for taking agile back:
The message that I left the conference attendees was this: Start where you are, do the best that you can in the situation that you find yourself in, and always strive to learn and get better. Becoming agile doesn’t have to be hard.
A fundamental philosophy of agile is that teams should be allowed to own their process, to choose their way of working (WoW). In Disciplined Agile (DA) we take it one step further with the idea that teams should not only be allowed to choose their WoW, they should be supported and enabled in doing so. In other words, let’s help teams to be awesome.
Figure 1 depicts the workflow for how a team can choose and then evolve their WoW. The workflow shows four key activities that a team will iteratively work through as they need. In this blog we focus on initially choosing your team’s WoW.
Figure 1. The workflow for choosing and evolving your WoW (click to enlarge).
When adopting your initial WoW, the first thing to do is to identify whether you team is allowed to choose its WoW or whether one has been chosen for them. Let’s start by exploring how you would proceed if you’re allowed to choose your own WoW.
Tailoring Your Initial WoW
When a team is allowed to choose its own WoW the first step is to select the appropriate lifecycle given the situation faced by the team. Lifecycles, in some ways, are “methods” in that they show the high-level workflow for a team. They are the glue that combines detailed techniques/practices into a coherent whole (more on this below). Disciplined Agile Delivery (DAD) supports several lifecycles:
Although the focus of DA is on agile and lean ways of working, DA recognizes that in some cases you may still decide to adopt a waterfall/serial lifecycle. DA doesn’t explicitly support waterfall, but as you can see in Figure 2 we do recognize that in very low-risk situations a traditional approach makes sense.
Figure 2. A flowchart summarizing how to choose a lifecycle (click to enlarge).
Your lifecycle will of course evolve, either incrementally via normal evolution of your WoW or because your team explicitly decides to adopt a different one (once they’ve learned more about themselves as a team).
Once your team has chosen an initial lifecycle, the next is to select the detailed techniques that you’re going to follow as a team. This is typically done as a series of process tailoring workshops where the team works through the appropriate goal diagrams to identify how they want to work together. Figure 3 depicts the goal diagram for Secure Funding, you can see how it walks you through the decision points that you need to consider and potential techniques for addressing those decision points. Don’t worry, if you’re not familiar with all of the options they are described in the book Choose Your WoW!, with a description and the trade-offs associated with each technique summarized in tables. Knowing your options, and the trade-offs associated with them, enables your team to make better process decisions (which in turn leads to better process outcomes). This is something we call guided continuous improvement.
Figure 3. The Secure Funding process goal (click to enlarge).
In theory it’s possible to do a single “big bang” process tailoring workshop when a team is in initially formed, but we’ve found that leads to process bloat because the team has to guess at too many things all at once. Unless you’re in a regulatory environment requiring defined process descriptions up front, it’s usually better to tailor your WoW in stages on an as-needed basis.
Adopt Existing Method or Framework
In some organizations teams are still not allowed to choose their WoW. This may happen for several reasons:
The problem with forcing a team to follow an existing method or framework, no matter how popular it is, is that it rarely fits the situation faced by the team. It might be a great method, but it’s the wrong one for the team – context counts, every team is unique and faces a unique situation, so should be allowed to choose and evolve their own WoW to enable them to be as effective as they can be. Think of it like this: If a team is competent enough to build a solution for their stakeholders, surely they must also be competent enough (perhaps given a bit of help) to choose their own WoW?
Regardless of whether you were allowed to choose your initial WoW or had one forced upon your team, this is only a start. Your team will still want to evolve your WoW as you learn and as your situation evolves. More on this in our next blog.
A fundamental philosophy of agile is that teams should own their own process, or as we like to say in Disciplined Agile (DA) teams should choose their way of working (WoW). Of course this is easier said than done in practice. The challenge is that every team is unique and faces a unique situation – in other words, context counts. Furthermore, there are no “best practices,” rather, every practice has tradeoffs and works well in some situations and poorly in others. Worse yet, you really don’t know how well a technique will work for you until you actually try it out in your environment. Given all of this, how can a team choose its WoW?
Since the 1980s the lean community has shown that an effective way to evolve your process is to do so as a series of small incremental improvements, a strategy called kaizen. Numerous organizations have taken this approach over the years, and virtually every single DevOps success story is based on a multi-year kaizen-based continuous improvement strategy. Figure 1 depicts the workflow of implementing a single improvement, with Deming’s Plan-Do-Study-Act (PDSA) loop on the right-hand side to indicate the iterative nature of the overall process.
Figure 1. Running an experiment to evolve your WoW (click to enlarge).
Let’s explore each step one at a time:
Figure 2 shows how your team’s effectiveness improves over time with a continuous improvement approach. When you experiment with a new technique and it works out well for your team then your team effectiveness improves. When an experiment “fails” your team effectiveness dips for a bit – the technique didn’t work well in your situation – but then you end the experiment and go back to your previous way of working (your team’s level of effectiveness goes back to where it was).
Figure 2. Experiment to evolve your WoW (click to enlarge).
When you keep at it, when you adopt a kaizen mindset, your team effectiveness increases over time as we see in Figure 3. The figure also shows that when you first adopt a continuous improvement strategy that your team effectiveness drops at first because you’re learning how to follow the continuous improvement process of Figure 1. In many ways you begin this improvement journey by experimenting with this experimentation-based strategy.
Figure 3. Continuous improvement over time (click to enlarge).
Some organizations struggle with the idea of experimentation, likely because they still believe in the idea of “best practices” and often because they’re looking for an easy answer. They’re afraid to experiment because they might “fail,” not realizing that a failed experiment teaches you what doesn’t work for your team given your current situation. Running small, “safe to fail” experiments is absolutely critical for improving your WoW.
Where this blog overviewed the strategy of Continuous Improvement, in the next blog in this series we will see how better decisions lead to better outcomes via Guided Continuous Improvement. Stay tuned!
For more information about choosing and evolving your WoW, we humbly suggest that you consider reading our book Choose Your WoW! A Disciplined Agile Delivery Handbook for Optimizing Your Way of Working. If you want to succeed at enterprise agile you need choices, not prescriptions.
Disciplined Agile and SEMAT
I’m happy to announce that the Disciplined Agile Consortium (DAC) is now working with SEMAT. SEMAT, Software Engineering Method and Theory, is an international community of people, companies, and universities. Led by Ivar Jacobson, SEMAT is working together to create a common ground, or kernel, for software engineering. As you may know I am one of the original signatories who first indicated their support for the SEMAT effort and am currently a member of the SEMAT advisory board.
So why are we working with SEMAT? We hope to gain several benefits:
Of course it is still early days and there is a lot to do. Please stay tuned here for further updates!
I recently wrote a detailed article about process tailoring workshops. In a process tailoring workshop a coach or team lead walks the team through important aspects of the delivery process and the team discusses how they’re going to work together. This typically includes choosing a lifecycle, walking through the process goals one at a time and addressing the decision points of each one, and discussing roles and responsibilities.
There are several reasons why you want to tailor your team’s process:
The article covers the following topics in detail:
I hope you find it useful.