Disciplined Agile

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:

1. Every team is unique and faces a unique situation.
2. You want to have a common vision as to how you’re going to work together.
3. You want to streamline how you work together.
4. You may actually need to document your process.

The article covers the following topics in detail:

1. Why process tailoring?
2. When do you run process tailoring workshops?
3. The risks associated with process tailoring workshops
4. Planning a process tailoring workshop
5. What should you tailor?
6. Running a process tailoring workshop
7. Documenting the results

I hope you find it useful.

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.