Project Management

Disciplined Agile

by , , , , , , , , ,
This blog contains details about various aspects of PMI's Disciplined Agile (DA) tool kit, including new and upcoming topics.

About this Blog

RSS

View Posts By:

Scott Ambler
Glen Little
Mark Lines
Valentin Mocanu
Daniel Gagnon
Michael Richardson
Joshua Barnes
Kashmir Birk
Klaus Boedker
Mike Griffiths

Recent Posts

The Disciplined Agile Enterprise (DAE) Layer

Disciplined Agile (DA)'s Value Streams Layer

The Disciplined DevOps Layer

Would you like to get involved with the 20th Anniversary of Agile?

The Four Layers of the Disciplined Agile Tool Kit

The Disciplined Agile Foundation Layer

Disciplined Agile Foundation Layer

The Disciplined Agile (DA) tool kit is organized into four layers: Foundation, Disciplined DevOps, Value Streams, Disciplined Agile Enterprise (DAE).  This blog focuses on the Foundation layer, the purpose of which is to provide the underpinnings of the DA tool kit.  The foundation layer itself is organized into four distinct topics:

  1. The DA mindset
  2. Fundamental concepts
  3. People
  4. Choosing your WoW

 

The DA Mindset

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 behaviours and follow these guidelines when doing so. There is a purpose for each aspect of the mindset:

  • 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 behaviours 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.

The Disciplined Agile Mindset

 

Fundamental Concepts

Disciplined Agile (DA) is a hybrid in that it adopts ideas and strategies from a wide range of sources. DA encompasses three categories of fundamental concepts:

  1. Agile. Agile is both a mindset and a skillset. As a mindset Agile is the manner in how you look at your environment; it is the desire to collaborate with and to learn from others; and it is the willingness to share your skills and knowledge with others.  As a skillset Agile varies based on the domain in which you operate.  For example, an agile skillset for a marketing professional may include experimental strategies such as minimum viable products (MVPs) and marketplace sensing strategies, whereas an agile skillset for a software professional may include test-driven development (TDD) and chaos engineering techniques. Agility is the ready ability to move with quick and easy grace to respond to changes in your operating environment.  
  2. Lean.  Lean produces value for customers quickly through a focus on reducing delays and eliminating waste which results in increased quality and lower cost. Lean philosophies and strategies infuse DA, and in fact much of the DA mindset reflects lean thinking. This includes ideas such as optimizing flow, making all work and workflow visible, keeping workloads within capacity, and attending to relationships throughout the value stream to name a few. 
  3. Serial. DA adopts great ideas from serial - often referred to as traditional, waterfall, or even predictive - ways of working (WoW). There are many strategies and concepts from the past which are critical to our success in the future, and DA chooses to leverage them where they make sense. For example, DA's project-oriented lifecycles have explicit, named phases which are clearly serial in nature. DA recognizes that inception efforts, sometimes called  project initiation or simply initiation activities, such as initial planning, initial scoping, and initial design can be critical to your success.  These efforts are very different than the construction/realization efforts that happen after this, and different yet again than the transition/delivery efforts that then follow, and different again than the operational efforts that bring actual realized value to your customers.

 

People

The people portion of the Foundation layer addresses two key aspects of agility:

  1. Roles (and responsibilities). The DA tool kit captures a wide range of roles that people may fill.  This includes common agile roles such as Team Lead/Senior Scrum Master, Product Owner, Architecture Owner, and others.  It also includes function-specific roles such as Program Manager, Financial Specialist, Governor, Security Engineer, Sales Manager, and many others.  All of these roles have associated responsibilities, and of course there are common rights and responsibilities that everyone has.
  2. Teams. Every team is unique and faces a unique situation.  As a result, DA supports several team structures which your teams can adopt and evolve to meet their needs.  There are suggested structures for small, medium, and large (program) teams.  There are team structures that support geographic distribution.  There are team structures that support learning teams such as communities of practice (COPs)/guilds and centres of excellence (CoEs), and structures that support common services teams.

 

