Disciplined Agile

We recently released the 5.2 version of the Disciplined Agile (DA) tool kit, and in that release we added three new process goals: Intake Work, Organize Metrics, and Measure Outcomes.  The focus of this posting is the Measure Outcomes process goal, the goal diagram for which is posted in Figure 1.

Figure 1. The Measure Outcomes process goal diagram (click to enlarge).

The Measure Outcomes process goal describes potential improvement outcomes, or improvement goals, and suggests potential metrics to measure progress against those outcomes. Disciplined Agile doesn't prescribe what to measure, that would be naive because every team is unique with its own priorities and desired outcomes. 

All of the potential outcomes in Figure 1 are important.  However, you will want to focus on a subset at any given time, and that subset is likely to evolve as your improvement focus evolves. Context counts. 

Related Resources

• The Disciplined Agile (DA) Browser.  This is a PMI-members only feature that provides access to the up-to-date details behind the goal diagrams.
• How to Read Process Goal Diagrams

We recently released the 5.2 version of the Disciplined Agile (DA) tool kit, and in that release we added three new process goals: Intake Work, Organize Metrics, and Measure Outcomes.  The focus of this posting is the Organize Metrics process goal, depicted in Figure 1.

Figure 1. The Organize Metrics process goal diagram (click to enlarge).

As the name implies, this process goal describes strategies to organize the metrics approach within your team. This strategy will be driven both by your team's culture and skills as well as the needs of your stakeholders - your metrics will likely need to "roll up" to the program or portfolio level.

Your metrics strategy will focus on several important questions:

• What is the focus of our measure strategy?
• How will we communicate measures both within the team and externally to our stakeholders?
• How will we measure?
• What types of measures will we take and communicate?

Where this goal focuses on how to measure, the Measure Outcomes goal describes what to potentially measure.

Related Resources

• The Disciplined Agile (DA) Browser.  This is a PMI-members only feature that provides access to the up-to-date details behind the goal diagrams.
• How to Read Process Goal Diagrams

We recently released the 5.2 version of the Disciplined Agile (DA) tool kit, and in that release we added three new process goals: Intake Work, Organize Metrics, and Measure Outcomes.  The focus of this posting is the Intake Work process goal.

Intake Work: Added

Figure 1 depicts the process goal diagram for Intake Work (see How to Read Process Goal Diagrams).  This is how a team pulls in work from their "upstream" stakeholders. The incoming work is examined and if ready it is prioritized and put on the team's work backlog. We introduced this process goal because we wanted to have a cohesive source of process information capturing the issues around a common activity that is critical to your team's success.

Figure 1. The Intake Work process goal diagram (click to enlarge)

To be effective at intaking work, we need to consider several important questions:

• When are we going to accept any new work?
• Is the request work ready for us to accept?
• How are we going to prioritize work?
• Who will prioritize the work?
• What types of work needs to be prioritized?
• How are we going to manage work items?

Address Changing Stakeholder Needs: Refactored

Part of the development of Intake Work was the refactoring of Address Changing Stakeholder Needs which previously captured several decision points that focused on intaking work and several on exploring stakeholder needs.  Figure 2 depicts the updated goal diagram.  Important changes include:

• Several decision points - Prioritize Work (What), Prioritize Work (Who), Prioritize Work (How), and Manage Work Items - were moved from here to Intake Work.
• The Explore Stakeholder Needs decision point was moved here from Produce a Potentially Consumable Solution, simplifying that goal and helping to focus this one.

Figure 2. The Address Changing Stakeholder Needs goal diagram (click to enlarge)

Related Resources

• The Disciplined Agile (DA) Browser.  This is a PMI-members only feature that provides access to the up-to-date details behind the goal diagrams.
• How to Read Process Goal Diagrams

