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.
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 Disciplined Agile (DA) tool kit is organized into four layers: Foundation, Disciplined DevOps, Value Streams, Disciplined Agile Enterprise (DAE). This blog focuses on the Foundation layer, the purpose of which is to provide the underpinnings of the DA tool kit. The foundation layer itself is organized into four distinct topics:
The DA Mindset
The Disciplined Agile (DA) mindset is captured in the form of principles, promises, and guidelines. Disciplined agilists believe in the DA principles, so we promise to adopt these behaviours and follow these guidelines when doing so. There is a purpose for each aspect of the mindset:
Disciplined Agile (DA) is a hybrid in that it adopts ideas and strategies from a wide range of sources. DA encompasses three categories of fundamental concepts:
The people portion of the Foundation layer addresses two key aspects of agility:
Choosing Your WoW
A fundamental philosophy of agile is that teams should own their own process, or as we like to say in Disciplined Agile (DA) teams should choose their way of working (WoW). Of course this is easier said than done in practice. The challenge is that every team is unique and faces a unique situation – in other words, context counts. Furthermore, there are no “best practices,” rather, every practice has tradeoffs and works well in some situations and poorly in others. Worse yet, you really don’t know how well a technique will work for you until you actually try it out in your environment. Given all of this, how can a team choose its WoW?
While working with organizations to help them to learn how to improve their WoW, we’ve developed a technique that we call guided continuous improvement (GCI). GCI extends the kaizen-based continuous improvement approach, where teams improve their WoW via small incremental changes, to use proven guidance to help teams identify techniques that are more likely to work in their context. This increases the percentage of successful experiments and thereby increases your overall rate of process improvement.
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:
In the article we go into the details of the technique, exploring:
We hope you find the article to be a game changer for your agile adoption efforts.
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).
As you’d expect, you have choices available to you. In Figure 1 there are three decision points relevant to terraforming:
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.
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:
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.
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.