Choosing Your WoW

A fundamental philosophy of agile is that teams should own their own process, or as we like to say in Disciplined Agile (DA) teams should choose their way of working (WoW). Of course this is easier said than done in practice. The challenge is that every team is unique and faces a unique situation – in other words, context counts. Furthermore, there are no “best practices,” rather, every practice has tradeoffs and works well in some situations and poorly in others. Worse yet, you really don’t know how well a technique will work for you until you actually try it out in your environment. Given all of this, how can a team choose its WoW?

While working with organizations to help them to learn how to improve their WoW, we’ve developed a technique that we call guided continuous improvement (GCI). GCI extends the kaizen-based continuous improvement approach, where teams improve their WoW via small incremental changes, to use proven guidance to help teams identify techniques that are more likely to work in their context. This increases the percentage of successful experiments and thereby increases your overall rate of process improvement.

Posted by Scott Ambler on: July 29, 2020 12:06 PM | Permalink | Comments (6)

Guided Continuous Improvement (GCI) article is now online

While working with organizations to help them to learn how to improve their way of working (WoW), we’ve developed a technique that we call guided continuous improvement (GCI).  Adopting an agile method such as Scrum, or a framework such as SAFe, may give you an initial start at improving your WoW you will quickly find yourself in “method prison.” The organizations that break out of method prison do so with a kaizen-based continuous improvement approach, or better yet GCI.

First, some definitions:

  • A kaizen loop is an approach where a team experiments with a small change in their WoW, adopting the change if it works in their given context and abandoning it if it doesn’t.
  • Continuous improvement is the act of applying a series of kaizen loops to improve your WoW over time.
  • Guided continuous improvement (GCI) extends the kaizen loop strategy to use proven guidance to help teams identify techniques that are likely to work in their context.  This increases the percentage of successful experiments and thereby increases the overall rate of process improvement.

In the article we go into the details of the technique, exploring:

  • Why every team is unique
  • Why agile methods/frameworks will only get you so far
  • How to apply a kaizen-based improvement strategy
  • How to improve kaizen loops with the DA toolkit
  • How to break out of “method prison”

We hope you find the article to be a game changer for your agile adoption efforts.

Posted by Scott Ambler on: April 26, 2019 06:19 AM | Permalink | Comments (0)

Terraforming: Evolving Your Agile Workspace

Terraforming

Terraforming is the act of making an environment suitable for human habitation.  Terraforming has been popularized in science fiction as the act of evolving a planetary ecosystem, but in our context terraforming is the act of evolving your team’s physical workspace to make it more habitable for you to work.  Doing so in an important enabler for improving your way of working (WoW).

The Evolve Way of Working (WoW) process goal, the diagram for which is shown in Figure 1, involves several decision points that are pertinent to terraforming. In Disciplined Agile (DA) our philosophy is that teams should choose and evolve their WoW over time as they learn, and an important aspect of doing so is to recognize that you should be able to evolve your physical as well as virtual workspace.

Figure 1. The Evolve Way of Working (WoW) process goal diagram (click to expand).

Evolve WoW process goals

As you’d expect, you have choices available to you.  In Figure 1 there are three decision points relevant to terraforming:

  1. Organize Physical Environment. There are many options for organizing your physical environment.  A key issue is that you want people to be as close to one another as possible – the further away you are from someone the less likely you are to interact with one another, and the harder it becomes to share ideas and information. Ideally you want your team to have its own work room or at least be in a common open area together.  Having said that, it’s still useful to have “caves” or separate collaboration areas where people can escape to as needed to focus their efforts.
  2. Choose Communication Styles. Some people are leery of work rooms or common workspaces because they’re afraid that they won’t be able to concentrate due to the noise.  There has in fact been numerous studies that show that productivity drops when people are forced to work in open work areas or worse yet “hoteling” desks.  Yes, this is definitely a problem.  However, it is vitally important to differentiate between the noise generated by people who aren’t working on your team and the information/discussions generated by those who are. In short, I want to hear what my fellow teammates are saying but not what the stranger beside me is. When your office is organized in an “open” manner we’ve found that you should strive to have everyone on your team is sitting together.  Furthermore, erect sound barriers (such as sound-proof whiteboards or moveable walls) between you and the other teams near by to provide further focus.  And speaking about whiteboards, you can never have too many.
  3. Choose Collaboration Styles. The more flexible your physical workspace the greater your ability to collaborate with one another in an effective manner.

