Starting a Transition to Business Agility in Seven Steps

Agile transformations take time. Many companies decide to start one and then take months to get going. While a complete transformation does take time to manifest, there is a way to get started quickly. This not only creates quick improvement but also sets the stage for the full transformation later. 

The different Lean-Agile approaches for improvement go to two different extremes. The Scrum and Scrum-based approaches (SAFe, Scrum@Scale, ...) suggest mostly preset starting points that often require abrupt change. The Kanban Method goes to the other extreme of starting exactly where you are. There is a middle ground - doing an assessment and seeing a good place to start. However, if you are working on your own that may be difficult. Nevertheless, there exist a few adjustments to workflows that can be a good first step for virtually all companies that can be done up front with little guidance.

Effective flow involves:

• what goes into the development group to be built
• visibility of the work being done
• the structure of the teams doing the work
• how the teams work together
• Dev Ops
• Management

While accomplishing these can take a long time to set up, a little bit of each of these can be accomplished quickly. The effect can be significant. If you are an organization with a development group of less than 500 people here are steps for each of these you can quickly take to get going to significant improvement.

While additional steps will be needed to continue your journey, these steps can get you immediate improvement:

1. Use Minimum Business Increments (MBIs) to identify enhancements you are building
2. Agree on service classes and service level agreements
3. Have a visible intake process where all work can be seen
4. Organize into dedicated product teams.
5. Agree on how the dedicated product teams will work with each other and the rest of the organization
6. Do Dev Ops Phase 1
7. Management attending to the environment people are working in

Using Minimum Business Increments. The focus in business agility is delivering value quickly. This requires increments that are large enough to be valuable to the client but also be as small as possible so they can be released quickly. If you are not clear about the difference between an MVP and an MBI I suggest reading about the (MBIs).

Minimum Step: While using MBIs is ideal, just considering smaller items to release will get you significant value. Product managers/owners should ask themselves the question - "is there any part of this that I can have customers realize value quicker?"

Agree on Service Classes and Service Level Agreements.  Even the smallest organization has different types of work. Typical ones include:

• enhancements
• new products
• maintenance issues
• severity one issues
• bug fixes
• time dependent work

It is important to have agreements on how items from each of these service classes is to be worked on. Without these agreements it will be difficult for development teams to manage both what and how much they are working on. The common scenario is everyone asks them to do everything. This is untenable and makes it difficult to get out of a project mentality.

Minimum step: Have 3 - new functionality, severity one issues, maintenance.

Have a visible intake process where all work can be seen. Most companies are project focused. That is, projects are started from many sources. A person gets budget and then finds some people who may have time to help get it done. They create a team based on the partial availability of many people. When this happens little collaboration is possible. Sometimes projects start and no one but the people who started it know of it. So when one team is finished and needs to get help from another the other team is often surprised. This causes interruptions and chaos.

Having a visible intake process so everyone can see what’s coming to the teams and what’s in play can make a big difference. Even if nothing else changes. See The Importance of Having an Intake Process for more.

Minimum step: Even if you don't change your process, make all the work visible. If you don't have a tool to do this use Excel or Google Sheets. You only need to list those items that are actually being worked on. Sub-items don't need to be listed. The intent is to just know what's going on the in organization. If you have a group that does primarily maintenance they can keep a separate list.

Organize around dedicated product teams. These are teams that can develop the MBIs defined. You can then create Scrum-Kanban teams (8-12 people) if the product teams are too big. While cross-functional teams of less than 12 are ideal, they often can’t be formed. Sometimes you’d like a bigger team in order to develop the MBI faster.

The size of this team is dependent upon having sufficient skills and experience. Sometimes a dedicated Product Team will be larger than it has to be to get the MBIs done more quickly. The idea is to have some stability in the team as well so that future MBIs related to the product or service can be done by this semi-stable team. A “Feature Team” is a team with all the skills required to create a feature. Remember, features often have value and can be demonstrated to a customer but aren’t sufficient in value to be released and have value realized.

The structure of a dedicated product team is shown in the following figure.

“Core Teams” are teams that have almost sufficient skills to build features. They will need to use those individuals shown at the bottom of the picture.

Minimum step: Try to have people on as few projects as possible. Best to dedicate them to a product. When calculating the utilization of a person add 20% for each project they are assigned to after the first. For example, a person working 30% of their time on 2 projects has 60% of their time allocated plus another 20% for having a second project (20% added each) for a total of 80% allocated.

Agree on how these teams work together and with the rest of the organization. Each dedicated product team, and any sub-teams should work together on a regular cadence. A two-week cadence is often best. But regardless of the number of weeks, all should work at the same cadence. This makes it easier to coordinate product management input, any cross-integration that may be required and released to ops.

Minimum step: Have teams work on a common cadence. This adds a lot of other value with no additional effort. Expect some teams to complain saying they work better on longer sprints/iterations. The intent, however, is to improve overall effectiveness. Working with a common cadence with increase collaboration.

Do DevOps Phase 1. DevOps phase 1 means that all work being done by Dev and Ops is visible to both. This enables Ops to see what’s headed their way. It also means Dev can understand any delays they will have getting Ops to help them. This is straightforward and readily doable, but is often not done in many organizations.

Minimum step: Include Ops in any planning sessions so they can know what's coming there way.

Understand management’s role is to manage the eco-system within which people work. Our systems greatly influence the behavior we get. When we get bad behavior from our people we should recognize that this is more due to the system than the people themselves. Our focus should be on improving the systems within which our people work. All of the above steps do this:

• MBIs give people smaller things to work on which makes it easier to finish them
• Visibility helps people see what’s coming
• Dedicated product teams means that people can collaborate with people who are readily available to them – this cuts our delays and handoffs significantly
• By having dedicated teams work on a common cadence, teams can coordinate both with each other and other roles that need to work with them
• Dev Ops Phase 1 avoids Ops from being blindsided and causing last minute delays

Learn more at Leadership and Management.

Minimum step: Becoming a Lean manager is not an easy thing to do for someone who is used to telling people what to do. But good managers already do a lot of the right things here. They should put more and more energy into stepping back and seeing what would both help their charges make better decisions as well as how they could see themselves the quality of these decisions without micro-managing.

A middle ground is best

Large adoptions typically take one of two approaches:

1. just jump in with a lot of training
2. take the attitude of having to get it just right

The first has people do a lot of training where most of the knowledge gained is lost within a week or two. It can also be very disruptive. The second takes a long time to get started. A good approach is often to get people aligned on a plan of small steps. An experienced person (internal or outside consultant) can greatly speed things up. But getting started in small steps is a good way to go.

The Bottom Line

A quick assessment and initial training to get some overall view of the picture to be done is highly recommended. But a massive start or a massive plan before starting is not recommended. It is ideal to roll out change with a cohesive plan that unfolds as you go. But if you can't get started quickly, just taking small steps based on actions that are known to be good is virtually always beneficial. Small steps makes it easy for people to adopt them while teaching people the value of continuous improvement.