The five stages of BDD (and Agile) Adoption

An article by John Ferguson Smart and Jan Molak.

More and more organisations are looking to Behaviour Driven Development (BDD) and related practices, as a way to gain or maintain their competitive advantage in software delivery. This is generally a good thing, and the teams I see that succeed in embracing a BDD and Agile mindset do reap huge benefits in terms of business value.

Teams that adopt BDD, and other Agile practices, typically go through a number of phases as their understanding evolves and their experience builds. Being familiar with these stages makes it easier to evaluate progress and streamline the adoption process.

A model of five levels

A typical BDD adoption process (and indeed, Agile adoption in general) goes through five quite distinct stages, or levels of maturity:

Folks familiar with learning models like the Dreyfus Model of Skills Acquisition and Shuhari will see some parallels here, and that is intentional, as both of these models provide some great insights into the process of learning. However unlike these models, the five stages I discuss here are as much about team maturity and shared understanding than about individual skills. The effective skill and maturity of a team in any area is not the sum of the skills of the individuals. In fact, team maturity is quite a different beast altogether. For example I have seen many, many teams where the strong personalities of a few individuals will override the ideas of less forthcoming team members, to the detriment of the team as a whole. Team Maturity has as much to do with fostering a shared understanding, a common alignment around clear business goals and a culture of psychological safety as it does with individual skill levels.

This model actually works well for Agile adoption in general, but in this article I want to focus particularly on adopting BDD practices, as this is where a lot of the examples I mention come from. In addition, I find that when teams successfully embrace a BDD mindset, they are more likely to get concrete and long-lasting benefits than teams that simply trying to "do Agile" or "do Scrum".

Disruption

"To go faster you must slow down"

-  John Brunner

Most adoption processes start with some sort of training, whether it be formal classroom training or more informal internal show-and-tell sessions. When teams learn about new practices, and start to apply them in their daily work, they inevitably slow down. This is normal and desirable. We cannot learn effectively if we are under pressure to deliver or to work faster; in fact, when a team is placed under pressure to deliver whilst learning, the team will do neither well. In this initial phase, it is essential to give the team space to breath while team members learn a new way of working.

Any change in the way a team works is disruptive: that is why change is hard. During this initial learning phase, expect your productivity to drop a little (or even quite a bit!). This is normal, and is largely offset by the gains in productivity further down the track.

During this phase, the team is almost entirely focused on learning how to apply what they have been taught. They follow the rules, ceremonies and practices that they were shown (or as they understood them), even if they don't yet have enough experience to know whether they are doing them well, or in the way that would work best for them, or exactly why they are doing them in a particular way.

The Disruption phase usually involves a lot of theoretical training and workshops. Theoretical training is rarely enough to get the team off the ground, and needs to be complemented with some form of support. On the positive side, at this early stage team members generally respond well to guidance from mentors or more experienced practitioners.

Appreciation

"A little learning is a dangerous thing"

- Alexander Pope

By the "Appreciation" stage the team knows what to do, "on paper" at least. They will have "broken even" in terms of productivity, and may even register some modest gains. They are able to apply the principles they have learnt in the real world. But they are still very much focused on following the rules and procedures they have learnt.

At this level, teams will often ask for cookbooks or formula to tell them what they should do in particular circumstances.  For example, they might ask for precise rules about when to express acceptance criteria as narrative Given-When-Then scenarios, and when to express them in tabular form.

Another characteristic of this level is that most team members are still thinking very much in terms of process and practices (such as writing scenarios in a Given-When-Then format or discussing requirements in "Three-Amigos" workshops), rather than thinking in terms of finding the most efficient path to delivering business value. Again, this is normal; our brains have trouble focusing on more than one level of abstraction at the same time, and until we master the basics, it is hard to take a step back and see the bigger picture.

This level is a dangerous one, as oftentimes both management and team assume that the work is done, and that the adoption process is complete. Without strong leadership and guidance, many teams can stay at this level almost indefinitely, and fail to reap the full benefits of their new practices, or even conclude that the new practices are not right for them, before they fully understand them.

Comprehension

“I fear not the man who has practiced 10,000 kicks once, but I fear the man who has practiced one kick 10,000 times.”