We’ve found that a great strategy for a company is to make physical things such as furniture and whiteboards readily available to teams.  Something as simple as a room full of (currently) unused furniture that a team can simply take from, or contribute things they’re no longer using into, goes a long way to providing flexibility.  And of course allowing teams to buy what they need, when they need it, is also crucial.  Smart organizations realize thatone of the best investments they’ll ever make is to spend a few thousand dollars on furniture and whiteboards to enable a team of people earning five or six figure annual incomes to improve their WoW.

Ideas for this blog was adapted from the book Choose Your WoW! This book is a handbook overviewing hundreds of agnostic techniques and strategies that agile and lean teams may decide to experiment with to see how well they work in the situation that they face.

Posted by Scott Ambler on: March 08, 2019 02:56 PM | Permalink | Comments (0)

Evolving Your Agile Way of Working (WoW)

Butterfly emerges

Choosing your way of working (WoW) isn’t just a one-time event, instead it is an ongoing effort.  Figure 1 shows the workflow for choosing and then evolving your WoW.  In our previous blog, Choosing Your Initial Way of Working (WoW), we worked through the left-hand side of Figure 1.  In this blog we explore how a team evolves their WoW via a series of experiments, hopefully ones that are guided by the Disciplined Agile (DA) toolkit.

Figure 1. The workflow for choosing and evolving your WoW.

Tailoring and Evolving Your WoW

As you can see in Figure 1, evolving your WoW is a two-step process at a high-level.  First, you identify that you have a potential issue with your current WoW and second you experiment with one or more potential improvements that you believe will address the issue that you’ve identified.  And of course you repeat this strategy whenever needed.

Identify Potential Process Issue

There are various ways that a team can identify a potential process issue:

  1. Retrospectives. Retrospectives are a strategy for a team to reflect upon what is working well for them and what isn’t working so well. Some teams, particularly agile ones, will choose to hold a retrospective at the end of each iteration/sprint whereas lean teams tend to hold them on an as needed basis.  Regardless, one of the outputs of such a working session is a list of one or more potential issues the team wants to address.
  2. Someone recognizes there’s an issue. Sometimes it’s as simple as someone saying “Hey, I think that X is a problem. Is there anything we can do about it?”
  3. Someone from outside the team points it out. It can also be as simple as someone from outside of the team – one of your stakeholders, a colleague on another team, a leader within your organization, or others – identifying a potential issue.

The point is that there are multiple ways that potential issues are identified.  So what are you going to do about them?

Experiment with Potential Improvement(s)

For any process issues that you believe you can address, the next step is to experiment with one or more potential solutions. Experiment?  What?!?!?!?!  That’s right, experiment. Any given practice works well in some situations but not in others.  Just because a technique worked well for another team, maybe even one that you’ve worked on in the past, that doesn’t mean that it will work well for your team in the context of the situation that you currently face. There is no such thing as a best practice, regardless of the endless marketing you may have heard telling you otherwise.

What you need to do as a team is to identify ways that you can potentially address an issue, narrow down your options, and see how well a given technique works for you by trying it out in practice.  In other words, you need to run an experiment.  Figure 2 depicts a continuous improvement loop, also known as a “kaizen loop,” where you choose a technique to experiment with, you try it for a sufficient amount of time to determine whether it works for you, and then you decide what aspects of the technique (if any) you should keep and which you should abandon.  And if you’re enterprise aware your team will share your learnings with others.  Guided continuous improvement takes this one step further by employing the DA toolkit to help identify potential new WoW for you to experiment with that is more likely to work for you, thereby increasing your team’s rate of improvement.  Better decisions lead to better outcomes.

