A simple approach to make your Agile transformation towards DevOps brutally Transparent!
A couple of years ago, I wrote a blog about the DoD EvoCycle and how you can use this technique to manage your Definition of Done effectively and bring back ownership to the Scrum Team.
Because it works amazingly well, I’ve been actively using and promoting this technique with all my Scrum Teams. While using the DoD EvoCycle, I noticed that it could also be a powerful approach for making an organisation’s Agile transformation towards DevOps brutally transparent!
It requires three steps.
Step 1: Gather data.
Step 2: Plot the retrieved data onto the DoD EvoCycle (which requires two additional steps), and voila! You have a starting point.
Step 1: Gather Data
What to do?
The first step is about creating transparency. We do this by asking the following question.
What are all the activities that need to be done to bring an Increment
into Production?
Protip:
- In this stage, it’s not about what your team can or can’t do. I always emphasise the “what are ALL the activities”-part because I want the teams to think in possibilities instead of limitations.
- Depending on the team size, I tend to use facilitation techniques to promote bottom-up thinking. Some Liberation Structure microstructures can be very useful here.
- Don’t worry too much about whether you have identified all the activities or not. An Agile transformation should be considered an empirical journey with no end state. It’s always on the move. We are limited to what we know, and when we learn more, we can make decisions based on what is observed.
Empiricism asserts that knowledge comes from experience and making decisions based on what is observed. — Scrum Guide 2020
Step 2: Plotting the data onto the DoD EvoCycle.
Step 2.1: Identify the Outside and Inside
What to do?
Ask the team to plot all the identified activities from step 1 onto the Outside and Inside column.
Definition:
- Outside: activities that need to be done to get the Increment into Production, but they are outside our self-managing ability
- Inside: activities that need to be done to get the Increment into Production and they are inside our self-managing ability.
Examples of Outside and Inside
- [Outside] “We have a separate Release Management Department that takes care of the releases”.
- [Outside] “Before the Increment can go into Production, it needs to go through Security due to auditing”.
- [Outside] “We finished our part. Now it’s up to Team X to do theirs”.
- [Inside] “Yes, the actual releasing of the Increment is outside our team, but triggering Release Management is something that we have to do.”
- [Inside] “There are organisational quality standards that we need to respect.”
Protip:
- Focus on the first two columns. The third column will come.
- All the activities that are placed in the Outside columns are somehow triggered. This can be by mail, phone, in-person, automatically through other systems etc. Make sure that you’ve identified these “triggers”. They are your dependencies.
- Every activity in the Outside column is a dependency that is holding your team back from becoming truly self-managing. A Scrum Master can help the Scrum Team by getting these activities from Outside to Inside. Note that not all dependencies can or should be solved.
Step 2.2: Move items from the Inside to Owned
What to do?
Now that we’ve identified the first two columns, it’s time to look at the Inside and Owned columns.
Definition:
- Inside: activities that need to be done to get the Increment into Production and they are inside our self-managing ability, but we’re actually not doing these at the moment. (Or not at least not consistently)
- Owned: activities that need to be done to get the Increment into Production and they are inside our self-managing ability, and we’re owning it.
Examples of Inside and Owned
- [Inside] “Yes, we know about Test-Driven-Development. We’re just not doing it consistently.”
- [Inside] “Sometimes, when I see a harmless error, and I don’t have enough time, I add a //todo so that I won’t forget it.
- [Owned] “If it doesn’t follow our clean architecture principles, then it’s not done.”
- [Owned] “All security standards are met; otherwise, it’s pointless to go live.”
Protip:
- It’s a thin line between Inside and Owned.
- Having activities in the Inside column doesn’t mean it’s bad. There can be numerous valid reasons to have to there. It’s a good conversation starter.
- Essentially, all the activities in the Owned column should be your Definition of Done.
Conclusion
- The DoD EvoCycle is a simple technique to make your Agile transformation towards DevOps brutally transparent.
- The power of the DoD EvoCycle is that you can see your team’s Agile journey towards DevOps in one glance. This approach is way more visual and valuable than all these mechanical Agile Maturity Scans.
- Reevaluate the DoD EvoCycle often with your team. See if you can get more activities to the Owned column. The more a Scrum Team can own their work, the more self-managing they can be, and the closer they get to delivering an Increment to Production at least every Sprint.
- The DoD EvoCycle can provide detailed insights to Leaders on where Scrum Teams struggle to become fully self-managing. Often in an Agile transformation, managers are also figuring out how to help the teams. The DoD EvoCycle can be a useful input for these conversations.
- Remember that not all dependencies can or should be solved.
- DevOps is Professional Scrum done right!
- When the DoD EvoCycle is present in the team room, it creates this “in-your-face effect” where you will constantly be reminded of improving your Definition of Done.
At Scrum Facilitators, we have a GitHub repository where you can download the DoD EvoCycle for free.
