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


View Posts By:

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

Recent Posts

Embracing Mindset Diversity in Disciplined Agile

Disciplined Agile: An Executive's Starting Point

Using Lean Agile Procurement (LAP) in complex procurement situations

Vendor Management in the Disciplined Agile Enterprise

Asset Management: What Types of Assets Might You Manage?

The parachute mind and other ways to improve group decision-making

So much of agile teams’ successes depend on collaborative decision-making. Take for example refining the backlog. That is a collaborative decision-making process where the development team, the architecture owner, and the product owner choose the relevant details of each user story. The retrospective is another collaborative undertaking where the team explores and decides how to improve their way of working. Solution modelling, user story estimation, story mapping, and big room planning are more examples of similar processes. The list goes on and on.

If decision-making should be truly collaborative during these processes, how can we encourage everyone to contribute? What can we do to make this work?

First, we need a model that gives us an overview of how group decision-making works. Sam Kaner’s dynamics of group decision-making is a great starting place. The model is split into three parts.

Source: “Facilitator’s Guide to Participatory Decision-Making” by Sam Kaner (2007)

Part 1: In the beginning, all ideas are welcome during divergent conversations. We begin with a question or unsolved challenge. As we explore the topic, we easily get to familiar options and opinions. The tricky part is moving past the familiar and uncovering new and fresh perspectives and ideas.

Part 2: Then, with a suite of diverse perspectives and options we enter the groan zone. That is exactly what it sounds like: uncomfortable, awkward, and seemingly dysfunctional. Questions arise. How do we move on? What’s the best idea? Are we stuck? This is the uncomfortable space of moving from “now-we-have-all-these-great-ideas” to, “how-do-we-decide-which-one-to-move-forward-with?” Misunderstanding and miscommunication are normal, natural aspects of the collaborative process. The groan zone is a healthy, unavoidable consequence of the diversity that exists in any group.

Part 3: Eventually, we steer towards the finish line in the convergent stage. This is where we condense the large number of ideas and options to one final decision that we move forward with.

Divergent thinking: ways to keep an open mind

Source: “Facilitator’s Guide to Participatory Decision-Making” by Sam Kaner (2007)

The parachute mind (it works best when open)
When starting the divergent stage, think of parachutes. They work best when fully open. The same goes for our minds in the stage of the process which can be easier said than done. Below are some practices that will help you keep your ‘parachute’ open.

Cognitive empathy
Cognitive empathy is the ability to empathize with how others on your team think. Approaching divergent thinking by embracing the fact that we all think differently and that there is no right or wrong way to think about the problem we are solving is a big step in the direction of keeping an open mind. There are a number of short games that illustrate cognitive empathy. One of them is “this is not a stick”.

This is not a stick
To play “this is not a stick” game you need a stick (or something similar, like a broom shaft) and a group of people (between 3-8). Someone starts the game by performing an action with the stick, say pretending to throw a javelin, and says: “this is not a stick, this is a ______”. The other people in the group then has to guess what the stick is. When someone guesses “javelin”, the stick is handed to the next person in the circle and they perform a new action, say, pretending to be fishing, while saying: “this is not a stick, this is a _______”. Playing the game for 8-10 minutes typically allows everyone to go at least twice.

Not only does the “this is a not a stick” game underline the importance of cognitive empathy, it also shows how the group the natural progression in the divergent stage of first coming across familiar options, like javelin and fishing pole, only to move to newer, more diverse perspectives when you build on each other’s ideas.

Yes, and!
Speaking of building off each other’s ideas, the “yes, and!” mindset is a great way to do that. This technique is borrowed from improv theatre where the performers continue each other’s sentences by saying: “yes, and!” The opposite of “yes, and!” is either “no!” (as in, that idea will never work) or the more subversive: “yes, but”. Saying “yes, but” means you cancel out whatever was said before the but and replace it with your own idea or opinion. Take the example of your co-worker, Bob, who presents his idea of selling yellow t-shirts. You know this will never work, so you start your sentence with: “Yes, I like that idea, but we know our customers prefer blue t-shirts”. You have effectively closed down Bob’s idea and replaced it with your own. That is the opposite of a parachute mind.

Using “yes, and!” a different response could be: “Yes, I like the idea of yellow t-shirts, and we can bundle them at a discounted price with our popular blue t-shirts to test the market’s appetite for yellow shirts.”

50 bad ideas
This last technique seems odd at first, and it can really help your team if they are stuck at the “familiar options” state in divergent thinking. Sometimes, you need sheer volume to move on to the newer, more diverse perspectives. Setting yourselves the goal of coming up with “50 bad ideas” can allow you to consider more ideas and move forward.

It works by writing down 50 bad ideas on individual post-it notes. Often it doesn’t take more than 5-7 minutes and it can loosen up the group with some laughs. When done, the group is often energized and has opened up their horizon and can move on to brainstorming newer, more diverse perspectives related to the challenge you are solving.