One of the mantras of the agile community is that you need to "be agile," that you need to adopt an agile mindset. Agilists will often point to the Manifesto for Agile Software Development, commonly referred to as the Agile Manifesto, as a good starting point to understand this mindset, which it is. Other mantras within the agile community include respecting others and having a safe environment that embraces diversity. All wonderful ideas, but what do you do when they collide with one another? 

The Disciplined Agile Mindset

Figure 1 depicts the Disciplined Agile (DA) mindset, which is captured in the form of principles, promises, and guidelines. Disciplined agilists believe in the DA principles, so we promise to adopt these behaviours and follow these guidelines when doing so. Where the Agile Manifesto addressed the environment faced by software developers 20 years ago, the DA mindset addresses the environment faced by organizations today. The DA mindset reflects our learnings over these past 20 years, adopting great ideas from a wide range of sources, in particular ideas around lean and flow, to describe concepts that enable enterprise agility.  

Figure 1. The Disciplined Agile mindset.

Embracing Different Mindsets in the DA Tool Kit

One of the promises of the DA mindset is to create psychological safety and embrace diversity. Interestingly, when you do that you soon realize that people often have very different mindsets and that this is a very desirable thing. Yes,we want people to embrace an agile mindset so that we all share a similar point of view, but that's only one of many points of view. There are still noticeable differences between the way that you approach something and the ways that others do, even when everyone involved has an agile mindset. This happens because we are all unique people with unique experiences and backgrounds, and as a result you have other points of view than just the agile mindset.  

I'm sure that you've noticed that finance people have a different perspective than people from marketing, whose perspective differs from data management professionals, which is different yet again than research and development people, and so on. Each business function tends to attract, and then reinforce, people of a certain mindset.  Some people find legal work incredibly interesting, whereas others find it spectacularly boring.  To each their own.

This is where it gets interesting.  Remember that DA is a tool kit that supports improvement across all aspects of your organization, not just software development.  One aspect of the architecture of the DA tool kit is that we've captured the different business functions within your organization as process blades, which in turn are described in terms of mindset, people, flow, and practices. Process blades include Finance, Strategy, Legal, Marketing, Security, IT Operations, Portfolio Management, and many more. Regarding mindset, for a given process blade, we extend the base DA mindset with philosophies that are applicable to that process blade.  For example, Figure 2 depicts DA's People Management (Human Resources) mindset and Figure 3 DA's Security mindset.

Figure 2. Disciplined Agile's People Management Mindset.

Figure 3. Disciplined Agile's Security Mindset.

There are several important points to this strategy:

1. DA respects and embraces a diverse range of viewpoints. To truly support business agility, you need an approach that recognizes that different groups within your organization have different ways of thinking, different concerns, and different priorities. The DA tool kit captures that as specific mindsets for each process blade. As always, context counts.
2. To work effectively with others, you need to understand their point of view. The philosophies captured in the mindsets of each process blade provide insights into how people in those job functions think. This improved understanding will help you to bridge the gap between you when you first begin to communicate and collaborate. For example, it can be particularly frustratingly working with Security people, particularly when they are stopping you from doing something or are forcing you to follow a more security-oriented WoW.  Understanding the philosophies captured in Figure 3 can help you to appreciate what Security professionals are trying to achieve, and why they are doing so.
3. This supports process improvement across disparate teams. Agile teams are semi-autonomous in that they need to collaborate with others sometimes to get things done. For example, my team needs to interact with Finance to fund a new endeavor.  Although we want to accomplish this in a streamlined and agile manner, the Finance team is currently more traditional in their approach and as a result injects cost and risk into the overall process. By understanding the mindset of Finance, and hopefully Finance investing time to understand the mindset of my team's function, we'll be better able to negotiate a new way of working (WoW) to experiment with.  This sort of skill, facilitating process improvement efforts across disparate teams, is a critical skill that we team in the Disciplined Agile Coach (DAC) certification.

Just like one process does not fit all situations, one mindset doesn't either.  The Disciplined Agile (DA) tool kit explicitly embraces mindset diversity.  Do you?

