Starting a Transition to Business Agility in Seven Steps

< How Using MBIs Tie Strategies, the intake process, ATDD, and planning together       ToC    Setting up a Transition Monitoring Team >

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. 

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 300 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 seven steps can get you immediate improvement. These steps are:

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

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.

Have a visible intake process where all work can be seen. Some 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. We create a team based on partial availability of many people. Little collaboration is possible when this happens. 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.

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.

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.

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.

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.