The groan zone: ways to grit it out

Source: “Facilitator’s Guide to Participatory Decision-Making” by Sam Kaner (2007)

In the groan zone, you can use several practices from divergent thinking as well: the parachute mind, cognitive empathy, and “yes, and!” In addition to those practices, there are a number of techniques to help you grit your way through the groan zone.

Active listening
There are three ways to listen: listening to yourself (“I feel like pizza tonight”), listening to others (“I see…”), and listening to others and taking their context into perspective (“It’s okay. I know you were just trying to help”).


To move successfully through the groan zone and safely make it to the convergent stage, we need to do our best to stay at level 2, and ideally at level 3.

Emotional intelligence
This state is often uncomfortable, awkward, and seemingly dysfunctional. Questions arise and doubt starts to creep in. How do we move on? How do we find the best idea? Can we even agree on what’s best? Just like misunderstanding and miscommunication are normal aspects of the collaborative process, so are our emotions.

The key is not to ignore and suppress the emotions as they arise in the group, but to deal with them in an intelligent way. So how do we do that?

Source: “Working with Emotional Intelligence” by Daniel Goleman (1998)
Image source:

Daniel Goleman’s competency framework can help us navigate how to deal with emotions in an intelligent way -as they arise inside ourselves, and as they arise inside the group. It starts with emotional self-awareness and self-management. Once we have dealt with our own emotions, we can focus on the emotions in the group setting (social awareness) and then manage the group emotions in an intelligent way (relationship management), safely guiding us to the last stage.

Convergent thinking: ways to get to the decision

Source: “Facilitator’s Guide to Participatory Decision-Making” by Sam Kaner (2007)

We are almost there. So close to the finish line. To get there we need a way to ‘boil down’ our great ideas discussed in the groan zone.

Clustering ideas
Clustering is a really simple way of narrowing down your ideas and options. The technique is exactly what it sounds like: you cluster together the sticky-notes with similar ideas and then give that group a meaningful name.

Some teams prefer to cluster ideas in silence to avoid influencing each other (group think bias). Others prefer to cluster in collaboration and conversation. The choice is yours. Experiment and use what works for your team.

Plotting ideas
Plotting ideas allows you to rank your ideas based on dimensions that are important to your team and context. Let’s say you create a 2x2 grid with these dimensions: “alignment with our team mission (low/high)” and “implementation effort (low/high).” When you plot your ideas into that grid, it will quickly become apparent which ones are highly aligned to your team mission and are low-effort to implement. These are the ideas you pursue first.

Again, some teams prefer to plot the ideas in silence to avoid influencing each other (group think bias), while others prefer to plot in collaboration and conversation. The choice is yours. Experiment and use what works for your team.

Dot voting
The final technique is called dot voting.

Dot voting is a way to ensure that everyone on the team has a say in the final decision. By giving all the team members three votes (represented by three sticky dots) and asking them to place them on the three ideas they most like, we create a fair, transparent, and balanced way of getting to the final decision. If you have a lot of similar ideas, dot voting works even better when you cluster the ideas first.

Dot voting is always done in silence. When finished, one team member tallies the scores, and you can move forward with the winning idea.

Posted by Klaus Boedker on: November 11, 2020 10:15 PM | Permalink | Comments (12)

For the want of a whiteboard....

Categories: Collaboration

For the want of a whiteboard the vision was lost,

For the want of a new vision the release was lost,

For the want of a new release the product was lost,

For the want of a new product the customer was lost,

For the want of a new customer the company was lost,

And all for the want of a whiteboard.

With a nod to Benjamin Franklin.

Posted by Scott Ambler on: April 12, 2017 07:35 AM | Permalink | Comments (0)

Choose the Best Communication Technique Available

Recently on the DAD LinkedIn discussion forum we’ve had an interesting conversation going on that strayed into the effectiveness of various communication techniques.  This conversation got me to thinking a bit about an article that I first wrote over a decade ago, Communication on Agile Software Projects, based on material in my Agile Modeling book.  This article extends some of Alistair Cockburn’s thinking on the topic, summarized in Figure 1, which in turn extends a body of work called Media Richness Theory.  The basic observation is that the richer the communication channel – such as email, videoconferencing, or face-to-face conversation – the more effective it is in practice.

Figure 1. Comparing the effectiveness of communication techniques.

Communication Modes

In the DAD book Mark and I said that the implication of Figure 1 was that given the situation you find yourself in that you should choose to use the most effective communication strategy available to you.  We thought that this was all that needed to be said, but since then we’ve come to realize that a better diagram is needed.  We developed Figure 2 which we believe communicates this strategy a bit more clearly.

Figure 2. Choosing the best communication technique for your situation.

