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

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 Fallacy of Instant Self-Organization: What Team Development Models Can Teach Us

Right from the outset, agile teams are expected to self-organize. Let’s take a team that just started practicing Scrum. To do Scrum well, they must self-organize how they plan the next two weeks’ worth of work during the iteration planning. They must self-organize how to coordinate today’s work during their standups. They must also self-organize how to solicit feedback on what they built (iteration demo) and how they built it (iteration retrospective). On top of that is the matter of actually self-organizing the work of building the actual solution they are working towards. 

That is a lot to ask any team, especially one that is newly formed, or one that has recently changed from their old way of working (WoW) to an agile WoW. I, for one, would venture that it is impossible. A newly formed team, or a team that recently changed WoW, have to normalize first before they can carry out those tasks in a self-organizing manner.

The fact that Scrum and other agile ways of working expect this from the outset is what I call the fallacy of instant self-organization.

What is team development?

Team development and team building often get mixed up. Let’s be clear, team development is not team building. Rather, team building can be a part of team development. Team building is a catch-all phrase for activities where colleagues get to know each other better as fellow humans, not just people at work. Team building can be anything from quick social games (like Pecha Kucha or two truths and a lie) or getting away from the office for a celebratory meal, drink or game of bowling.

Team development on the other hand is a deliberate process in which a team takes time to explore its potential; how it can become even greater than it’s been before. Team development is a journey.

What is a team development model?

There are plenty of team development models to pick from. How teams form and develop has been the fascination and research of many people.

Before we move on, let’s recall the wise aphorism by George Box: that “all models are wrong, but some are useful.” Models are like a pair of spectacles. They help us see the world with more clarity to make better sense of it. But they are all inherently “wrong” because they are not the world itself.

That said, models can be very useful and provide insight and guidance for our world of agile teams. As an agile practitioner, I find three models useful: Bruce Tuckman’s stages of team development model, the Drexler/Sibbet team performance model, and Patrick Lencioni’s five beaviors model.

What can we learn from team development models when it comes to self-organization?

Looking across all three models, we can extract some key points about team development.

First, there are no shortcuts to high performance. In all the models, the team has to travel a journey of set steps or stages before reaching high performance. The steps start out very basic, like building trust and getting to know each other, and progresses to something more advanced where we learn to solve work tasks together. This all seems like a given, but it is often overlooked or forgotten.

Secondly, even though the models all lay out the road to high performance as a neat step-by-step journey, the journey is not linear. We are dealing with people, not printers. People and their interactions are messy, complex and to a large degree unpredictable.

Thirdly, regression can happen anytime. As I discussed above, the scenario of a team that has recently changed their WoW is a prime example of team development regression. The abrupt change of their way of working (say, from a traditional approach to an agile WoW) can likely cause the team members to be unsure of their role on the team, how they are supposed to work together now, and can even erode some of the trust inside the team. Regression can also occur when team members come and go, and in the case of significant external changes, regression is always something to be on the lookout for, and it is always a question that leaders should ask themselves when they make changes. Can this change adversely impact the team’s journey to high performance?

The last and most important point seen from an agile practitioner’s perspective is that the models all offer guidance for the team’s journey. Take the Drexler/Sibbet model for example:

Source: http://www.robertmcneil.com/2016/02/12/the-drexler-sibbet-team-performance-model/

Not only does it tell you what’s going on in each stage (by naming the stage intuitively), it also describes how to move to the next step. If you look closely at the first step (Orientation: why am I here?), you see that if left unresolved, you will get patterns (or rather anti-patterns) of: disorientation, uncertainty, and fear. The tools that we as team leaders have to resolve this step and help the team onwards are: providing purpose, team identity and membership.

Continue your learning journey

The Disciplined Agile People Management process blade contains an overview of how to manage people in an agile enterprise.

The Disciplined Agile Grow Team Members process goal contains a collection of tools and practices of how to continuously grow our team members.

Posted by Klaus Boedker on: December 08, 2020 12:52 PM | Permalink | Comments (5)

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”).

Source: http://www.mtbunnies.com/

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: https://positivepsychology.com/emotional-intelligence-frameworks/

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)

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)

Stable Teams Over Project Teams

One of the interesting trends that we’re seeing within organizations taking a disciplined agile approach to solution delivery is the preference for stable teams. Stable teams, also called stable product teams or simply long-term teams, are exactly as they sound – they remain (reasonably) stable over time, lasting longer than the life of a single project. This blog explores the differences between project teams and stable teams and then overviews the advantages and disadvantages of the stable team approach.  We also explore the issue of how stable teams evolve over time.

Stable Teams