- Bruce Lee

As teams grow in maturity, they come to understand that simply following rules, recipes and procedures is a rather inefficient way of working. It may get the job done, but it does not lead to optimal or elegant solutions. You may be able to tile a floor by following a set of rules in a DIY book, but it won't be very neat, it will take longer because you didn't know that old tilers' trick for getting the corners lined up just so, and you certainly won't create a mosaic. You may be able to run a proper three-amigos session, but you will spend a lot of time discussing points that a more experienced team would skim over in minutes or would not deem worthy of their attention.

When a team gets to the "Comprehension" level, they start to benefit from their growing experience. They are now comfortable enough with the basic practices to be able to look beyond the rules and recommendations they have learnt, and have a good idea of when they can bend or break the rules. They can start to adapt the practices, and how they apply them, based on differing circumstances or contexts. For example, they will understand when it might be better to express a scenario as a single table or split into a set of tables. They will know when an acceptance criteria will be more useful in a Given-When-Then format, or when a simple declarative sentence will suffice. They will also know if a scenario should be tested via a UI test, with a fully set up and expensive integration environment, or maybe just on a unit test level.

Teams at this level also communicate more efficiently. They have a common language and a common understanding that helps them leave some things that are now well understood unstated. This helps them reason about business problems at a higher level, and start to provide more innovative solutions.

One thing you notice about a team from this stage on is their increasing level of engagement and empathy, both for other team members and for the client. They genuinely care about doing a good job, and will actively look for better ways to deliver. This engagement needs to be fostered and developed, as it is the key to the next level: Adoption.

Adoption

"Theirs not is to make reply, Theirs not is to reason why"

- (with apologies to) Alfred, Lord Tennyson

The next step in a team's BDD adoption process is to truly realise that there is a bigger picture out there. That the process and practices are a means to an end, and that that end is to deliver business value. This helps the team question their practices, which is the first step to improving and adapting them to their own context.

Of course, in the previous levels, the team knows about the importance of business value; at least in theory. But they hadn't yet internalised the processes and practices enough to be able to step away and consider how they might be refined.

At the "Adoption" level, the team is ready to explore. They can not only bend and break the rules, they can invent entirely new ones. They are in a good place to learn from the experience of others, and experiment with new practices or variations of existing ones.

At this level (and to some extent in the "Comprehension" level as well), the team will be able to use their understanding of the business goals to question the form and even the validity of the features that the business ask for.

In organisations where requirements are handed down from on high and questioning the validity or business value of the requirements is not viewed in a positive light, this sort of thinking is positively discouraged. This may sound a lot like Waterfall, but there are plenty of allegedly "Agile" organisations that still operate this way. Moving these organisations much beyond the "Appreciation" level requires a much more substantial shift in mindset. But that is where the big payoffs come through.

Expansion

“Learn the rules like a pro, so you can break them like an artist.”

- Pablo Picasso

The "Expansion" level corresponds to some extent to the "Expertise" stage in the Dreyfus model or the "Ri" stage in the Shuhari model. At the "Adoption" level, the team can draw on their experience to make reasoned decisions about the best way to deliver value to the business. At the "Expansion" level, the team has accumulated such a wealth of collective experience that they intuitively just know how to deliver a particular outcome. Furthermore, their experience with working and communicating with each other make the delivery smooth and fluid.

The team will also be in a good position to extend the principles beyond their immediate sphere. For example, it becomes very natural for teams at this level to apply their understanding of how to effectively deliver business value to help the organisation plan and prioritise features and capabilities at a portfolio level. This way IT can support the business as a partner in driving value, rather than as just an unimaginative service provider.

Climbing the ladder

Different organisations, and even different teams, will go through these stages at different rates. Some teams get stuck and are tempted to abandon the whole practice. Many others stop at the "Appreciation" level and are convinced that they have successfully adopted BDD (or Agile, or Scrum) and are getting all the benefits that are to be had. I find that a great way to avoid these pitfalls is to do two things:

• Define good progress metrics, and
• Make your progress visible,

Let's see what I mean by this.

Define good metrics

“When the wise man points at the moon, the fool looks at the finger”