Communication Modes Implications

Figure 2 indicates that that the viability of communication options available to you varies depending on the situation that you find yourself in.  For example, people on a co-located team can communication in pretty much any manner they choose.  Ideally they would choose face-to-face communication around a whiteboard or paper but there’s nothing stopping someone from writing a detailed document and then emailing it to someone sitting beside them.  When a team is geographically distributed they have fewer communication strategies available to them, unless of course they invest in travel so that they can be face-to-face.

Figure 2 also indicates strategies for capturing, or persisting, a conversation.  For example, a few people could have a conversation around a whiteboard, sketching the design of a screen perhaps.  When they’re done they might decide to take a digital snapshot of it so that they can retain the diagram to work on it later (many organizations still don’t provide permanent whiteboard space to their development teams).  They may even choose to have someone write up notes, perhaps on a wiki or in a word processor, and embed the snapshot(s) into those notes.

To summarize, when it comes to how people communicate with one another they have choices.  Disciplined agilists prefer to choose the most appropriate communication strategy for the situation that they find themselves in.

Posted by Scott Ambler on: January 09, 2014 04:03 AM | Permalink | Comments (0)

Coordinating activities on agile delivery teams

One of the key characteristics of Disciplined Agile (DA) is that it is goal driven rather than prescriptive.   This simplifies process tailoring, simplifies identifying potential process improvements, reduces the prescription inherent in other software methods, and enables scaling.  One of the process goals identified by the DA toolkit is Coordinate Activities, one of the ongoing goals throughout the delivery effort.  The fundamental question that this goal addresses is what options do individuals on an agile team have to coordinate their work with other people that they are involved with?  Note that this work may not occur completely within the team, that team members may find that they need to coordinate with people external to their team.

The process goal diagram for Coordinate Activities is shown below.  The rounded rectangle indicates the goal, the squared rectangles indicate issues or process factors that you may need to consider, and the lists in the right hand column represent potential strategies or practices that you may choose to adopt to address those issues.  The lists with an arrow to the left are ordered, indicating that in general the options at the top of the list are more preferable from an agile point of view than the options towards the bottom.  The highlighted options (bolded and italicized) indicate default starting points for teams looking for a good place to start but who don’t want to invest a lot of time in process tailoring right now.  Each of these practices/strategies has advantages and disadvantages, and none are perfect in all situations, which is why it is important to understand the options you have available to you.

An interesting thing about this process goal diagram is that it makes it very clear that there might be a bit more to coordination on an agile team than just holding a short meeting every day.  For example, people may share information within the team, and with people external to the team, via conversations, reviews, and non-solo development techniques such as pair programming or modeling with others.  Another interesting thing is that to avoid the problem of method branding we use descriptive terms such as Coordination Meeting instead of Scrum Meeting or Daily Scrum.

Several of the issues are team focused, in particular Artifact Ownership and Coordinate Within Team.  Several reflect the fact that DA teams are enterprise aware and thus describe strategies to coordinate with others external to the team.  For example, your team may need to coordinate with your organization’s enterprise architects and operations staff, potentially adopting some of the strategies captured by Coordinate Across IT (and you are also likely to do so via Share Information strategies).  If your organization has a release organization then your team may need to adopt one or more Coordinate Release Schedule strategies (or, if there’s no release team then your team will still need to coordinate releases with other delivery teams, and with your operations team, somehow).

Several issues address scaling factors.  For example, large teams (often called programmes) will find that they need to adopt strategies called out by Coordinate Within Program.  Teams that are geographically distributed or organizationally distributed will need to consider strategies from Coordinate Between Locations.  Naturally if you don’t face a scaling issue such as geographic distribution then the issue Coordinate Between Locations isn’t something you need to consider.

I wanted to share two important observations about this goal.  First, this goal, along with Explore Scope, Identify Architecture Strategy, and Accelerate Value Delivery seem to take the brunt of your process tailoring efforts when working at scale.  It really does seem to be one of those Pareto situations where 20% addresses 80% of the work, more on this in a future blog posting.  Second, as with all process goal diagrams, the one above doesn’t provide an exhaustive list of options although it does provide a pretty good start.

I’m a firm believer that a team should tailor their strategy, including their team structure, their work environment, and their process, to reflect the situation that they find themselves in.  When it comes to process tailoring, process goal diagrams not only help teams to identify the issues they need to consider they also summarize potential options available to them.  Agile teams with a minimal bit of process guidance such as this are in a much better situation to tailor their approach that teams that are trying to figure it out on their own.  The DA toolkit provides this guidance.

Posted by Scott Ambler on: July 12, 2013 09:41 AM | Permalink | Comments (0)

"The most exciting phrase to hear in science, the one that heralds new discoveries, is not Eureka! (I found it!) but rather, 'hmm.... that's funny...'"

- Isaac Asimov