As you can see in the following diagram, with a project team approach we say that we bring the team to the work. What we mean by that is that we first identify the need to run a project, perhaps to build the new release of an existing solution or to build the initial release of a new solution, we build a team to do the work.   Once the work is done, in this case the solution is successfully released into production, the team is disbanded and its team members move on to other things.

Stable teams vs project teams

The stable team approach is a bit different. In this case we first build an effective team then we continuously bring valuable work to the team to accomplish. In this situation the work never really ends, but instead we replenish the team’s work item list (or work item pool depending on the lifecycle being followed) regularly. The team stays together and continues to produce value for your organization over time.

Of course the term “stable team” is a bit of a misnomer as they do evolve over time. For example, many people like to stay on a team for a couple of years and then move on to another team to gain new skills and perspectives. This is good for them and good for your organization as it helps to keep your teams fresh. Sometimes you will want to grow or shrink a team. Sometimes you will discover that two people aren’t working well together and you need to split them up. The point is that there are very good reasons for your stable teams to evolve over time.

We wouldn’t be disciplined if we didn’t explore the trade-offs involved with stable teams.

The Advantages of Stable Teams

There are several advantages to stable teams:

  1. Lower management overhead. There is clearly less “resource management” to be done because you’re not constantly forming and disbanding project teams. In fact, this lower need for resource management activities is one of several factors why agile IT organizations need managers than non-agile IT organizations.
  2. Easier team budgeting. The annual budget for a stable team is incredibly straightforward to calculate: Multiply the number of people on the team by the fully burdened cost of an IT person for your organization. Once again, less management work required for this.
  3. You build better teams. When you build project teams you tend to take the people who are currently available (often referred to as sitting on the bench). With a stable team approach you’re motivated to build your teams with the right people, and very often its best for the team to build itself by inviting others who they believe will fit in well.
  4. There is greater opportunities to build trust within the team.  It takes time to build trust within a team.  Greater trust leads to greater willingness to work together in a more streamlined manner.  As Stephen Covey insightfully points out, trust enables speed.
  5. There’s a greater opportunity for safety.  It takes time to build an environment where people feel safe. In safe environments there is a much greater chance that they will share ideas and be willing to try new things because they don’t fear being thought less of or even punished.
  6. There is less overhead from team formation. You’re forming teams far less often with a stable approach compared to a project team approach, hence there is less overhead in total for your organization.
  7. Better team performance.  Consider the analogy of a train.  Just like it takes time to bring the train up to cruising speed it takes time for the team to jell.  Bringing work to a seasoned team that works together well is like jumping onto a train going at full speed: it’s faster in both cases because you don’t have to get going from a full stop.
  8. You have more efficient utilization of staff. With this approach it is far less likely that someone will be “sitting on the bench” because they will instead be an active member of a team. When someone is hired it is directly into a team. Throughout their career they will move from team to team as appropriate. The only time that they might not be utilized is when their on vacation, sabbatical, or if you purposefully disband a team. The first two reasons are something you still have with the project team approach, and the last reason should happen a lot less often.
  9. Your teams are more likely to improve. When a team knows that they will be working together for a long time, and particularly when they are responsible for the entire delivery lifecycle from beginning to end, they are more likely to streamline their work so as to make things better for themselves.

 

The Disadvantages of Stable Teams

There are several disadvantages to stable teams:

  1. Teams can become too stable. A real danger of stable teams is the potential for groupthink – everyone on the team starts to think and work in a common way, thereby being in danger to common blindspots. Luckily people still want to move to other teams for career management reasons, offering the opportunity to bring new viewpoints into other teams. In the Disciplined Agile (DA) toolkit we have the continuous improvement process blade which supports sharing of ideas across teams so that can also lessen the chance of groupthink. And, as mentioned earlier, some people may need to be motivated to move on to another team for interpersonal reasons.
  2. You still may need to do projects. Sometimes your business team makes promises to their customers. For example, in a software company a sales person makes a big sale and promises that by a certain date your solution will have additional features that the customer needs (in immature organizations they’ll even make such promises without first negotiating this with the delivery team). Another example would be a financial institution that needs to fulfill new industry regulations that require changes to existing solutions. In both of these cases there is a large amount of work to be done that needs to be delivered before a certain date, and this may motivate you to treat this work as a project. You would still bring this work to the appropriate stable team(s) to accomplish as you normally would. However, you would also track the performance of the work to ensure that it is delivered in its entirety as appropriate. The implication is that projects may not completely go away

 

Evolving Stable Teams Over Time