Figure 2. Guided continuous improvement.

Experiment to evolve your WoW

An Example

Let’s consider an example.  We’ve been working together as a team for several months, have released the initial version of our solution into production, and have been working on our next release for about a month.  Our Team Lead has informed us that we’ve coming to the end of the funding for the team.  When we formed the team we received funding for a 6-month project, following our company’s fixed cost approach to funding solution delivery teams.  Our team expanded in size so that we could become a complete, whole team, and a side effect of that is that after a bit more than 4 months we’ve run out of money.  This is a problem that the team needs to address.

Terry, our Team Lead, gathers the team to work through the issue.  The first thing we do is discuss whether this is an issue that we can even influence.  The Team Lead believes that we can because our organization’s leadership is very happy with our work and can see the value in the product that we’re working on.  Because they have been receiving advice from an Executive Agile Coach they are beginning to realize that the way that they fund teams needs to evolve. Terry believes that our team is in a position to suggest, and then experiment with, a new approach to funding.

As a team we discuss what we need to do, realizing that there are really two issues commingled here: First, we’re funding a project, not the actual team.  Second, we’re taking a fixed-price approach. Carlos, our Agile Coach, suggests that we review the options captured by the Secure Funding process goal, the goal diagram for which is shown in Figure 3. It indicates that both project-based funding and fixed-price funding are the least effective options for agile teams, and more importantly it also indicates that there are better options available to us.  We look up the trade-offs associated with the options in our copies of Choose Your WoW! and after a bit of heated discussion agree that we should suggest to our management team that we adopt a stage-gate funding strategy for a product (long-lived) team.  Several of us wanted to push for a time-and-materials (T&M) approach, but we felt that would be a future improvement that we could experiment with once we’re successful with stage-gate funding.

Figure 3. The Secure Funding process goal diagram.

Secure Funding process goal

Terry, with the support of Polly (our Product Owner), manages to convince our senior managers to experiment with a new approach to financing.  Terry and Polly were able to describe the trade-offs associated with both the existing approach to funding and their suggested new approach. Interestingly, their suggestion was whole-heartedly supported by Florinda our finance officer.  She’s been concerned for several years about the way that IT projects have been funded, and is eager to move from a cost-based funding model towards one focused on investing our company’s money wisely. Our team was given the go-ahead to try the new funding strategy.

Sure enough, we run the experiment with stage-gate funding of a product team and it works well.  Our “stages” were three months in length, and after two rounds of such funding we successfully experimented with a T&M approach as we’d originally hoped.

Posted by Scott Ambler on: February 14, 2019 11:10 AM | Permalink | Comments (0)

Choosing Your Initial Way of Working (WoW)

Small number of choices

A fundamental philosophy of agile is that teams should be allowed to own their process, to choose their way of working (WoW). In Disciplined Agile (DA) we take it one step further with the idea that teams should not only be allowed to choose their WoW, they should be supported and enabled in doing so.  In other words, let’s help teams to be awesome.

Figure 1 depicts the workflow for how a team can choose and then evolve their WoW. The workflow shows four key activities that a team will iteratively work through as they need. In this blog we focus on initially choosing your team’s WoW.

Figure 1. The workflow for choosing and evolving your WoW (click to enlarge).

Tailoring and Evolving Your WoW

When adopting your initial WoW, the first thing to do is to identify whether you team is allowed to choose its WoW or whether one has been chosen for them. Let’s start by exploring how you would proceed if you’re allowed to choose your own WoW.

Tailoring Your Initial WoW

