Disciplined Agile

One of the iconic movies of the 1980s was The Breakfast Club, which told the story of five very different teenagers who were forced to come into school one Saturday to serve detention.  Recently I’ve been working at a large insurance company helping them to adopt the Disciplined Agile (DA) toolkit.  One of people whom I’m working with has a Breakfast Club poster on the wall near her work area and it got me thinking about some of the dynamics that I’ve seen watching agile teams form and eventually gel.  Here are my thoughts.

At the start of the movie the kids didn’t really like each other, they were very different from one another, they certainly didn’t want to be there, and they were each coming to the group with their own point of view and background.  Sadly, I’ve seen more than one software project team that was put together like this.  As the movie progressed they began to really talk with one another and their stories started to emerge.  They started to work together, hijinks ensued, and they bonded as a group.  As part of their punishment they were each asked to write an essay describing what they learned from their detention.  Instead they wrote a single letter, which follows, that they submitted as a team.

“Dear Mr. Vernon:

We accept the fact that we had to sacrifice a whole Saturday in detention for whatever it was we did wrong, but we think you’re crazy to make us write an essay telling you who we think we are. You see us as you want to see us… In the simplest terms and the most convenient definitions. But what we found out is that each one of us is a brain… …and an athlete… …and a basket case… …a princess… …and a criminal.

Does that answer your question? Sincerely yours, the Breakfast Club."

So how does this relate to agile teams?

1. You often build teams from specialists.  Although we ideally recommend that you build teams from multi-disciplinary, T-skilled generalizing specialists, the reality is that many organizations are staffed with specialized people.  We like to say that you go to war with the army that you’ve got, or in other words you need to make do with what you have.  If all you have are specialized staff then that’s the people you have to form teams.  The good news is that you can help people to evolve from being specialists into generalizing specialists via building a cross-functional whole team, enabling and promote non-solo collaborative work within the team, and by training and coaching people.
2. It takes time for a team to gel.  In the movie the “team” gelled in a single day, but it’s rarely that fast in practice.  It often takes weeks, and sometimes months, for a team to really get to the point where they’re working together effectively (yet another reason to move towards stable solution delivery teams).
3. Co-location shortens the time it takes to gel.  When we’re co-located, everyone works together in the same room, it is much easier and much more likely that we will collaborate with one another.  Not only does this increased interaction help us to get the work done it also helps us to gel as a team faster.
4. We’re not as different from each other as we think.  One of the lessons that the kids learned in the movie is that each one of them had a bit of an athlete, a brain, a criminal, and so on in them.  Similarly, we’re not just programmers, or architects, or analysts but instead we all have some of those skills in us and we can certainly get better at the skills that we are weak on.
5. We are still different.  Every single person is a unique individual.  This implies that we must be flexible in the way that we collaborate with one another, that people simply aren’t “cogs in the corporate machine.”  We should also respect the fact that we each bring something of value to the team, a revelation that the kids in the movie stumbled upon when they had to work together to not get caught by Mr. Vernon (there were a few hijinks in the movie).
6. Working together as a team produces better results than a group of individuals.  As Alistair Cockburn likes to say, software development is a team sport.  In the movie the kids all got caught doing something on their own, hence the punishment of a Saturday in detention, yet together they managed to have a fair bit of fun as a team.  Similarly, you may be the best programmer in the world, but it behooves you to work with people who can help you to understand the requirements, design the solution, validate the solution, and so on.
7. We can all learn from each other.  Everyone has value to bring to the team and everyone has areas where they are weak on that could be improved.  By working closely together we can learn from each other and get better both as individuals and as a team.

The Breakfast Club is a great movie.  If you haven’t seen it, or haven’t seen it lately, then I highly suggest watching it again.

We have recently posted an update to The Disciplined Agile Manifesto.  In particular, we simplified the wording of the three principles (reduce technical debt, visualize workflow, multi-modal organizations) that we added to extend the original Manifesto for Agile Software Development.  We describe the updates to each of the three principles, and our thinking behind them, below.

Reduce Technical Debt

Original: #13. Leverage and evolve the assets within your organizational ecosystem, and collaborate with the people responsible for those assets to do so.

Update: #13. Leverage and evolve the assets within your enterprise, collaborating with the people responsible for those assets to do so.

The primary change here is the use of the term enterprise instead of organizational ecosystem. Over the years we had several people point out that they weren’t comfortable with that term or that they found it overly complex.

Visualize Workflow

Original: #14. Visualize workflow to help achieve a smooth flow of delivery while keeping work in progress to a minimum.

