Disciplined Agile

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”.  My keynote worked through the following topics:

1. A mea culpa where I walked through my work in method and frameworks over the past two decades.
2. What is a framework?
3. What problems do we have with process frameworks/methods?
4. Why are frameworks so popular?
5. Some industry stats on how effective frameworks are in practice
6. What actually works in practice?
7. How we can take agile back?

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:

1. Leadership often adopts a framework because others are doing it. I hate to say it, but we often see agile frameworks, in particular SAFe, get adopted simply because other organizations are doing it. There seems to be less concern about whether the framework is a good fit, or even if it solves a problem the organization actually has, compared with whether others have adopted it (so therefore it must be a good idea).  In short, adoption of the framework often does more harm than good.
2. Developers like frameworks because of the easy certifications. What’s not to like about becoming a certified master after taking a two-day workshop, or a program consultant after a four day workshop? Back in the distant past (the 1980s) I had to go to school for four years just to get a job as a junior programmer.  But, if you adopt an agile method or framework, you can become certified in it in just a few days of training!  In short, the frameworks enable people to present themselves as more qualified than they actually are, and motivate them to think that they know more than they do, which more often than not leads to trouble later on.
3. Vendors like frameworks because it’s easy to support a single way of working (WoW).  Most tool vendors like well-defined, popular methods/frameworks because it makes it clear to them what functionality they should implement.  Prescriptive frameworks are particularly attractive because the tool vendor only has to implement a single way of working (WoW), reducing their development effort.  Cha-ching!
4. Consultants like frameworks because they’re easy to learn.  Prescriptive frameworks supported by certifications that you “earn” in just a few short days enable consultants with little experience in agile to present themselves are experts and even expensive coaches to the unwary and gullible.  Cha-ching!  And consulting organizations can swiftly build up an army of such consultants quickly in order to staff huge teams at their clients.  Cha-ching cha-ching!
5. Frameworks put you in method prison.  As Ivar Jacobson warns us about, we quickly find ourselves in method prison with prescriptive agile methods and frameworks that give you a limited way of doing things.  You’re often told that they’re flexible and can be tailored to meet your needs, but then they leave that very hard work up to you. The problem with this is that when organizations hit the limits of what the framework addresses, and the knowledge of their “certified experts,” that they either become disillusioned with agile or they find themselves on the very expensive path of extending the framework on their own.
6. Are frameworks right for you? I asked several questions to get people to realize the challenges surrounding frameworks.  These questions included: What if the rules (of the framework) don’t apply to your situation?  What if the situation changes?  What if the framework solves a problem that you don’t actually have? What if the framework solves the problem and you find yourself in a new situation? For methods/frameworks that tell you that you can tailor them, what do you do if you don’t know what the available options (practices/techniques) are?  What if you don’t know how to compare the options?
7. Are you joining a cult? When I was putting the keynote together I went looking for possible definitions of frameworks.  I noticed that they were suspiciously close to the definition of a cult.
8. Frameworks are not silver bullets. Regardless of the marketing promises, or more often than not the perceptions left by marketing promises, there are no easy answers to your process and culture-related problems.  It takes hard work to improve your WoW, you don’t just “install” a new method/framework and in a few short months you’re agile. In short, the purveyors of methods and frameworks often set very unrealistic expectations.
9. There is no best practice that applies to all situations. Every practice is contextual in nature, there are no “best practices” that apply in all situations.  Similarly, many of the “bad practices” that agile purists rail against (but hey, it’s not a cult) do in fact make sense in some situations (yes, there are often better practices available).  Sadly, many people are of the mindset “just tell me the best practices I need to adopt” and the frameworks/methods cater to that very attitude.  People willing put themselves into method prison.
10. Focus on the apex predators. A common question that we ask executives when we’re working with them to help adopt new WoW in their organizations is “Who keeps you up at night?  What organizations are you afraid of competing against?”  It’s been years since a banker, for example, has told us that they’re afraid of other banks.  We often hear that they’re afraid of having to compete against Amazon, Google, or fintechs.  They’re afraid of these organizations because they’re hyper-competitive “apex predators.”  We then ask them how these organizations became apex predators, whether the executive believes they adopted an “agile scaling” framework like SAFe, LeSS, or Nexus to do so.  When the executive says no, of course not, that’s when we can have an intelligent conversation about process improvement. In short, if the scary competitors, the apex predators, aren’t adopting these frameworks it should give you reason to pause.
11. Learn and improve through experimentation. In case study after case study after case study you learn that apex predators, the hyper competitive organizations that everyone respects and fears became so through continuous process improvement via small changes.  This is often called a kaizen loop.  You can speed up process improvement via a technique we call guided continuous improvement (GCI). Doesn’t it make more sense to act in a similar way that the apex predators act?
12. Improvement is a journey, not a project. An important lesson that we can take from the apex predators is that they all have learned that process improvement is a long-term journey, one that never ends.  Many of them may have started this journey with an improvement project, but the successful ones all learned that this was only just a good start.
13. You can only go to war with the army that you have.  You have likely staffed up your organization in a manner that reflects “the old rules” or your old way of working.  Part of improving your way of working (WoW) is investing in your staff to help them gain a new mindset and new skills. You need to help turn the people that you have into the people that you need.
14. No need for reinventing the wheel. Although every person, every team, and every organization is unique that doesn’t mean that you need to develop your own WoW from scratch.  There are thousands of great techniques out there that have been implemented by thousands (if not more) of teams around the world. You can also learn and apply these techniques too, combining them in a unique manner to address your unique situation.  Yes, you may stumble onto a completely new technique at some point.  Great, please share that with us.  But 99.99% of the time you’ll be following techniques that others have followed before you. Have the humility to recognize this and actively choose to learn from the experiences of others rather than take the long and expensive path of figuring out everything on your own. The DA toolkit can help with this.

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:

1. Respect yourself. The first step to addressing the meaningless certifications within the agile community is for people to push back against them. If you’re going to get certified in something then make sure that it’s a certification that you earn, not buy. It takes years to become proficient at something, not days of training.
2. Go back to fundamentals. A fundamental concept from the early days of agile was that we would work to learn and improve over time.  This is what the lean strategy of kaizen loops are all about and certainly what GCI is all about.
3. Be humble. The problems and challenges that you face today have been solved by many people who have come before you.  We can choose to learn from these people, to adopt and extend their strategies.
4. Be agnostic. We can learn a lot from the various frameworks and methods (and other sources of information) that are out there. Treat them all with respect, and take what you can from each. Spend a bit of time with the Disciplined Agile (DA) toolkit and you’ll quickly discover that we’ve already done a lot of that hard work for you.
5. #NoBestPractices. As I pointed out above, all practices are contextual in nature – they have advantages, they have disadvantages, they work well in some situations and poorly in others.  Our latest book, Choose Your WoW!, puts hundreds of agile and lean techniques into context, enabling you to identify strategies that are likely to work for you in the context that you face.
6. Start where you are. Whatever you’re doing today – be it following a traditional approach, or a Scrum-based one, or one based on SAFe, or something else – that’s where you’re starting from.  Adopt GCI to begin improving from base, and you’ll soon find that you’re working your way out of method prison to a much better future.
7. Observe, think, experiment. We need to observe what situation we’re in, think critically about what we face and about how we can improve, and then experiment with new WoW to see what works for us in our context.
8. Optimize the whole. We need to get better at looking at the bigger picture.  For developers we need to look beyond programming to DevOps, to IT, and to the business as a whole.  For business people, because everyone organization is a software organization now, we need to invest time to understand how IT works. We need to streamline at least our overall value stream that we’re part of and better yet our organization as a whole.

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.

While working with organizations to help them to learn how to improve their way of working (WoW), we’ve developed a technique that we call guided continuous improvement (GCI).  Adopting an agile method such as Scrum, or a framework such as SAFe, may give you an initial start at improving your WoW you will quickly find yourself in “method prison.” The organizations that break out of method prison do so with a kaizen-based continuous improvement approach, or better yet GCI.

First, some definitions:

• A kaizen loop is an approach where a team experiments with a small change in their WoW, adopting the change if it works in their given context and abandoning it if it doesn’t.
• Continuous improvement is the act of applying a series of kaizen loops to improve your WoW over time.
• Guided continuous improvement (GCI) extends the kaizen loop strategy to use proven guidance to help teams identify techniques that are likely to work in their context.  This increases the percentage of successful experiments and thereby increases the overall rate of process improvement.

In the article we go into the details of the technique, exploring:

• Why every team is unique
• Why agile methods/frameworks will only get you so far
• How to apply a kaizen-based improvement strategy
• How to improve kaizen loops with the DA toolkit
• How to break out of “method prison”

We hope you find the article to be a game changer for your agile adoption efforts.

Terraforming is the act of making an environment suitable for human habitation.  Terraforming has been popularized in science fiction as the act of evolving a planetary ecosystem, but in our context terraforming is the act of evolving your team’s physical workspace to make it more habitable for you to work.  Doing so in an important enabler for improving your way of working (WoW).

The Evolve Way of Working (WoW) process goal, the diagram for which is shown in Figure 1, involves several decision points that are pertinent to terraforming. In Disciplined Agile (DA) our philosophy is that teams should choose and evolve their WoW over time as they learn, and an important aspect of doing so is to recognize that you should be able to evolve your physical as well as virtual workspace.

Figure 1. The Evolve Way of Working (WoW) process goal diagram (click to expand).

As you’d expect, you have choices available to you.  In Figure 1 there are three decision points relevant to terraforming:

1. Organize Physical Environment. There are many options for organizing your physical environment.  A key issue is that you want people to be as close to one another as possible – the further away you are from someone the less likely you are to interact with one another, and the harder it becomes to share ideas and information. Ideally you want your team to have its own work room or at least be in a common open area together.  Having said that, it’s still useful to have “caves” or separate collaboration areas where people can escape to as needed to focus their efforts.
2. Choose Communication Styles. Some people are leery of work rooms or common workspaces because they’re afraid that they won’t be able to concentrate due to the noise.  There has in fact been numerous studies that show that productivity drops when people are forced to work in open work areas or worse yet “hoteling” desks.  Yes, this is definitely a problem.  However, it is vitally important to differentiate between the noise generated by people who aren’t working on your team and the information/discussions generated by those who are. In short, I want to hear what my fellow teammates are saying but not what the stranger beside me is. When your office is organized in an “open” manner we’ve found that you should strive to have everyone on your team is sitting together.  Furthermore, erect sound barriers (such as sound-proof whiteboards or moveable walls) between you and the other teams near by to provide further focus.  And speaking about whiteboards, you can never have too many.
3. Choose Collaboration Styles. The more flexible your physical workspace the greater your ability to collaborate with one another in an effective manner.

We’ve found that a great strategy for a company is to make physical things such as furniture and whiteboards readily available to teams.  Something as simple as a room full of (currently) unused furniture that a team can simply take from, or contribute things they’re no longer using into, goes a long way to providing flexibility.  And of course allowing teams to buy what they need, when they need it, is also crucial.  Smart organizations realize thatone of the best investments they’ll ever make is to spend a few thousand dollars on furniture and whiteboards to enable a team of people earning five or six figure annual incomes to improve their WoW.

Ideas for this blog was adapted from the book Choose Your WoW! This book is a handbook overviewing hundreds of agnostic techniques and strategies that agile and lean teams may decide to experiment with to see how well they work in the situation that they face.

Mark and I are lucky enough to spend a few weeks in India this March.  In addition to speaking at Agile India 2019 we’ll also be running several Disciplined Agile workshops and a user group presentation one evening.  Here is our schedule in both Pune and Bengaluru.

Pune:

• March 16&17.  Workshop – Implementing Disciplined Agile Delivery.  Delivered by Mark Lines.  This is our new workshop that works through how to use the DA toolkit to choose and then evolve your way of working (WoW).  You’ll learn how to break out of “method prison” if you’ve hit the limits of Scrum or SAFe, and more importantly how to take an agile approach in an enterprise-class setting.  This isn’t “purist agile” but instead is pragmatic and agnostic.

Bengaluru:

• March 19. Conference Presentation – Choose Your WoW! How Agile Software Teams Can Optimize their Way of Working. Presented by Scott Ambler.  This presentation goes into how your team can implement kaizen improvement loops effectively by taking a guided continuous improvement approach through applying the DA toolkit.
• March 20. Conference Presentation – Agile Transformations: The Good, the Bad, and The Ugly. Presented by Mark Lines and Scott Ambler. We’ve been helping organizations to improve their way of working (WoW) for years.  In this presentation we’ll share our experiences regarding what works and what doesn’t work in practice.
• March 20. User Group Presentation – Choose Your WoW! How Agile Teams Can Optimize Their Way of Working. Hosted by Mark Lines and Scott Ambler. This presentation goes into how your team can implement kaizen improvement loops effectively by taking a guided continuous improvement approach through applying the DA toolkit.  Get your questions answered for how to break out of the “method prison” you likely find yourself in with Scrum or SAFe.
• March 23. Workshop – Disciplined Agile in a Nutshell. Delivered by Mark Lines and Scott Ambler.  This is a quick overview of Disciplined Agile Delivery (DAD) and the DA toolkit.  This is a great way to come up to speed on DA and to prepare for the DA certification test.
• March 24-25. Workshop – Implementing Disciplined Agile Delivery. Delivered by Mark Lines and Scott Ambler.This is our new workshop that works through how to use the DA toolkit to choose and then evolve your way of working (WoW).  You’ll learn how to break out of “method prison” if you’ve hit the limits of Scrum or SAFe, and more importantly how to take an agile approach in an enterprise-class setting.  This isn’t “purist agile” but instead is pragmatic and agnostic.

If you’re based in India we hope you can make it out to one or more of these events.  If you have colleagues in India please pass this along to them as this may be a great chance for them to learn about DA from the source!

Choosing your way of working (WoW) isn’t just a one-time event, instead it is an ongoing effort.  Figure 1 shows the workflow for choosing and then evolving your WoW.  In our previous blog, Choosing Your Initial Way of Working (WoW), we worked through the left-hand side of Figure 1.  In this blog we explore how a team evolves their WoW via a series of experiments, hopefully ones that are guided by the Disciplined Agile (DA) toolkit.