- Confucius

When you adopt a new practice or process, it's always good to know how well you are doing. Many organisations are perfectly happy just to note what practices they are doing or what ceremonies they are observing, and assume that following these practices means progress. For example, they are doing daily stand-ups, they have a board on a wall with coloured cards, and they talk about "User Stories" a lot, so naturally they are "doing Agile" just fine. Or they write all their stories using the Gherkin "Given-When-Then" notation, so surely they are doing BDD correctly.

But just observing what practices you are performing is not a great way to measure progress. You are not "doing Scrum" or "doing BDD" so that you can have a nice group chat every morning or gather around the table to talk "Given-When-Then": your goal is to align your efforts so that you can get useful features out the door sooner.

This also applies to technical practices. For example, it is certainly a good thing to write unit tests for your code, and even better to write them before you write the code, but just saying that you are doing TDD doesn't mean you are doing it well, or effectively.

If you are serious about measuring how well you are doing, a better strategy is to define more objective metrics, preferably independent of the process you are following. I would rather track defect rates, or features deployed to production, than velocity or stories marked as done. Velocity and story count is easy to game, defect rates, not so much. For example, if I am measured on the number of stories done, I can just make my stories smaller. Useful metrics that are harder to game (even unintentionally) tend to be indirect and related to tangible, business focused outcomes, such as features (not stories) deployed to production and defect density. Other similar useful metrics might include revenue generated, transactions processed, and so forth.

Two simple and practical metrics that I find useful to keep tabs on a BDD adoption process and that are easy to track are:

• Defect Rate: how many defects (including misunderstood requirements) are raised after a story is delivered
• Throughput: the number of features you can get from the backlog to in front of your users in a given period of time

The numbers here are conservative guidelines, but they do reflect what I have seen in the field, when teams introduce BDD practices and go through these stages.

• During Disruption, productivity actually drops as the team learns and adapts to new practices. Despite this, particularly in teams that practice both BDD and TDD, we typically see a drop in defects very early on.
• During Appreciation, the team breaks even in terms of productivity and throughput, and will typically continue to gain in terms of quality and reduced defect density.
• During Comprehension, the team starts to see some solid gains in terms of throughput;
• During Adoption, the team consolidates and extends their gains in productivity;
• And at the Extension level, the team is at its optimum performance: it is not rare to see defects drop to virtually zero, and throughput increase dramatically.

Conclusion - driving progress

Too many teams and organisations never get beyond the "Appreciation" stage of BDD adoption. This is a shame, as the benefits at this level are mediocre compared to what can be achieved at the higher levels of maturity. If all you are getting from your BDD adoption is fewer defects for comparable throughput, then BDD is hardly worth the investment, at least in the short term. To really get the benefits of BDD, you need to set the bar higher.

But progress doesn't happen by itself. You need to drive it, through deliberate learning and continuous improvement (see “Beyond the 10000 hours myth”).

To progress through the levels, team-members need to build up skills and experience. But this is only part of the formula. How the team communicates and interacts with each other and with the outside world is equally important. Successful teams balance improving their skills with pride in their work and a health dose of empathy for each other and for the customer.

We help organisations get more value sooner out of their IT teams – get in touch to learn more!

JOHN FERGUSON SMART is an international speaker, consultant, author and trainer well known in the Agile community for his many books, articles and presentations, particularly in areas such as BDD, TDD, test automation, software craftsmanship and team collaboration. John helps organisations and teams around the world deliver better software sooner through more effective collaboration and communication techniques, and through better technical practices. John is the author of the best-selling “BDD in Action”, as well as “Jenkins: The Definitive Guide and “Java Power Tools”, and also leads development on the innovative Serenity BDD test automation library.

JAN MOLAK is a full-stack developer and coach who spent last 12 years building and shipping software ranging from award-winning AAA video games and MMO RPGs through websites and webapps to search engines, complex event processing and financial systems. Jan’s main focus is on helping organisations deliver valuable, high-quality software frequently and reliably through implementing effective engineering practices. A prolific contributor to the open-source community, Jan is the author of the Jenkins Build Monitor helping thousands of companies worldwide keep their builds green and the delivery process smooth.