Update: #14. Visualize work to produce a smooth delivery flow and keep work-in-progress (WIP) to a minimum.

This principle was reworded to make it more action oriented and to clearly point out the term WIP.

Multi-Modal Organizations

Original: #15. The organizational ecosystem must evolve to reflect and enhance the efforts of agile teams, yet be sufficiently flexible to still support non-agile or hybrid teams.

Update: #15. Evolve the enterprise to support agile, non-agile, and hybrid teams.

As you can see we simplified this principle greatly, using enterprise instead of organizational ecosystem as above and going straight to the point of supporting multiple ways of working.

A process blade encompasses a cohesive part of your overall organizational way of working (WoW). Each process blade addresses a specific organizational capability, such as Data Management, Continuous Improvement, or Vendor Management. Process blades are sometimes called process areas, key process areas (KPAs), or business functions. 

In September 2016 InfoQ published an interview, Benefits of Agile Transformation at Barclays, with Jonathon Smart and Ian Dugmore of Barclays in the UK.  The interview summarizes the experiences of adopting Disciplined Agile (DA) strategies within Barclays.  Some of the key points made in the interview include:

• Barclays is a large financial institution with over 130,000 employees that has been in operation for over 325 years
• Barclays is taking a holistic approach to their agile transformation, it is not just a technology thing, linking up their various “islands of agility” to reduce the impedance mismatch between them
• Barclays has the equivalent of over 800 agile teams that have adopted DA approaches in progress
• They considered SAFe, LeSS and DA and settled on DA as it is not a “one-size fits all” approach
• They needed to change both their funding and measurement strategies
• Results include: A 300% increase in throughput (note: measured in terms of story delivery); 50% reduction in code complexity; test code coverage increase by 50%; More than half of teams are deploying into production at least monthly; Improved team happiness/morale; Improved business outcomes such as quicker time to market

The source article is definitely a very interesting read.  

This brief article explains our thinking around our terminology choices in the Disciplined Agile (DA) toolkit. It overviews the terminology principles that we follow, discusses why Scrum terminology isn’t appropriate, and maps common Scrum terms to DA terms.

Our Principles Around Terminology

The following three principles drive our terminology decisions:

1. Terms must be clear. If you need to explain the term, it likely isn’t the best. For example, how many times have you had to explain what a Scrum meeting is? Call it a coordination meeting instead, and people have a much better idea of what’s going on.
2. Terms must be method neutral. Every team is unique and owns its own process. Part of owning your process is choosing the overall method, or lifecycle, that you’re following. Because the DA toolkit is a hybrid that leverages a variety of methods, were we to adopt one method’s terminology over another it would only make sense for people following that lifecycle. For example, Scrum terminology makes sense if you’re following the Scrum-based Agile/Basic lifecycle but not the Lean Continuous Delivery lifecycle.
3. Terms should already be in use elsewhere. We are not in the business of creating new terms when existing ones are perfectly fine.

The Problem with Scrum Terminology

Many people ask us why we don’t simply use Scrum terminology. We originally wanted to, because that would be the easy thing to do, but we quickly realized that Scrum terminology just doesn’t get the job done for three reasons:

1. It doesn’t apply in all situations. For example, the term “sprint retrospective” doesn’t really make sense when you’re following a lean lifecycle that doesn’t have the concept of sprints/iterations. Furthermore, it breaks principle #3 above in that the Scrum folks tacked “sprint “onto the front of the existing term “retrospective” to brand it with Scrum marketing.
2. It was motivated by marketing reasons. The Scrum originators purposely chose unusual terms such as sprint, Scrum Master (later concatenated to ScrumMaster), and Scrum meeting to signal to people that Scrum was different. Well, in DA we’re purposely choosing pragmatic terminology to signal to people that it’s time to up our game as software professionals.
3. It reflects 1990s thinking. There’s nothing wrong with that per se, other than the fact that we have learned a lot the following decades that we can apply.

Mapping Scrum to Disciplined Agile Terms

The following table maps common Scrum terms to the terms that we prefer in DA. As you can see, the mapping is very straightforward.

Parting Thoughts

There is no standard terminology in the agile world, nor will their ever be. Your team, as part of owning your process, will need to decide which terms they prefer to use. We’ve seen many DA teams choose to use Scrum terminology (e.g. sprint instead of iteration) because they originally started with Scrum and that’s what they’re familiar with. That’s their decision and as always our advice is for a team to do what they believe to be right for the situation that they find themselves in.