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.

The value streams layer encompasses the capabilities required to provide value streams to your customers.  A value stream begins, ends, and hopefully continues with a customer. A value stream is the set of actions that take place to add value for customers from the initial request through realization of value by the customers.  The value streams 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 value streams layer.

Figure 1. The layers of the DA tool kit.

Figure 2 depicts the DA FLEX lifecycle, overviewing the high-level workflow for a value stream.  As you can see, a value stream begins with the initial concept, moves through various stages for one or more development teams, and on through final delivery into business operations.

Figure 2. The DA FLEX lifecycle for value streams.

Let's explore the components of Disciplined Agile's value stream layer.  The hexes in Figure 2 and Figure 3 represent process blades, sometimes called process areas. A process blade encompasses a cohesive collection of process options, such as practices and strategies, that should be chosen and then applied in a context sensitive manner.  Process blades also describe functional roles specific to that domain as well as extensions to the DA mindset specific to that domain. 

Figure 3. The process blades of Disciplined Agile's value stream layer.

You can see in Figure 3 that some process blades, such as Product Management and Program Management, are specific to this layer.  Other process blades, such as Strategy and Marketing, are shared between the value streams layer and the disciplined agile enterprise (DAE) layer. This is an indication that you may choose to implement those process blades at both the enterprise level as well as the level of a single value stream - do what is right for your situation.

Expanding upon the Disciplined DevOps layer, the value stream layer adds the following blades:

• Business operations
• Continuous improvement
• Governance
• Marketing
• Portfolio management
• Product management
• Program management
• Research & development
• Sales
• Strategy

Business operations

Business operations focuses on the activities required to provide services to customers and to support your products. The implementation of business operations will vary by value stream, in a bank retail account services is implemented in a very different manner than brokerage services for example. Business operations includes help desk and support services (integrated in with IT support where appropriate) as well as any technical sales support activities such as training, product installation, and product customization. As you can imagine close collaboration with both your Sales and Marketing efforts is required to successfully Delight Customers.

Continuous improvement

The continuous improvement process blade describes how people within your organization can share their improvement learnings with one another in a systematic way.  There are many strategies for doing so, including centers of excellence (CoEs), communities of practice (CoPs) which are also known as guilds, techniques for exploring existing ways of working (WoW), identifying new WoW, and sharing techniques.

Governance

Governance is the leadership, organizational structures, and strategies to enable you to sustain and extend your organization’s ability to produce meaningful value for your customers. Lean governance promotes strategies such as motivating people to do the right thing, enabling them to do so (often via automation), communicating organizational objectives, and preferring visibility over reporting.

Marketing

The goal of marketing is to ensure successful interactions between your organization and the outside world. Disciplined Agile marketing applies data and analytics to continuously source promising opportunities or solutions to problems in real time, deploying tests quickly, evaluating the results, and rapidly iterating. It also means taking a validated learning approach, being customer focused, working in a collaborative and flexible manner, and working in an evolutionary (iterative and incremental) manner. Your marketing efforts will represent your organization and your offerings, both products and services, to the outside world and conversely will represent external stakeholders, and potential stakeholders, to the rest of the organization. In conjunction with product management, Marketing will be actively involved with long-term visioning for your organization’s offerings. Marketing is sometimes called brand management

Portfolio management

Portfolio management addresses how an your organization goes about identifying, prioritizing, organizing, and governing their various endeavors. Disciplined Agile portfolio management seeks to do this in a lightweight and streamlined manner that maximizes the creation of business value in a long-term sustainable manner. Potential endeavors include solution delivery initiatives/projects, stable product development teams, business experiments (along the lines of a lean startup strategy), and the operation of existing solutions.

Product management

Product management is the art of taking strategic objectives and turning them into tactical activities.  Disciplined agile product management is performed in a collaborative and evolutionary manner that reflects the context of your organization. Disciplined agile product management includes the acts of:

• Identifying and prioritizing potential products/solutions to support your organization's vision;
• Identifying, prioritizing, and allocating features to products under development;
• Managing functional dependencies between products;
• Marketing those products to their potential customers;
• Exploring the needs of existing and potential customers;
• Identifying minimum business increments (MBIs) for delivery teams to work on.

Program management

A program is a large team composed of two or more sub-teams (also called squads). The purpose of program management is to coordinate the efforts of the sub-teams to ensure they work together effectively towards the common goals of the overall endeavor. Program management encompasses financial activities, vendor management, coordination of people/staffiing concerns, coordination of the evolution of the solution, and coordination of requirements management issues across the sub-teams within the program.

Research & development

Research & development (R&D) encompasses the innovative activities undertaken by your organization to identify potential new offerings (services or products), or to identify potential improvements to existing offerings. R&D constitutes the first stage of development of a potential new offering.  R&D activities are an important part of both product management and solution development to help explore potential ideas and strategies.

Sales

The aim of your sales efforts is to, you guessed it, sell your organization’s offerings (both products and services) to customers. Your sales people, if any, will work very closely with your marketing team to ensure they are focused on selling offerings that reflect your organizations’ overall strategy. They will also work closely with product management to ensure that what they’re selling is available or can be built in a timely manner. Organizationally Sales is often combined with marketing or may even be matrixed into business operations.

Strategy

Strategy is what you do now, and what you intend to do in the future.  The focus of the strategy process blade is to identify, evolve, and then drive the execution of your organization’s vision. Your vision is driven by the perceived needs of your customers and influenced by the environment in which you operate.

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.

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.

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.

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.

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.

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

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

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

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.