We used to say that software is eating the world, but the fact is today software is the world. Gone are the days where IT could be treated like a utility, one that more often than not was outsourced in the belief that you needed to focus on your core competencies and IT didn’t make it onto that list. These days being competent at IT is mere table stakes at best, you need to excel at IT if you hope to become an industry leader. Today business executives must focus on disruptors, new competitors entering their market space using technologies in new ways. Becoming an agile business – an adaptive, responsive, and learning organization – is the true goal. Business agility requires true agility across all of your organization, not just software development, not just DevOps, and not just IT. There isn’t a single industry now that either isn’t dominated by agile businesses or isn’t under threat of disruption by new agile competitors.   

The Disciplined Agile (DA) tool kit was created to apply agile in complex enterprise agile implementations. DA has been well received and implemented in organizations around the world. According to Gartner, Disciplined Agile is also the only available agile process explicitly allowing enterprises to customise agile for their unique enterprise challenges at both the organization and project levels.  In their research report, Adopt Disciplined Agile Delivery for a Comprehensive and Scalable Agile IT Approach, Gartner reported: 

“Success with agile development is important, but comes in different forms across enterprises. Technical professionals responsible for application development can use Disciplined Agile Delivery to tune agile processes and practices, including SAFe, to their specific needs."

In this article, we address several common questions executives have about Disciplined Agile (DA):

1. What is DA?
2. Why should I consider DA?
3. Where is DA being used?
4. Are there any DA success stories?
5. How can we get started?

What is Disciplined Agile (DA)?

The Disciplined Agile (DA) tool kit provides straightforward guidance to help organizations streamline their processes in a context-sensitive manner, providing a solid foundation for business agility. The figure below provides a high-level overview of the scope of DA (click on the diagram to zoom in).

DA provides a foundation for business agility does this by showing how the various activities such as Finance, Portfolio Management, Solution Delivery (software development), IT Operations, Enterprise Architecture, Vendor Management and many others work together. DA also describes what these activities should address, provides a range of options for doing so, and describes the trade-offs associated with each option.

DA also provides a straightforward strategy for implementing value streams, overviewed in the following diagram (click on it to zoom in).

You can read more about DA in Introduction to Disciplined Agile.

Why should I consider Disciplined Agile (DA)?

There are several reasons why your organization should adopt the Disciplined Agile (DA) tool kit:

1. DA enables you to become a learning organization. Rather than helping you to adopt the “best practices” of a specific agile framework, the DA tool kit instead gives your team the tools they need to learn and to improve their ways of working (WoW). 
2. DA enables you to increase your rate of process improvement. The DA tool kit provides straightforward guidance for identifying potential improvements that are likely to work in the context that you face, enabling your teams to reduce the number of failed experiments and thereby increase their rate of improvement.
3. DA supports the entire range of complexities faced by your teams, not just team size. Every person, every team, and every organization is unique. The implication is that you need a tool kit that provides you with choices so that you can tailor, and later evolve, an approach to address the situation that you face in practice. 
4. DA is agnostic and hybrid. DA adopts pragmatic techniques from a wide range of sources – agile sources, lean sources, and even traditional sources – and does the work of putting them into context so that you don’t have to. 
5. Support all types of teams, not just software teams. As you saw earlier, there are over twenty process blades/areas within the DA tool kit. Only one of them, Disciplined Agile Delivery (DAD), is focused on software development teams.  
6. Consistent governance across disparate teams. Luckily, it’s not only possible but highly desirable to have a light-weight, lean governance strategy in place. In fact, the DA tool kit builds lean governance strategies into most process blades and has an overarching, enterprise-level process blade called Governance. 
7. DA is the foundation for business agility. We’ve been talking about teams a lot, but it’s not just about teams. It’s really about how your organization can become more competitive, how it can regularly delight your customers, and how it can continue to evolve and improve over time. It’s really about business agility, and the DA tool kit shows how it all fits together.

