Disciplined Agile

Remote agile teams typically use more video conferencing and extra written communication than collocated teams to stay synchronized. While perhaps not as effective as direct face-to-face communication, these approaches make up some of what is lost from sitting together and provide the advantage of being easily recorded for later access.

This asynchronous access to information is especially valuable for globally remote teams that may not share the same work hours. By accessing content on-demand, people can contribute when works best for them and sync up with the rest of the team at preset events.

Remote Onboarding Challenges

Onboarding new team members can be a challenge for remote teams. Introducing team members, explaining agreed to norms around process and tools are traditionally done in-person. Writing all of this information down along with the justifications and discussions around the decision process is a significant undertaking.

GitLab, one of the most successful all-remote agile development organizations, has onboarding materials that would occupy over 8,000 pages if printed. As organizations transition to more remote-friendly structures, documenting how teams work is becoming more critical.

Disciplined Agile for Onboarding

Fortunately, Disciplined Agile (DA) can help. It contains a vast tool kit of approaches accompanied by industry vetted analysis of when they add value when they do not, along with the pros and cons of implementing them. Teams can use the DA tool kit as the starting point for describing their way of working.

Using the upcoming DA Profiler tool, teams can debate, discuss and decide on their ways of working. The tool captures the goals, decision points and trade-off tables of each selected process or technique. Then, when new team members join, they can be pointed to the saved profile representing the team’s way of working. This saves creating lengthy onboarding materials and descriptions of processes.

Of course, processes should not remain static but instead, continue to evolve as teams and businesses learn and develop. So, at regular intervals, teams are encouraged to review and update their way of working and create a new definition. DA provides a robust strategy to support this and the goal “Evolve Way of Working.”

Keeping it Real

A strength of DA is its realism and pragmatism towards how organizations work. Not all organizations are fully agile yet, nor perhaps want to be. So, if some traditional, serial practices are still in use, that is OK; DA supports it. If Team A uses Scrum with two-week Sprints, Team B uses Kanban with continuous flow, and Team C uses SAFe, that works too.

DA is approach agnostic and capable of supporting a variety of popular techniques along with custom hybrid solutions. It also embraces a set of principles that make building guidance for remote agile teams more successful. These include: “Be pragmatic,” “Context counts,” “Choice is good” and “Enterprise awareness.”  These principles provide practical advice teams can apply to define their remote ways of working.

Mind Your Toes

Returning to the GitLab onboarding process, they promote a fun principle called “Short toes,” which comes from when people join the company and frequently say, “I don’t want to step on anyone’s toes.”

At GitLab, they aim to be accepting of people taking the initiative in trying to improve things. They recognize that as organizations grow, their decision-making speed often slows since more people are involved. However, this can be counteracted by having short toes and feeling comfortable letting others contribute to their domain.

Short toes is a great concept that is required if organizations are to scale and evolve successfully. It aligns well with another of DA’s principles, “Be awesome,” which is all about striving to be the best that we can and to always get better.

Summary

Adapting to the challenges of more remote team members and new all-remote teams creates the need for better onboarding resources.

DA provides great scaffolding to build onboarding handbooks that document how teams have selected to work without making manuals with thousands of pages.  It supports group-based discussion and selection of techniques, ongoing refinement and offline access. Perfect for onboarding today’s increasingly remote workforce.

This blog posting has been replaced with Risk-Based Milestones.

You may also be interested in How Disciplined Agile Teams Address Risk.

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.

Quick answer

The term predictive is deceptive.

Detailed answer

In the Disciplined Agile (DA) tool kit we use the term traditional or serial, rather than predictive or waterfall, to refer to the classic/linear ways of working.  We feel that predictive is deceptive, more on this in a minute, and waterfall to be insulting (albeit still in common use within the IT community).  Furthermore, we're starting to move away from using traditional as we're now seeing a generation of practitioners who feel that some of the older agile approaches, in particular Scrum, are traditional ways of working.

There are several reasons for why we feel the term "predictive" to be deceptive:

1. "Predictive" implies predictable.  Predictive is defined as "relating to the ability to predict" whereas predictable is "something that happens in a way or at a time that you know about before it happens."  Something that is predictable is a sure thing, yet something that is predictive is not. This is an important difference, particularly given that we know that projects aren't completely predictable - otherwise we wouldn't need risk management.
2. "Predictive" approaches to IT projects are a poor choice in most cases.  Years ago I led a study for Dr. Dobb's Journal that investigated the effectiveness of different approaches (agile, lean, iterative, ad hoc, and traditional) to IT projects.  We found that traditional strategies were less effective in practice than agile and lean approaches, and we weren't the only ones to have found this.  We also investigated what was initially predicted at the beginning of the project and what actually happened by the end of the project, and once again traditional approaches didn't do as well as agile & lean.  BUT, I must stress that the study focus was on IT projects only, not on projects in general.  
3. "Predictive" approaches to intangible projects are likely a poor choice  DDJ found, in several studies in fact, that "predictive" strategies were less predictable in practice than agile/lean approaches in IT.  I highly suspect that this is true of intangible projects in general although do not have hard data to back up that claim.  We need to investigate this.
4. "Predictive" approaches to tangible projects are likely a good choice, but I suspect we can do better.  I suspect that "predictive" approaches are more appropriate for tangible projects, such as building houses or buildings, than agile/lean approaches.  I also believe that a hybrid approach combining the best from traditional, agile, and lean strategies is likely better than traditional alone. Having said this, as with the previous point, I don't know of any research that has compared the various project management paradigms for tangible projects, so this too is something we need to investigate.