When a team is allowed to choose its own WoW the first step is to select the appropriate lifecycle given the situation faced by the team. Lifecycles, in some ways, are “methods” in that they show the high-level workflow for a team. They are the glue that combines detailed techniques/practices into a coherent whole (more on this below). Disciplined Agile Delivery (DAD) supports several lifecycles:

  1. Agile. A Scrum-based project lifecycle.
  2. Lean. A Kanban-based project lifecycle.
  3. Continuous Delivery: Agile. A Scrum-based lifecycle for long-standing product teams.
  4. Continuous Delivery: Lean. A Kanban-based lifecycle for long-standing product teams.
  5. Exploratory. An experimentation-based lifecycle, based on Lean Startup, for exploring marketplace needs.
  6. Program. A lifecycle for a large “team of teams.”

Although the focus of DA is on agile and lean ways of working, DA recognizes that in some cases you may still decide to adopt a waterfall/serial lifecycle. DA doesn’t explicitly support waterfall, but as you can see in Figure 2 we do recognize that in very low-risk situations a traditional approach makes sense.

Figure 2. A flowchart summarizing how to choose a lifecycle (click to enlarge).

Selecting an agile lifecycle

Your lifecycle will of course evolve, either incrementally via normal evolution of your WoW or because your team explicitly decides to adopt a different one (once they’ve learned more about themselves as a team).

Once your team has chosen an initial lifecycle, the next is to select the detailed techniques that you’re going to follow as a team.  This is typically done as a series of process tailoring workshops where the team works through the appropriate goal diagrams to identify how they want to work together.  Figure 3 depicts the goal diagram for Secure Funding, you can see how it walks you through the decision points that you need to consider and potential techniques for addressing those decision points. Don’t worry, if you’re not familiar with all of the options they are described in the book Choose Your WoW!, with a description and the trade-offs associated with each technique summarized in tables. Knowing your options, and the trade-offs associated with them, enables your team to make better process decisions (which in turn leads to better process outcomes). This is something we call guided continuous improvement.

Figure 3. The Secure Funding process goal (click to enlarge).

Secure Funding process goal

In theory it’s possible to do a single “big bang” process tailoring workshop when a team is in initially formed, but we’ve found that leads to process bloat because the team has to guess at too many things all at once.  Unless you’re in a regulatory environment requiring defined process descriptions up front, it’s usually better to tailor your WoW in stages on an as-needed basis.

Adopt Existing Method or Framework

In some organizations teams are still not allowed to choose their WoW.  This may happen for several reasons:

  • The organization is new to agile.
  • Your organizational leadership wants every team to follow the same process (this is a spectacularly bad idea because context counts). This is often because they don’t understand that you can have a consistent governance process without inflicting the same process on all the teams.
  • You’ve hired coaches that only know one method or framework.
  • Leadership still has a command-and-control culture or they don’t trust your team to do this (either because you don’t have the experience required on your team or because you’re not using something like the DA toolkit yet).
  • You’re in a regulatory environment (e.g. medical device development) and don’t realize that you can choose and evolve your WoW in any way that you like, as long as you remain compliant and document what you do (yes, that’s annoying).

The problem with forcing a team to follow an existing method or framework, no matter how popular it is, is that it rarely fits the situation faced by the team. It might be a great method, but it’s the wrong one for the team – context counts, every team is unique and faces a unique situation, so should be allowed to choose and evolve their own WoW to enable them to be as effective as they can be. Think of it like this: If a team is competent enough to build a solution for their stakeholders, surely they must also be competent enough (perhaps given a bit of help) to choose their own WoW?

Regardless of whether you were allowed to choose your initial WoW or had one forced upon your team, this is only a start. Your team will still want to evolve your WoW as you learn and as your situation evolves. More on this in our next blog.

MORE INFORMATION


For more information about how your agile team can choose and evolve its way of work, we recommend our book Choose Your WoW! A Disciplined Agile Delivery Handbook for Optimizing Your Way of Working. If you want to succeed at enterprise agile you need choices, not prescriptions.

Posted by Scott Ambler on: February 06, 2019 08:19 AM | Permalink | Comments (0)
ADVERTISEMENTS

"There's nothing remarkable about it. All one has to do is hit the right keys at the right time and the instrument plays itself."

- Johann Sebastian Bach

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events