Is there a Simplified Version of Disciplined Agile?

Disciplined Agile (“DA”) is a sizable body of agile and lean knowledge, and it keeps growing. Is there a simplified version of Disciplined Agile? Yes, I know of many simplified versions of DA. However, before jumping right to the simplified versions, I want to have a common understanding with you of what simple is.

No matter the approach, waterfall, hybrid, agile or lean, we still need requirements. Let’s use the requirements space for a place to get our minds synced on what simple means. DA’s main guidance is found in information containers called process goals. Most of the process goals have a lot of practices to choose from. Explore Scope, a primary container of requirements practices, has 56! No team needs to use all of those 56 options. Let’s simplify.

Figure 1 is a significantly simplified DA “Explore Scope” process goal diagram, two practices: user stories and a product backlog. User stories are an approach to capturing functional requirements. A product backlog is nothing more than a prioritized (or ordered) stack of stories.

Figure 1: Super-simple agile requirements approach

This is simple, super-simple, just two practices. But, if this were all the guidance in DA for requirements, would this work for you? Is it enough for you to successfully adopt an agile way of working?

If you thought maybe, but my team may need more than this, what would you do next? Me, I most likely would go to Google. Type in something like “agile requirements” and start exploring.

Figure 2: Where can I find more agile guidance

I look at the search results. I go down some black holes that waste time; however, I find a few things I think my team may benefit from. Our stakeholders need to understand acceptance criteria. I also found that epics are big stories that we don’t need to do much work with until we break them down. Both will be helpful.

I am pretty good with graphics. I have Snag-it screen capture tool and PowerPoint. So I take super-simple DA and add these two other things for my team to use. Figure 3 is super simple, plus these two additions.

Figure 3: Super Simple +

Now, is that enough? Epics, user stories, acceptance criteria, and a product backlog. We get on with adopting agile, but we run into some issues. We are struggling with how to capture the nonfunctional requirements, our developers need to do technical work, but we have not written that anywhere yet. Well, at least in some consistent way. Our stakeholders are also struggling with seeing the connection of all these user stories. They want the team to group related ones and move them into a Word document. What should we do?

I am not sure. Ok, back to my source of agile information, Google. More black holes lead me nowhere, but eventually, I find information that helps me. I discovered technical stories (also referred to as enablers, spikes, and a few other terms), which would solve our developers’ issue. I also find a solution to our stakeholders’ problem with all the stories we have been identifying and not connecting to how they fit with each other. A user story map looks like it would help our Stakeholders and us as a team.

Figure 4: Super Simple ++

A little more graphic editing magic and figure 4 now include those things added to our way of working. Ok, I am sure you can see where I am going with this. Simple is comfortable. Simple is easy to understand. But, simple is often not enough. What is simple for my team may be super complicated to your team or vice versa. What we need today may not be enough tomorrow.

Figure 5 is an example from a team I coached through a few projects. They started with five choices and have expanded to thirteen. Still pretty simple. By the way, I strongly feel this is a set of core practices that most teams would get value from adopting.

Figure 5: Still Pretty Simple

Figure 6 is the Explore Scope process goal, as you find it in DA now with all 56 options. You can start with this, make some choices, and that is your way of working. Next, take a screen capture of the diagram and edit it to have your team’s selections. This reduces the visual clutter and brings focus to your way of working. I did this with the figures above and in figure 7 comparing before and after choices.

You can use less sophisticated editing or no editing at all. Place a transparent grey or solid white box to cover what will not be used. A good tool for this is Miro (virtual collaboration canvas). Another is just to circle or highlight the options chosen. Putting the choices in a spreadsheet is another. There is no right or wrong way; what is essential is finding the most straightforward approach that everyone understands and gets value from.

Figure 6: Full Explore Scope Process Goal

Figure 7: Side-by-Side Comparison Before & After Choosing Options

You run into some problems or challenges or want to improve continuously, go to the DA browser and look at the options. Find a practice that solves your challenge. Update your process. It is that easy.

I started this article by stating that there are many simplified versions of DA. Those simplifications are what teams using DA has. By making choices, you simplify DA. You don’t need to use Google, or not very often. You don’t need a stack of books, articles, white papers, etc. Instead, use Disciplined Agile’s process goals. Start with what you need, see how the practices you chose are adding value. Keep the ones that help you. Replace the ones that don’t. Simple.

Now I have what we call quick-starts, good starting points for teams to begin, especially those new to agile or using a hybrid approach. If you have an experienced coach (in agile – does not have to be in disciplined agile) supporting you, they can guide you through making choices. If you don’t, you could struggle. That is where the quick-starts provide an excellent on-ramp to DA and an agile way of working. A place to start and then improve. That will be my next article.