In short, we know that "predictive" is a deceptive term for a large category of projects and suspect this to be true for other project types.  As a result the only use of the term predictive in DA is to tell you that we don't use it.

A Disciplined Agile Enterprise (DAE) is able to sense and respond swiftly to changes in the marketplace. It does this through an organizational culture and structure that facilitates change within the context of the situation that it faces. Such organizations require a learning mindset in the mainstream business and underlying lean and agile processes to drive innovation.

The DAE layer is one of the four layers of the Disciplined Agile (DA) tool kit, overviewed in Figure 1.  These layers are: Foundation, Disciplined DevOps, Value Streams, and Disciplined Agile Enterprise (DAE).  This blog focuses on the DAE layer.

Figure 1. The layers of the DA tool kit.

The Disciplined Agile Enterprise (DAE) layer encompasses the capabilities required to guide your organization, to coordinate the teams/groups within your organization, and to support the value streams offered by it.  Figure 2 summarizes the DA tool kit and Figure 3 overviews the process blades that are specific to the DAE layer.  Several process blades of the DAE layer - Research & Development, Business Operations, Strategy, Governance, Marketing, Continuous Improvement, and Sales  - are shared with the value streams layer. The are "shared" in that the scope of these process blades may focus on both the entire organization and specifically on individual value streams.  For example, a financial institution may execute an organization-wide marketing strategy as well as specific strategies for their retail and corporate value streams.

Figure 2. The Disciplined Agile (DA) tool kit.

Figure 3. The process blades specific to the DAE layer.

Expanding upon the value streams layer, the DAE layer adds the following blades:

• Asset management
• Enterprise architecture
• Finance
• Information technology
• Legal
• People management
• Transformation
• Vendor management

Asset management

The asset management process blade addresses the purposeful creation (or rescue), management, support, and governance of organizational assets.  This includes financial, inventory, contractual, risk management, and strategic decisions of these organizational assets. 

Enterprise architecture

The enterprise architecture (EA) process blade overviews how a Disciplined Agile EA team will work. An agile enterprise architecture is flexible, easily extended, and easily evolved collection of structures and processes upon which your organization is built. The act of agile enterprise architecture is the collaborative and evolutionary exploration and potential capture of an organization’s architectural ecosystem in a context-sensitive manner. The implications are that enterprise architects must be willing to work in a collaborative and flexible manner and that delivery teams must be willing to work closely with enterprise architects.

Finance

The finance process blade addresses a collection of potentially competing goals, such as ensuring cash flow within your organization, ensuring your money is being spent well, taxes are minimized, spending is properly tracked and recorded, and legal financial reporting is being performed properly. All of this will be performed in a manner that is compliant with applicable financial regulations, such as Financial Accounting Standards Board (FASB) and International Accounting Standards Board (IASB) guidelines.

Information technology

The information technology (IT) process blade encapsulates the activities required to provide IT capabilities to the rest of the organization.  This includes managing information technologies, data resources, applications, and IT infrastructure.

Legal

The aim of the Legal process blade is to ensure that your organization works within the parameters of the law of any and all legal territories in which you operate. Your legal team will work closely with your vendor management people on (Agile) contracts; with your people management team to ensure that their strategies reflect the local statutes and to help educate staff in legal concerns; with your marketing team to guide what they’re legally able to promise; with your strategy team to ensure the direction they're taking the organization is legally viable; and with governance to understand the legal implications of applicable regulations.

People management

The aim of the people management process blade is to attract and retain great people who work on awesome teams.  People management goes by many names, including human resource (HR) management, human relations (HR) management, talent management, staff management, people operations, and work force management to name a few. This process blade addresses strategies for forming teams; helping people to manage their careers; training, coaching, and educating people; human resource planning within your organization; managing movement of people within your organization; reward structures; and governing people management efforts.

Transformation

The transformation process blade captures advice for how to redefine, and then reengineer, your organization.  This includes understand the current context, identifying the desired future, identifying how to measure the success of the transformation, identifying a likely strategy for moving towards the desired state, and then executing on that strategy.  Throughout a transformation you will constantly gauge your progress and the desired target state and adjust according.  This process blade leverages the advice of PMI's Brightline Initiative.

Vendor management

The aim of the vendor management process blade, sometimes called supplier management, is to help obtain and then manage offerings (products, services, and intellectual property) from other organizations. To do this your vendor management team will collaborate with other parts of the organization to help them understand their needs (if any), identify potential vendors that can fulfill those needs, work with legal to develop appropriate contracts, address vendor-related risks, help monitor and manage vendors, and eventually close out any contracts.