In a process tailoring workshop a coach or team lead walks the team through important aspects of the Disciplined Agile (DA) process and the team discusses how they’re going to work together. This typically includes choosing a lifecycle, walking through the process goals one at a time and addressing the decision points of each one, and discussing roles and responsibilities.
In this article we work through the following topics:
- Why Process Tailoring?
- When do you Run Process Tailoring Workshops?
- The Risks Associated with Process Tailoring Workshops
- Planning a Process Tailoring Workshop
- What Should you Tailor?
- Running a Process Tailoring Workshop
- Documenting the Results
Why Do You Want to Tailor Your Team Process?
There are several reasons why you want to tailor your team’s process:
- Every team is unique and faces a unique situation. One of the agile tenets is that teams should own their own process so that they can work together effectively. One process size, a common prescribed process, doesn’t fit all situations because teams are unique. In short, repeatable results (such as regularly providing valuable functionality, doing so in a timely manner, and producing quality results) are far more important than following common “repeatable processes.”
- You want to have a common vision as to how you’re going to work together. For teams to work together effectively they need to agree on how they’re going to do so. Without a common vision you’ll flounder.
- You want to streamline how you work together. Teams should do their best to identify how to make their work as efficient as possible, to reduce work in progress (WIP) to a sustainable pace, and to eliminate waste wherever they can.
- You may need to document your process. Sometimes a team is required to document their process, perhaps because of legal regulatory requirements or to help other teams understand how they’re working. Our recommendation is to apply agile documentation strategies so as to keep your documentation as lightweight and sufficient as possible.
When Do You Run Process Tailoring Workshops?
A process tailoring workshop is typically done early in Inception to determine how the team will streamline their initiation efforts, and just before Construction to settle on how that phase will work. Process tailoring for Transition is typically reflected in your transition/deployment planning efforts that occur throughout Construction.
Any process decisions made in process tailoring workshops are not carved in stone but instead evolve over time as the team learns. You always want to be learning and improving your process as you go, and in fact most agile teams will regularly reflect on how to do so via holding retrospectives. In short, the purpose of process tailoring workshops is to get your team going in the right direction, whereas the purpose of retrospectives are to identify potential adjustments to that process.
The Risks Associated with Process Tailoring Workshops
Before we get into the details of how this practice works, we wanted to share a few concerns that we have with it:
- It takes time. No matter how lightweight you keep things, it still requires an investment of time from the team. This is time that could be spent in the short-term on producing new value for your stakeholders. The hope is that you will help the team work more effectively by having agreement around their process.
- It can easily get out of hand. We’ve been leery about this type of thing for a long time because we saw many Rational Unified Process (RUP) teams struggle with this in years past and certainly saw CMMI-compliant teams get into serious trouble with process tailoring. It is far too easy for people to spend too much time, to write too much process documentation, and then to not evolve the process over time.
- One or more people need to be experienced. It’s easy to advise teams that they should “own their own process.” However, if they don’t know what trade-offs they’re making or worse yet they don’t know what their options are (in effect they don’t know what’s for sale) then that’s hard to do in practice.
The good news is that with effective facilitation you can keep process tailoring workshops streamlined.
Planning a Process Tailoring Workshop
Here’s how to organize the workshop:
- Schedule several short sessions. We wish we could say that you could get this done in an hour or an hour-and-a-half, but that would be a lie. During Inception we typically schedule three 90-minute sessions with the hope that we don’t need all three. The length of time needed is driven by the amount of discussion – smaller, experienced teams will very likely get this done quickly but the larger the team or the wider the range of experience on the team the longer it will take.
- Have a clear agenda. Let people know what you intend to do and why you’re doing it. This sets expectations and forces you to be prepared.
- Invite the entire team. The team should own its own process, therefore everyone on the team should be involved with determining what that process is.
- Have an experienced facilitator. The person running the workshop should be experienced with the DA toolkit and better yet have run a process tailoring session in the past.
- Arrange a flexible work space. We prefer large rooms, ideally an agile modeling room or the actual workspace of the team, where we can tack things to the wall. As you can see in Figure 1 below we like to put the goal diagrams on the wall. In the picture you see that we have the goals for Construction and Transition on the wall, and then mark them up with the choices the team has made as we work through them. We also like to be able to project the goal diagrams on the wall, or a screen, one at a time so that people case read them.
Figure 1. Example of printed goal diagrams for Construction and Transition
What Should You Tailor?
Here is a list of the issues you may want to consider covering in your process tailoring workshop(s):
- What are your rights and responsibilities? The agile culture and way of working can be very different from the traditional way. We’ve found that it can be very valuable to explore what rights people on agile teams have as well as the corresponding responsibilities that support them.
- How do you intend to organize yourselves? Early in Inception you need to form the initial team and form your work environment, see Figure 2 and Figure 3 below for the respective goal diagrams. If you are holding a process tailoring session before you’ve settled on how you’ll be organized you are likely to find that your team members want to work through basic issues such as where people will be located, what your working hours are, what your workspace looks like, and so on.
- What lifecycle will the team follow? Because every team faces a unique situation, the DA toolkit supports six lifecycles: The Basic/Agile lifecycle based on Scrum; The Lean/Advanced lifecycle based on Kanban, the Continuous Delivery:Agile lifecycle, the Continuous Delivery: Lean lifecycle, the Program lifecycle for teams of teams, and the Exploratory lifecycle based on Lean Startup. Each lifecycle is appropriate for different situations and your team should choose accordingly.
- What practices/strategies will you follow? The easiest way to do this is to work through the Disciplined Agile Delivery (DAD) process goal diagrams one at a time. It’s important to do this at the appropriate point in the lifecycle – initially tailor Inception goals early in Inception and Construction goals just before Construction begins. A just-in-time (JIT) strategy is usually the way to go.
- What is your Definition of Ready (DoR)? For teams following an iteration/sprint-based approach you’ll want to talk through what your team requires for a work item to be sufficiently described so that the team can begin working on it. For teams following a lean or continuous delivery lifecycle typically the first work step is to perform sufficient analysis and design before implementing the item. The work to “get it ready” still occurs albeit the timing of when it occurs will change depending on the lifecycle.
- What is your Definition of Done (DoD)? Similarly, teams following an iteration/sprint-based approach will want to agree to a DoD against which work will be evaluated to determine whether it is sufficient.
- What tools will you use? Similar to the issue of organizing yourself, if the team hasn’t yet decided on all of the tools that it will use you often find that people will bring up tooling issues during process tailoring sessions. Usually you’ll identify that you’ll apply a practice such as continuous integration (CI) and someone will ask what tool(s) you’ll be using to do so.
Figure 2. The Form Initial Team process goal diagram (click to enlarge)
Figure 3. The Evolve WoW process goal diagram (click to enlarge)
Running a Process Tailoring Workshop
Here is a typical approach to running a workshop:
- Confirm the scope of the discussion. This information should have been in the agenda, but it’s always good to start by confirming what you hope to achieve.
- Share any existing material you may have. For example, if you’re going to work through process goals then bring along printed copies of the goal diagrams or at least have a laptop from which to view them online. If you’re going to work through roles and responsibilities, you might want to share the existing ones that we’ve published (or your versions of them if appropriate). This information should have also been made available before the working session – the better prepared people are, the better the workshop will be.
- Tailor the process. As a team, work through the process issues you’ve decided to focus on in the workshop. This should be a facilitated discussion as opposed to a process expert inflicting their views on the team. Sometimes the team will choose to adopt less than optimal strategies, and that’s ok – they can always adjust later on after they’ve learned what works for them.
- Capture your choices. Ideally, particularly with a small team, we prefer to have people stand around the printed goal diagrams (or other printed things) on the wall and discuss and mark them up accordingly. With larger teams you will often have one person marking up the diagrams, typically the facilitator, while the team discusses their choices. In this situation we often find it useful to project whatever is being discussed on a screen so that people can see it.
Documenting the Results
Nobody likes to read process material, so keep it as light-weight as you possibly can. Follow common agile documentation practices such as keeping it concise and working closely with the audience (in this case the team itself) to ensure it meets their actual needs. Here are some light-weight options for capturing your tailored process:
- Use a simple spreadsheet to capture the goal diagram choices. We often create a spreadsheet with the following columns: Phase, Process Goal, Decision Point, Choice(s), and Notes (you can download an Excel spreadsheet here). Another, more sophisticated option, is to use a commercial product such as Blueprint to tailor your process (and publish it too).
- Create an A3 overview of the process. A common lean strategy is for a team to capture their process on a single A3 (8.5”x11”) sheet of paper and post it on the way where everyone can see it. We typically capture a description of a typical day (indicating common working hours, when the coordination meeting is, and so on); an overview of a typical Construction iteration (indicating when common meetings and working sessions are scheduled throughout an iteration); and a graphical depiction of the lifecycle the team has chosen to follow (this is often very high level). This overview is typically put on the wall where the team can see it.
- Put up posters. When a team is co-located, in addition to the process overview, we like to put up key concepts such as the DoD, DoR, and roles and responsibilities. Some of these things we’ve made available from the Posters page at the Disciplined Agile Consortium site.
- Team process wiki. In addition to the printed copies on the way, we like to capture these things on the team wiki (if there is one). Once again, follow agile documentation practices for this.