Figure 1. The workflow for choosing and evolving your WoW.

As you can see in Figure 1, evolving your WoW is a two-step process at a high-level.  First, you identify that you have a potential issue with your current WoW and second you experiment with one or more potential improvements that you believe will address the issue that you’ve identified.  And of course you repeat this strategy whenever needed.

Identify Potential Process Issue

There are various ways that a team can identify a potential process issue:

1. Retrospectives. Retrospectives are a strategy for a team to reflect upon what is working well for them and what isn’t working so well. Some teams, particularly agile ones, will choose to hold a retrospective at the end of each iteration/sprint whereas lean teams tend to hold them on an as needed basis.  Regardless, one of the outputs of such a working session is a list of one or more potential issues the team wants to address.
2. Someone recognizes there’s an issue. Sometimes it’s as simple as someone saying “Hey, I think that X is a problem. Is there anything we can do about it?”
3. Someone from outside the team points it out. It can also be as simple as someone from outside of the team – one of your stakeholders, a colleague on another team, a leader within your organization, or others – identifying a potential issue.

The point is that there are multiple ways that potential issues are identified.  So what are you going to do about them?

Experiment with Potential Improvement(s)

For any process issues that you believe you can address, the next step is to experiment with one or more potential solutions. Experiment?  What?!?!?!?!  That’s right, experiment. Any given practice works well in some situations but not in others.  Just because a technique worked well for another team, maybe even one that you’ve worked on in the past, that doesn’t mean that it will work well for your team in the context of the situation that you currently face. There is no such thing as a best practice, regardless of the endless marketing you may have heard telling you otherwise.

What you need to do as a team is to identify ways that you can potentially address an issue, narrow down your options, and see how well a given technique works for you by trying it out in practice.  In other words, you need to run an experiment.  Figure 2 depicts a continuous improvement loop, also known as a “kaizen loop,” where you choose a technique to experiment with, you try it for a sufficient amount of time to determine whether it works for you, and then you decide what aspects of the technique (if any) you should keep and which you should abandon.  And if you’re enterprise aware your team will share your learnings with others.  Guided continuous improvement takes this one step further by employing the DA toolkit to help identify potential new WoW for you to experiment with that is more likely to work for you, thereby increasing your team’s rate of improvement.  Better decisions lead to better outcomes.

Figure 2. Guided continuous improvement.

An Example

Let’s consider an example.  We’ve been working together as a team for several months, have released the initial version of our solution into production, and have been working on our next release for about a month.  Our Team Lead has informed us that we’ve coming to the end of the funding for the team.  When we formed the team we received funding for a 6-month project, following our company’s fixed cost approach to funding solution delivery teams.  Our team expanded in size so that we could become a complete, whole team, and a side effect of that is that after a bit more than 4 months we’ve run out of money.  This is a problem that the team needs to address.

Terry, our Team Lead, gathers the team to work through the issue.  The first thing we do is discuss whether this is an issue that we can even influence.  The Team Lead believes that we can because our organization’s leadership is very happy with our work and can see the value in the product that we’re working on.  Because they have been receiving advice from an Executive Agile Coach they are beginning to realize that the way that they fund teams needs to evolve. Terry believes that our team is in a position to suggest, and then experiment with, a new approach to funding.

As a team we discuss what we need to do, realizing that there are really two issues commingled here: First, we’re funding a project, not the actual team.  Second, we’re taking a fixed-price approach. Carlos, our Agile Coach, suggests that we review the options captured by the Secure Funding process goal, the goal diagram for which is shown in Figure 3. It indicates that both project-based funding and fixed-price funding are the least effective options for agile teams, and more importantly it also indicates that there are better options available to us.  We look up the trade-offs associated with the options in our copies of Choose Your WoW! and after a bit of heated discussion agree that we should suggest to our management team that we adopt a stage-gate funding strategy for a product (long-lived) team.  Several of us wanted to push for a time-and-materials (T&M) approach, but we felt that would be a future improvement that we could experiment with once we’re successful with stage-gate funding.

Figure 3. The Secure Funding process goal diagram.

Terry, with the support of Polly (our Product Owner), manages to convince our senior managers to experiment with a new approach to financing.  Terry and Polly were able to describe the trade-offs associated with both the existing approach to funding and their suggested new approach. Interestingly, their suggestion was whole-heartedly supported by Florinda our finance officer.  She’s been concerned for several years about the way that IT projects have been funded, and is eager to move from a cost-based funding model towards one focused on investing our company’s money wisely. Our team was given the go-ahead to try the new funding strategy.

Sure enough, we run the experiment with stage-gate funding of a product team and it works well.  Our “stages” were three months in length, and after two rounds of such funding we successfully experimented with a T&M approach as we’d originally hoped.