Disciplined Agile

We are often asked why Disciplined Agile (DA) has a team lead role instead of  Scrum master or project manager.  The answer is three-fold: different types of teams require different types of leaders, leadership responsibilities vary based on the type of team they are leading, and DA strives to be agnostic wherever possible.  Let's explore the implications of this strategy.  

Team lead is what is known as a meta role.  What we mean by this is that there are different types of team lead depending on the situation, as depicted in Figure 1.  Think of team lead as a place holder for a more specific type of lead.  So, a scrum master is a team lead of a Scrum team, a project leader is a team lead of a project team, a sales manager is a team lead of a sales team. At times, the team will choose to stick with the name “team lead” for the role due to their way of working best fitting that description. 

Figure 1. Types of team leads.

As I said above, there are three reasons for taking this approach with the team lead role:

1. Different teams require different types of leads.  A Scrum team needs a scrum master, or better yet a senior scrum master, as team leader. Similarly, a project team needs a project manager or project leader.  A finance team or a sales team need a function manager such as a chief financial officer or a sales manager respectively as the team lead. Each type of team needs a team lead that is fit for purpose. Because all these teams (and many more) are part of Disciplined Agile, we cannot prescribe a single type of team lead.  
2. Leadership responsibilities will vary across teams. The responsibilities of team leads will vary depending on the type of team they lead. For example, when leading a team a project manager takes on different responsibilities compared to a scrum master.  Similarly, a sales manager leading a team would have responsibilities around educating business leaders on the sales strategy that a project leader typically wouldn't have.   
3. Being agnostic.  Let’s imagine for a moment that it made sense to have a single set of responsibilities for the team lead role. Which one should it be? Adopting the scrum master role would only fit Scrum teams. Similarly, adopting the project manager role would only fit project teams. In the end, either choice ends limiting the applicability of the Disciplined Agile tool kit. Remember that DA is a hybrid approach that opens your options by combining great ideas from a wide range of sources: some agile, some lean, and some traditional. Ultimately, leading teams appropriately to a better way of working.  

The end result is that you may see some DA teams with a senior scrum master as the team lead, some DA teams with a project leader as a team lead, some DA teams with a functional leader in the role of team lead, and some teams with someone who is simply the team lead. Just like your way of working (WoW) should be fit for purpose, so should your approach to roles and responsibilities.

The Disciplined Agile (DA) tool kit has always been a hybrid of great strategies from the very beginning, with the focus being on how all of these strategies fit together in practice. In the current release of DA we made its hybrid nature explicit when we refactored the foundation, depicted in Figure 1, into its own layer.  You can see this in that we clearly indicate that Agile, Lean, and Serial (traditional) strategies are all foundational aspects of DA.

Figure 1. The foundation of DA is fundamentally hybrid in nature.

We like to say that DA does the heavy process lifting so that you don’t have to. We’ve mined the various methods, frameworks, and other sources to identify potential practices and strategies that your team may want to experiment with and adopt. DA puts these techniques into context, exploring fundamental concepts such as what are the advantages and disadvantages of the technique, when would you apply the technique, when wouldn’t you apply the technique, and to what extent would you apply it? Answers to these questions are critical when a team is choosing its way of working (WoW). Figure 2 shows that DA is a  hybrid tool kit that puts great ideas from PMBOK Guide, Scrum, SAFe, Spotify, Agile Modeling (AM), Kanban, and several other methods into context.  

Figure 2. Some of the process sources leveraged by DA.

DA has taken this approach because no framework, no book of knowledge (BoK), is complete.  For example, XP is the source of technical practices such as test-driven development (TDD), refactoring, and pair programming but has nothing to say about project management.  The PMBoK Guide has great strategies for project managers, but has nothing to say about data analytics.  The Agile Data (AD) method has great strategies for creating and evolving data sources but has nothing to say about organizing agile teams. Scrum offers great strategies such as product backlogs, sprint/iteration planning, and daily coordination meetings for organizing agile teams but has nothing to say about documentation strategies.  Agile Modeling gives us model storming, architecture envisioning, and continuous documentation strategies but has nothing to say about governance.  You get the point.