Stable doesn’t mean stagnant.  Of course you still have basic people management issues such as people wanting to expand their skill set by working on something new by rotating to another team, people leaving the organization, and new people joining the organization.  So the team itself may go on for many years even though the membership of the team evolves over time.  Ideally these membership changes are not too disruptive: It’s not too bad adding a new person every month or so, or losing people at a similar rate, but gaining or losing several people in a short period of time can be painful.

 

Our Recommendation

Start experimenting with stable teams if you’re not already doing so. For most organizations the advantages clearly outweigh the disadvantages. In fact, you can see this in the Longevity decision point of the Form Initial Team goal diagram below.

Form Initial Team Process Goal

Posted by Scott Ambler on: November 13, 2016 09:24 AM | Permalink | Comments (0)

Agile Teams and The Breakfast Club

Categories: Analogy, Teams

The Breakfast Club

One of the iconic movies of the 1980s was The Breakfast Club, which told the story of five very different teenagers who were forced to come into school one Saturday to serve detention.  Recently I’ve been working at a large insurance company helping them to adopt the Disciplined Agile (DA) toolkit.  One of people whom I’m working with has a Breakfast Club poster on the wall near her work area and it got me thinking about some of the dynamics that I’ve seen watching agile teams form and eventually gel.  Here are my thoughts.

At the start of the movie the kids didn’t really like each other, they were very different from one another, they certainly didn’t want to be there, and they were each coming to the group with their own point of view and background.  Sadly, I’ve seen more than one software project team that was put together like this.  As the movie progressed they began to really talk with one another and their stories started to emerge.  They started to work together, hijinks ensued, and they bonded as a group.  As part of their punishment they were each asked to write an essay describing what they learned from their detention.  Instead they wrote a single letter, which follows, that they submitted as a team.

“Dear Mr. Vernon:

We accept the fact that we had to sacrifice a whole Saturday in detention for whatever it was we did wrong, but we think you’re crazy to make us write an essay telling you who we think we are. You see us as you want to see us… In the simplest terms and the most convenient definitions. But what we found out is that each one of us is a brain… …and an athlete… …and a basket case… …a princess… …and a criminal.

Does that answer your question? Sincerely yours, the Breakfast Club."

So how does this relate to agile teams?

  1. You often build teams from specialists.  Although we ideally recommend that you build teams from multi-disciplinary, T-skilled generalizing specialists, the reality is that many organizations are staffed with specialized people.  We like to say that you go to war with the army that you’ve got, or in other words you need to make do with what you have.  If all you have are specialized staff then that’s the people you have to form teams.  The good news is that you can help people to evolve from being specialists into generalizing specialists via building a cross-functional whole team, enabling and promote non-solo collaborative work within the team, and by training and coaching people.
  2. It takes time for a team to gel.  In the movie the “team” gelled in a single day, but it’s rarely that fast in practice.  It often takes weeks, and sometimes months, for a team to really get to the point where they’re working together effectively (yet another reason to move towards stable solution delivery teams).
  3. Co-location shortens the time it takes to gel.  When we’re co-located, everyone works together in the same room, it is much easier and much more likely that we will collaborate with one another.  Not only does this increased interaction help us to get the work done it also helps us to gel as a team faster.
  4. We’re not as different from each other as we think.  One of the lessons that the kids learned in the movie is that each one of them had a bit of an athlete, a brain, a criminal, and so on in them.  Similarly, we’re not just programmers, or architects, or analysts but instead we all have some of those skills in us and we can certainly get better at the skills that we are weak on.
  5. We are still different.  Every single person is a unique individual.  This implies that we must be flexible in the way that we collaborate with one another, that people simply aren’t “cogs in the corporate machine.”  We should also respect the fact that we each bring something of value to the team, a revelation that the kids in the movie stumbled upon when they had to work together to not get caught by Mr. Vernon (there were a few hijinks in the movie).
  6. Working together as a team produces better results than a group of individuals.  As Alistair Cockburn likes to say, software development is a team sport.  In the movie the kids all got caught doing something on their own, hence the punishment of a Saturday in detention, yet together they managed to have a fair bit of fun as a team.  Similarly, you may be the best programmer in the world, but it behooves you to work with people who can help you to understand the requirements, design the solution, validate the solution, and so on.
  7. We can all learn from each other.  Everyone has value to bring to the team and everyone has areas where they are weak on that could be improved.  By working closely together we can learn from each other and get better both as individuals and as a team.

The Breakfast Club is a great movie.  If you haven’t seen it, or haven’t seen it lately, then I highly suggest watching it again.

Posted by Scott Ambler on: October 06, 2016 11:48 AM | Permalink | Comments (0)
ADVERTISEMENTS

"The man who does not read books has no advantage over the man that can not read them."

- Mark Twain