Or “Why does it feel like I am doing the same work as I’ve always done?”

When we kick-off a Train, we will often kick off the Teams for that Train a little in advance. The problem is not that the people on the Teams don't know where their work is coming from, but rather we need to set up the process so that the process of deciding to do work, the new intake system for the Team, also knows all sources of work and what the Team should typically work on. From the perspective of “what is it the Teams are and will be working on” there are a number of reasons for starting the Team before we get to a PI Planning event:

• Learn Agile: It allows the Team to learn new agile (ceremonies, artifacts, roles) approach by doing real work. And, increasingly, that work is in the context of a Program Train.
• Visualize Work: It allows the Teams to increase visibility of team work for both the Team members and the Program Team
• Manage Work-in-Progress (WIP): It begins the process of having the Team manage their WIP
• Manage Intake System: It begins process of managing intake system (new requirements) for both Team and Train
• Understand Team Capacity: It allows the Team and the Program Team to develop an understanding of Team’s capacity to take on work.
• Stop Starting and Start Finishing: It allows us to start clearing the process, making progress in finishing work so Team members can take on new, planned work.
• Refine Scope: It helps to develop the Team's understanding of their scope
• Initiate Planning: Its a beginning to the process of getting ahead of the planning curve.

There is a period between the Team Kick-off and the PI Planning event where we try to help the team work in the new way and begin to get their work under control.

In addition to the base principles, ceremonies, artifacts, and roles specified through Scrum, Kanban and other agile approaches, there are some driving “guiding principles” that drive how we want Teams to operate at this stage:

• “Bring your work with you”: Both organizations that are transforming and people doing the work often assume that, because they are on a team, that their work will change. The result is that some organizations try to work out all the new processes in advance of converting to the Team structure. For example, people will say things like “we have a security process so we need to work out how that will happen in the new Team structure.” If you decide to do this you end up trying to do a whole bunch of process re-design without the benefit of understanding how work will be done by the Team and will probably slow down your transformation and create confusion. A better approach is to set the expectation that the people working on the Team know the work and how it gets done, and leave it with the Team to determine how to implement process changes, if required. To do this well, you have to make sure that all Team members bring their work with them.
• “All work is visible on the team board”: In order for everyone to understand both current work, capacity, and changes in how work will be done, the first step is to make all work visible. This is in fact as basic thing that Teams should do as well, but is something that usually has to be stressed at this stage of the Team's formation. The basic principle could be restated as “if it is going to take capacity it will appear on the board” or “no hidden WIP”. Experience has shown that when Teams get started there is a reluctance to make all work visible resulting in the inevitable learning that “that should have been on the board” (trust me, this will happen) which delays real understand of what the Team is working on and the true capacity of the Team.
• “Work that is not the scope of this Team must have a new home”: When Teams for as part of an agile transformation there is an expectation that “everything will change”. This is re-enforced by the announcement of the expected scope of the Team. The problem is that from an organizational perspective the work still needs to get done. A couple of things might have happened:
  • Perhaps the people “designing” the Teams did not have a complete understanding of the work the Team needs to do. In this case, the scope of the Team is adjusted to reflect this work as well.
  • Perhaps the people that should be doing the work in the new organization are not aware of this work. In this case the work needs to be transferred to the new Team or person.
  • Perhaps we should not be doing the work at all as it is low or no value. In this case we should stop doing this (and future similar) work.
• “All work must go through the PO before Team works on it”. In the final analysis the only way to improve our work is to build up a complete picture of the work. Agile Teams address this by ensuring there is one source of work, the backlog, and one person for prioritizing that work, the Product Owner. But it only works if all the work is known to the Product Owner.
• “Immediately inform the Program”. Teams should raise program level issues immediately. This is to ensure that the Program Team is working the real issues the Team's are seeing.

The bottom line is that it will feel like “business as usual” until we get control of the work and start operating in the new way. These “guiding principles” help us to get things under control. And as you operate in the new ways some of these guiding principles will seem less important or will just become part of your standard operating procedure, and you’ll create and adopt other principles that will help you operate as a high performing Team.

What we are talking about here is how work requirements move through the system, starting with the intake process all the way to completion (“done”). There are two basic areas that Teams need to focus on:

1. Get control of the Team intake system
2. Get ready for the initial PI Planning event

Here are a couple of practices to consider as you work to get the Team’s intake system under control:

1. All Team work must go through the PO for prioritization. Many times work will come to the Team because someone knows someone else, or there is an old “work assignment” procedure in place, or the Team member just wants to do the work. To make sure we gain visibility etc., we have to channel all work through the Product Owner. This is not just something you do at the beginning of “being a Team” but rather something that is a standard practice. But the practice is a good and useful habit to get into right now.
2. Update the Team scope. This means that for new work items you need to compare this work item to the current definition of Team scope. If it is in the Team scope, then it’s just normal work and so we continue. If it isn’t, then we need discuss with Product Management team to see if Team scope needs to be adjusted. Again, if the Team scope is changed, then it continues with the Team. If it is not, then you need to determine how to transfer work to responsible party for this and future similar items. Responsibility for the work item remains with the Team until this transfer discussion has been completed. In this way we also ensure that work that used to be done by Team members does not get dropped when the Agile Team is formed - see How Do We Ensure Critical Work Does Not Get Dropped as We Kick Off Teams for more information.
3. Work to understand what items that are unplanned (real break-ins) versus something that can be planned. From a Team perspective the more work we can plan, the more we can control and the more effective we can become. For many IT organizations which are driven by ticketing systems it often looks like all work suddenly appears. But the reality is that often the tickets come from known work such as projects that the business want. In other cases, a ticketing system will specify a date to be done (and the date is often “immediately”) but from a business perspective we don’t really need it now and so we could schedule it at some time in the future. The Team should look at incoming work and try to figure out how to plan more work.
4. Establish a triage person. Often it is difficult for Teams to sit back from the barrage of inputs coming into the Team and, while we would like to get these in front of the PO for prioritization, perhaps the ticket really only will take a couple of minutes to do and there really is no benefit to creating a backlog item etc. Or perhaps there is some level of technical evaluation required to classify the item so the Product Owner can understand how to prioritize the work. Rather than have the whole team being driven by these interrupts, a common practice is to set up one person on the Team that functions this way. This allows the Team to focus their efforts. Another common practice is to make this a rotating position, so that one person doesn’t get burned out.
5. Work to understand Team capacity to take on work. In order to determine whether the Team can start an item it needs to understand what its capacity is to take on work. This means they need to understand the Team capacity - how much work can we do in a (say) 2-week period. For most Teams the measure is a Team's velocity. Once this is understood we can start understanding, for example, the percentage of capacity we need to allocate to items that cannot be planned.

Again, the idea is that the Team increasingly gets control of their work, and in particular their intake system, so that can structure that process to deliver value faster. As you get control of work you will typically find that more and more work can be planned which provides opportunities for Teams to improve delivery (see How Do We Deal With Constant Interruptions for more of this thinking). Pictorially this is represented as:

(Thanks to https://twitter.com/stevenesanchez for this picture)

In the context of this discussion, even though we kick-off Teams as standalone entities, the reality is that we are working to building a Train (multiple Teams working together to a common purpose). The seminal event that is driving this is the initial PI Planning event.

The Program Team is responsible for getting this set up. Part of that responsibility falls to the Product Management and System Architect Team who need to develop a backlog of Features ready for the Train to work on. It is expected that some of the work will be as a result of key strategic initiatives and are driven top down from the Trains (via a Portfolio?) to the Teams. But experience has also shown that early Planning events must really understand current work Teams have as well as ideas on how they can improve their work. This means that even before a PI Planning event there is significant collaboration between the Program Teams and the individual Teams. This is good practice for future Train planning and execution.

Many people think that there is a hierarchical view of how work gets executed when we set up a Train. They think that Epics for the Portfolio level will drive all the Program-level Features, and that they in turn will drive all the Team Stories. While we expect a significant amount of work to be driven that way, this approach would not leverage the ability of Teams (and Trains) to do what is right based on the knowledge from the coal face. In reality it is a matter of timing. Early in the life of a Train, a lot of Features will be “sourced” from the Teams (as will Portfolio-level Epics from the Trains). Over time we would see more work being driven top down.

This is the basis of the collaboration between the Trains and the Teams. For the Product Management Team to understand how much work they can plan for the Train, they need to understand how the capacity of the Teams is being used today. The Teams on their side want to be able to start investing in improving the quality of work, not just responding to the latest ticket. It is in the interest of both groups to collaborate on the understanding of current work, and how we shape the intake of work going forward.

What kinds of practices have we seen between across the Train to help prior to the initial PI Planning event?

• Common understanding of planning artifacts: This means that everyone the Train models Epics, Features, and Stories in the same way, with similar fields, similar rules for estimation, and so on. Base guidelines exist (e.g. Features are less than 3 months of work) but this is only a start to effectively managing the work. It is usually up to the Product Management Team to establish the “commonality”. In other words, this means that the Product Managers, the System Architects, and the Product Owners all collaborate on how this is best done, and then hold each accountable.
• Track types of work: Establish common ways of categorizing incoming work. At a minimum each team should track items that can be planned versus those that cannot so we can 1) generate the data needed for allocation of capacity at the PI Planning event 2) understand this work better so we improve how we deal with it. As with Teams, we’d like to look at how this demand is being created and work to shape the demand coming into the Train instead of just responding to the latest request.
• Capacity reality check: Teams should work with Product Management to help them understand current work in flight and the source of that work. There are a couple reasons for this. The first is that the Program Team needs to understand this so they do not indulge in wishful thinking. “We have a list of needs and all these people that can work on it” needs to be tempered against the capacity that is already allocated to inflight or upcoming committed work. Secondly we need to develop an overall Train work intake system. The Product Management is clearly part of this, but this discussion needs include what the Teams are seeing. Note that this it is often a surprise for people to see that the Team members are only able to spend, say, 30% of their efforts on what management would regard as “important”.
• Business Features: Teams should work with the Product Management Team to develop the Features for the initial PI Planning event. As said, we often see the initial list of Features that the Train work on come from the Teams, rather than being sourced at a high level. From a business perspective, with the agile transformation we are expecting to focus on highest value features, but this will take time to get to. For Features that are sourced from the Product Management Team, these need to be socialized and worked to a common level of understanding as part of the preparation for the PI Planning event.
• Enablement Features: Teams work with the System Architects on self-investment (“enablement”) Features. Part of the process we want to encourage is that we step back a little from the work, and figure out what we can change to build things better, faster, and cheaper. In the heat of work there is always the next urgent ticket, the next urgent deadline - the urgent always overcomes the important. The problem is that in responding to these pressures we don’t get better. A lot of agile is about helping people find the time to focus on improvement. In this way the “important” can be worked and not just be lost to the “urgent”. Most Teams already know what they’d do if given a little time, so the Trains needs to start building this list so it it can be an input to the PI Planning event.
• Train Capacity: Program Team needs to understand the capacity of the Train to do work. As we get into the PI Planning event we need to understand what each Team is capable of working, how much is needed to address unplanned items and how much can we not plan for because it is already inflight and needs to be finished off before we take on new work. The Teams provide their velocities and the collaboration will the whole Train to develop a common understanding. Using this information, before we get to the PI Planning event, the Program Teams should create a shortlist of items that could make it into the plan for this Program Increment. In essence they do this by having a prioritized list of sized Features and, using the velocity information, draw a cut-line when there is insufficient capacity to take on more work.

You are still early days as a Team, but that does not mean that you have not started to understand what is possible. You can expect to bring this understanding into a PI Planning event:

1. Velocity and Iteration Predictability. As teams go through the several short iterations before their first PI, they get enough of a velocity as a starting point. In addition, tracking estimated over actuals would show how often teams finished what they committed to at start of sprint. These metrics can show how much work a team should accept during PI planning.
2. Capacity Percentages. Capacity can be allocated to match the team needs for both planned and unplanned work to prevent being overcommitted.
3. Features for a quarter. After the Program and Teams prioritize all the Train features, Teams will bring what they think they can complete in a quarter given an understanding of their capacity and velocity.

While this discussion is written from the perspective of a Team operating in a Team-of-Teams (SAFe Program) context, in reality the thinking applies to just about all Teams as they kick-off. Lets face it, when we kick off a Team, most people on the Team have work that doesn't just simply go away so working Team scope and work intake system is something that should be done. And while the Team might not be operating in a Program, the considerations (improvement, understanding capacity, common modeling of artifacts, etc) are useful in any situation where there is more one Team operating.

Related information:

• How Do We Deal With Constant Interruptions
• How Do We Ensure Critical Work Does Not Get Dropped as We Kick Off Teams
• Why Should We Work Harder to Eliminate the Effect of Dependencies?

Thanks to Steve Sanchez for his help with these materials.