1 Minute
WHAT YOU SAY / DO
Speaker 1: Hi.
[Click] And then…
[Click] And then…
Speaker 2: Great.
WHAT THEY SEE
Static slide
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. It 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.
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.
See https://www.pmi.org/disciplined-agile/introduction-to-disciplined-agile
Scott Ambler – Co-creator of Disciplined Agile, PMI VP and Chief Scientist of Disciplined Agile
Mark Lines – Co-creator of Disciplined Agile, PMI’s VP of Disciplined Agile
Al Shalloway – Creator of FLEX (now part of DA), PMI Director of Agility at Scale
A CAS is a system in which a perfect understanding of the individual parts does not automatically give you a perfect understanding of the whole system’s behavior.
It is complex because they are a dynamic network of interacting teams. It is hard to predict what each individual team will do. The hope and goal is that they are working toward the goal of delighting their customers.
It is adaptive because individuals and teams self-organize and learn from their experiences, and hopefully from the experiences of others.
This is the DA Process Blades chart.
A process blade addresses a specific organizational capability, such as finance, people management, data management, agile solution delivery, procurement, and more.
The foundation layer captures the fundamental skills and knowledge required for business agility
The Disciplined DevOps layer captures how to streamline solution delivery in an enterprise
The Value Stream layer captures, from beginning to end, how to provide value to customers
The Disciplined Agile Enterprise (DAE) layer captures the organizational process required to support value streams
What to say
Every team is in a unique situation
There is more to scaling than just team size, and frankly that’s the easiest factor to address
This diagram is a tactical scaling factors chart can help you to understand your context, addressing six dimensions. Each axis ranges from low to high complexity.
For more information about tactical scaling factors, see https://www.pmi.org/disciplined-agile/agility-at-scale/tactical-agility-at-scale/scaling-factors
There are four essential views of Disciplined Agile that you need to understand.
There are four essential views of Disciplined Agile that you need to understand.
Let’s start by looking at the DA Mindsets
The Disciplined Agile (DA) mindset is captured in the form of principles, promises, and guidelines. Disciplined Agilists believe in the DA principles, so we promise to adopt these behaviors and follow these guidelines when doing so. There is a purpose for each aspect of the mindset.
What to do
You can use the next three slides as an “animation” walk-through of these three foundations of the DA Agile Mindset. They describe the following
Principles. The principles provide a philosophical foundation for business agility. They are based on both lean and flow concepts.
Promises. The promises are agreements that we make with our fellow teammates, our stakeholders, and other people within our organization whom we interact with. The promises define a collection of disciplined behaviors that enable us to collaborate effectively and professionally.
Guidelines. These guidelines help us to be more effective in our way of working (WoW) and in improving our WoW over time.
For more information, see
https://www.pmi.org/disciplined-agile/mindset and
https://www.projectmanagement.com/blog-post/63666/Evolving-Disciplined-Agile--Principles-of-the-DA-Mindset
Now let’s turn to people: Roles, responsibilities, and team structures
DA includes these roles on teams regardless of size.
Team Lead. A meta role. Could be a Senior Scrum Master, PM, Project Leader, functional manager. This is described on the next slide.
Product Owner. The “voice of the customer,” representing the needs of the stakeholders to the team and the work of the team to the stakeholders
Architecture Owner. The “voice of the organization”, leads teams through solution decisions, typically a senior person
Team Member. Anyone else on the team
Stakeholder. A broader role than “customer” in that it explicitly includes both internal customers as well as external customers (who are typically thought of as the customer
See https://www.pmi.org/disciplined-agile/people/roles-on-dad-teams
Supporting roles (formerly called secondary roles) are typically introduced, often on a temporary basis, to address scaling issues. There are five supporting roles:
Specialist. Although most agile team members are generalizing specialists , sometimes, particularly at scale, specialists are required. For example, on large teams or in complex domains one or more agile business analysts may join the team to help you to explore the requirements for what you’re building. On very large teams a program manager may be required to coordinate the team leads on various subteams/squads.
Independent Tester. Although the majority of the testing is done by the people on the DAD team themselves, some DAD teams are supported by an independent test team working in parallel that validates their work throughout the lifecycle. This independent test team is typically needed for agility at scale situations within complex domains, using complex technology, or addressing regulatory compliance issues.
Domain Expert (or subject matter expert). The product owner represents a wide range of stakeholders, not just end users, so it isn’t reasonable to expect them to be experts in every nuance in your domain, something that is particularly true with complex domains. This is what the domain expert does.
Technical Expert. Sometimes the team needs the help of technical experts, such as a build master to set up their build scripts, an agile database administrator to help design and test their database, a user experience (UX) expert to help design a usable interface, or a security expert to provide advice around writing a secure system. Technical experts are brought in on an as-needed, temporary basis to help the team overcome a difficult problem and to transfer their skills to one or more people on the team.
Integrator. For large DAD teams which have been organized into a team of sub-teams, the sub-teams are typically responsible for one or more subsystems or features. The larger the overall team, generally the larger and more complicated the system being built. In these situations, the overall team may require one or more people in the role of integrator responsible for building the entire system from its various subsystems. On smaller teams or in simpler situations the Architecture Owner is typically responsible for ensuing integration, a responsibility that is picked up by the integrator(s) for more complex environments. Integrators often work closely with the independent test team, if there is one, to perform system integration testing regularly throughout the project. This integrator role is typically only needed at scale for complex technical solutions.
See https://www.pmi.org/disciplined-agile/people/roles-on-dad-teams
Disciplined Agile calls out a number of roles which reflect the scope of the tool kit.
See https://www.pmi.org/disciplined-agile/agility-at-scale/disciplined-agile-roles-at-scale
Now let’s turn to flow, how we go about improving the flow of value realization which is critical for business agility.
2 minutes
Disciplined Agile Delivery (DAD), the solution delivery portion of the Disciplined Agile framework, supports several full delivery life cycles. It does this because solution delivery teams face different situations, so one life cycle will not fit all. It depends on the context and needs that the team faces.
For example, agile can be a very effective approach but in some situations, such as where priorities are changing daily, Lean may be a better approach. Knowing more options can make your teams more effective.
Due to time constraints, we will review just a couple of the six DA life cycles.
For more information about all six life cycles, see https://www.pmi.org/disciplined-agile/lifecycle
1 minute
The agile life cycle is for teams taking a project approach. It is based on Scrum. And it brings enterprise-issues into account
Notice how it shares risk-based milestones with the business life cycles
For more information, see https://www.pmi.org/disciplined-agile/lifecycle#Agile
2 minutes
Continuous Delivery: Agile is appropriate for stable/long-lived teams doing Agile
Iterations are typically 1-2 weeks, although 1 day also common. At the end of the iteration you release into production.
More like a “very regular delivery” life cycle than a continuous delivery life cycle
For more information, see https://www.pmi.org/disciplined-agile/lifecycle#ContinuousDeliveryAgile
2 minutes
A good end goal for your improvement efforts
The product is shipped into production or the marketplace on a very regular basis. This could be often as daily, although weekly or monthly is quite common too.
https://www.pmi.org/disciplined-agile/lifecycle#ContinuousDeliveryLean
The life cycles of Disciplined Agile support a common set of risk-based, lightweight milestones.
This provides senior leadership visibility into key aspects of what teams are doing and entry points for them to provide guidance.
These common milestones are one aspect of how governance is baked into DA.
Finally, let’s turn to the practices of DA.
Let’s look at a couple of process goal diagrams:
Click: Explore Scope
And People Management (which is in the Disciplined Agile Enterprise)
This slide is animated.
What to say. Let me quickly walk you through an example of process goal called Explore Scope.
Here is the setup.
Your team is having problems identifying how people will use their solution because they don’t have access to actual end users.
The Team Lead says, ”Hey, why don’t we look up potential options in the DA tool kit” and see what we could try
The team looks at the Explore Scope goal diagram.
(CLICK) The team discovers that there’s more options for Exploring Usage than writing user stories
(CLICK) They then look up the details in the Choose Your WoW book. It has a table with options and trade-offs.
(CLICK) They learn about personas in the corresponding lookup table.
They identify that Personas are a likely option for addressing their problem, and decide to experiment with that strategy.
Optional: If you want to mention it, here is a quick description of read a process goal diagram. There are three parts
The process goal names
One or more decision points that are involved in the process goal
The options for a decision may or may not be ordered.
This is the goal diagram for the People Management process blade. Goal diagrams appear at all levels of the DA tool kit
See https://disciplinedagiledelivery.com/gci/ for a detailed discussion
Dr. Reifer is not aligned with any of the Agile frameworks or methods (he has no skin in this game)
Ivar Jacobson coined the term “method prison” in 2017
By trying to implement a prescriptive framework, we seem to have forgotten that agile was always about figuring out better ways of working, not following a prescribed approach
Disciplined Agile enables you to make better decisions regarding what techniques to experiment with.
This leads to quicker process improvement because more of your experiments succeed.
See https://disciplinedagiledelivery.com/gci/
This slide is animated
What to say
DA offers improvement through something we call Guided Continuous Improvement.
(Click). Going along with the current way of working, you will improve for a while but then gradually plateau.
(Click). The usual approacy to continuous improvement helps teams improve, helping you to escape the plateau.
(Click). With Guided Continuous Improvement, you use the DA tool kit to identify techniques that are more likely to succeed in your context.
(Click). This is what Disciplined Agile brings. More successful experiments, so you improve faster than the usual CI approach
(Click). The DA approach is to Start where you are, do the best you can, and always strive to get better.
What to do
This deck has the list of resources in one page. The 90 minute version has more details for each type of resource.
What to say
Here are some of the important resources for going further
Use these slides to summarize what has been said.
There are many opportunities for people to learn more about Disciplined Agile!
And you can always write to us for more information. Visit the Disciplined Agile website. We look forward to supporting and serving you.