Each framework, each BoK, has its specific focus and thus is not sufficient on its own. The upside is that there are great strategies presented by each, often in great detail.  The downside is that each source is locally optimize, they are inconsistent with one another, and there is very little advice for how to integrate these sources.  This is where DA steps in - DA is hybrid that combines and puts these great ideas into context, providing advice for how to apply them effectively when you choose your WoW. 

One of the principles of the Disciplined Agile (DA) mindset is to "Be Awesome."  Who doesn’t want to be awesome? Who doesn’t want to be part of an awesome team doing awesome things while working for an awesome organization? We all want these things. Recently, Joshua Kerievsky has popularized the concept that modern agile teams make people awesome, and, of course, it isn’t much of a leap that we want awesome teams and awesome organizations too. Similarly, Mary and Tom Poppendieck observe that sustainable advantage is gained from engaged, thinking people, as does Richard Sheridan in Joy Inc. Helping people to be awesome is important because, as Richard Branson of the Virgin Group says, “Take care of your employees and they’ll take care of your business.” 

There are several things that we, as individuals, can do to be awesome:

1. Act in such a way that we earn the respect and trust of our colleagues. Be reliable, be honest, be open, be ethical, and treat them with respect.
2. Willingly collaborate with others. Share information with them when asked, even if it is a work in progress. Offer help when it’s needed and, just as important, reach out for help yourself.
3. Be an active learner. We should seek to master our craft, always being on the lookout for opportunities to experiment and learn. Go beyond our specialty and learn about the broader software process and business environment. By becoming a T-skilled, “generalizing specialist” we will be able to better appreciate where others are coming from and thereby interact with them more effectively.
4. Seek to never let the team down. Yes, it will happen sometimes, and good teams understand and forgive that.
5. Be willing to improve and manage our emotional responses to difficult situations. Innovation requires diversity, and by their very nature diverse opinions may cause emotional reactions. We must all work on making our workplace psychologically safe. 

Awesome teams also choose to build quality in from the very beginning. Lean tells us to fix any quality issues and the way we worked that caused them. Instead of debating which bugs we can skip over for later, we want to learn how to avoid them completely. As we’re working toward this, we work in such a way that we do a bit of work, validate it, fix any issues that we find, and then iterate. The Agile Manifesto is clear that continuous attention to technical excellence and good design enhances agility.

Senior leadership within our organization can enable staff to be awesome individuals working on awesome teams by providing them with the authority and resources required for them to do their jobs, by building a safe culture and environment, and by motivating them to excel. People are motivated by being provided with the autonomy to do their work, having opportunities to master their craft, and to do something that has purpose. What would you rather have, staff who are motivated or demotivated?

An important part of agile culture is to be honest and forthcoming about your mistakes, so I'd like to share one that I've made in a key diagram that exists in both our courseware and in the book Choose Your WoW!  This blog posting is my "failure bow" regarding mistakes that I made in the flowchart for how to choose between DA life cycles.

Figure 1 presents the original flowchart as it currently appears in the book and courseware.  Don't worry, we're in the process of updating both.  I'm writing this blog now because I want to make this update publicly available as quickly as possible to support people's learning journeys.  There are two problems in Figure 1:

• The decision in the bottom right corner has two "yes" options coming out of it.
• The decision in the bottom-right corner is poorly worded.

Figure 1. Choosing a DA lifecycle (original diagram).

The update to the diagram is presented in Figure 2.  You can see that we've changed one of the Yes options to be No.  More importantly, we've reworded the decision point so that it's clearer.  We had several people point out that they didn't understand the original wording of the question about potential disruption.  I had written that question from the point of view of a team composed of people with a traditional background.  But, many teams now have an agile background, having gotten started with a framework like Scrum only to find it insufficient for their needs.  Such teams wouldn't be disrupted, at least not very much, by adopting the Agile lifecycle.  Thus we've reworked the question to instead ask about the team's agile background. 