You can read more about why you should consider DA at Why Disciplined Agile?

Where is Disciplined Agile (DA) being used?

DA is being used in numerous organizations, in a wide range of industries, around the world.  You can see a list of a subset of the organizations using Disciplined Agile.

Are there any Disciplined Agile (DA) success stories?

Yes. We have published several Disciplined Agile success stories with more on the way.

How can we get started with Disciplined Agile (DA)?

The answer to this question depends on what you're trying to achieve:

• Getting personally started 
• Getting a team started
• Getting your organization started 

Getting personally started with Disciplined Agile

There are several ways that you can learn more about DA, and we recommend following the one(s) that seem best for you:

1. Online reading. If you want to start with some online reading, then our Start Here article is a great option.
2. Online eLearning. If you prefer eLearning options, our Basics of DA online course is a nice overview to get you going.
3. Read a book. If you're looking for a quick read, the Introduction to Disciplined Agile Delivery 2nd Edition is it.  If you'd like a more in-depth understanding of the tool kit, then Choose Your WoW! is recommend (and it's free to PMI members). 
4. Take some training. We have a variety of instructor led training (ILT) as well as online learning options to choose from, which are important parts of an agile certification journey.

Getting a team started with Disciplined Agile

There are also several options for getting a team going with Disciplined Agile, we recommend considering all three:

1. Get a few individuals started with DA.  The easiest strategy would be to point them to the options for individuals above. Your goal is to have several people be sufficiently informed about DA so that you can determine if it's right for you.
2. Get some training. PMI's agile certification journey includes training options for all team members at all levels of agile expertise. 
3. Hire one or more Disciplined Agile Coach (DAC) or Disciplined Agile Value Stream Consultant (DAVSC). DACs can help you learn how to apply the DA tool kit with teams and across teams to improve their effectiveness.  DAVSCs help you to streamline your value streams so as to enable you to effectively delight your customers.  You can search for people who have earned their DAC accreditation here.

Getting your organization started with Disciplined Agile

Our fundamental advice is to start where you are, do the best that you can given the situation that you face, and always strive to get better.  To succeed, there are three key concepts to understand:

1. Context counts. Your strategy to get started will vary based on your context - an organization that is new to agile will take a different path than one that has already (mis)adopted an agile framework.  An organization that has successfully adopted agile within their IT department and is now focusing on other parts of their organization will need a different strategy than one that is focusing on the entire organization at once.  As you can see in the following diagram, there are multiple paths that you can take to become a learning organization.
2. The goal is to become a learning organization. Many organizations hope that adopting an agile framework such as Scrum or SAFe is what they need to do. That may be a good start, but it isn't your real end goal, instead you want to become a learning organization that is capable of evolving and improving beyond the confines of an agile framework/method. When you successfully adopt a framework, you typically find that the framework doesn't address all of the situations that you face. Nor do frameworks offer more than platitudes about how to evolve your WoW beyond what they prescribe, The aim of the DA tool kit is to teach you how to improve effectively, not prescribe one set of "best practices."
3. There is no quick, easy fix. Improvement is a life-long journey, not a short-term project. To become a learning organization you must adopt a mindset and some tools that enable your people to experiment, learn, and improve.

Although every organization's journey is unique, we have found that at a high-level they all follow a similar 3-step transformation path:

1. Align. Fundamentally, you always start where you are. Because every organization is different, you must assess your situation, identify your challenges that you need to overcome, and then select an appropriate improvement path and strategy to journey on that path.
2. Improve. Follow an improvement strategy that is fit-for-purpose, tailored to address the challenges that your organization faces.  This strategy will evolve over time as challenges are overcome and new challenges appear. The DA strategy is to improve in place, addressing your immediate needs while teaching you the skills and providing the tools to help you evolve into a true learning organization.
3. Thrive. You will thrive when you've become a learning organization, one that is able to learn from and evolve with their changing environment. One that is focused on improving their way of working (WoW) so that they delight their customers.