Figure 2. How to choose a DA life cycle (updated).

An important point that I would like to make about the flowchart of Figure 2 is that this is the logic that we suggest you follow, but you may still decide to make other decisions.  For example, consider the decision point in the bottom-right corner.  You may be working with a team that is new to agile but still decide to adopt the agile lifecycle over the lean lifecycle because you're willing to invest in the time and expense of training and coaching them in agile ways of working (WoW).  Fair enough, that's your call.

I hope that this update has cleared up any confusion you may have had around this diagram.

In the recent release of Choose Your WoW! we have evolved some aspects of the Disciplined Agile (DA) tool kit.  One of the things we evolved is how we communicate the DA mindset (pictured above). The guidelines help us to be more effective in our way of working (WoW) and in improving our WoW over time. In this blog posting we explore the eight guidelines:

1. Validate our learnings. The only way to become awesome is to experiment with, and then adopt where appropriate, a new WoW. In guided continuous improvement (GCI) we experiment with a new way of working and then we assess how well it worked, an approach called validated learning. Being willing and able to experiment is critical to our process-improvement efforts. 
2. Apply design thinking. Delighting customers requires us to recognize that our aim is to create operational value streams that are designed with our customers in mind. This requires design thinking on our part. Design thinking means to be empathetic to the customer, to first try to understand their environment and their needs before developing a solution. 
3. Attend to relationships through the value stream. The interactions between the people doing the work are what is key, regardless of whether or not they are part of the team. For example, when a product manager needs to work closely with our organization’s data analytics team to gain a better understanding of what is going on in the marketplace, and with our strategy team to help put those observations into context, then we want to ensure that these interactions are effective. 
4. Create effective environments that foster joy. Part of being awesome is having fun and being joyful. We want working in our company to be a great experience so we can attract and keep the best people. Done right, work is play. We can make our work more joyful by creating an environment that allows us to work together well. 
5. Change culture by improving the system. While culture is important, and culture change is a critical component of any organization’s agile transformation, the unfortunate reality is that we can't change it directly. This is because culture is a reflection of the management system in place, so to change our culture we need to evolve our overall system. 
6. Create semi-autonomous self-organizing teams. Organizations are complex adaptive systems (CASs) made up of a network of teams or, if you will, a team of teams. Although mainstream agile implores us to create “whole teams” that have all of the skills and resources required to achieve the outcomes that they’ve been tasked with, the reality is that no team is an island unto itself. Autonomous teams would be ideal but there are always dependencies on other teams upstream that we are part of, as well as downstream from us. And, of course, there are dependencies between offerings (products or services) that necessitate the teams responsible for them to collaborate.
7. Adopt measures to improve outcomes. When it comes to measurement, context counts. What are we hoping to improve? Quality? Time to market? Staff morale? Customer satisfaction? Combinations thereof? Every person, team, and organization has their own improvement priorities, and their own ways of working, so they will have their own set of measures that they gather to provide insight into how they’re doing and, more importantly, how to proceed. And these measures evolve over time as their situation and priorities evolve. The implication is that our measurement strategy must be flexible and fit for purpose, and it will vary across teams. 
8. Leverage and enhance organizational assets. Our organization has many assets—information systems, information sources, tools, templates, procedures, learnings, and other things—that our team could adopt to improve our effectiveness. We may not only choose to adopt these assets, we may also find that we can improve them to make them better for us as well as other teams who also choose to work with these assets. 

These guidelines are described in greater detail in chapter 2 of Choose Your WoW!.  

Free Downloads

We have made several Disciplined Agile (DA) posters available to you for free download, including a Disciplined Agile Mindset poster.