Manifesting Business Agility

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.

While it is important to understand that software development is not fully predictable I believe the approach many take with complexity is misguided.

If we can take actions in complex systems that predictably make things worse we can take actions that make them predictably better.

Theory of Constraints puts forward the concept of inherent simplicity-the presumption that inherent in complex systems are rules that, when understood, enormously simplify the system. These rules already exist. We must find them and take advantage of them. Doing so enables us to increase performance and reduce or eliminate the challenges we are facing.

I have been calling these natural laws, but now prefer ToC’s label because they may not be well-defined laws but noting them still enables us to see what to do. Some of these are:

• Small batches are better than large ones
• The system people are in greatly affects their behavior
• Delays in workflow and feedback create extra work to be done
• People's efficiency drops as the # of value streams they are in increases.
• You can’t manage what you can’t see
• Delays are caused when people do not collaborate
• Working beyond capacity creates waste
• Poor code quality creates unpredictability

Scrum proponents take pride in Scrum being a simple framework. This, of course, just means that Scrum provides a starting point and leaves the rest to the team to figure out.

Guidance such as "Shu Ha Ri" - copy, innovate, transcend is often given. But there are flaws in this thinking. Copying an existing approach in knowledge work is dangerous. No two teams in a company, let alone the world, are exactly alike. Systems-thinking (which includes culture) suggests that any starting point needs to attend to the team’s situation to both see where to start and how the team is required to adapt. Unfortunately, Scrum is not strong in systems-thinking.

We also need to remember that an understanding of principles is required to innovate. Much of Dark Scrum and Scrum But comes from not understanding principles of Flow and Lean. I don’t think I need to discuss transcendence.

There are several unasked questions here:

1. If teams can figure a what’s missing out why haven’t they already done so?
2. What concepts should be taught to all teams adopting Scrum?
3. What learning model should we use?

I’ll cover these in future posts.

We normally think about trust as a people issue, especially when delegation is involved. We can worry about a person’s motives - do they see the big picture? do they have the right skills? have they demonstrated they can be counted on? These are good questions. But they have the wrong focus. The real question is not “can we count on a person’s trustworthiness?” but “can we count on a person’s actions?”

Lean-management suggests that to be able to trust a person’s action we need to focus on what they need to make proper decisions. This includes:

1. information needed to properly make these decisions
2. any decision making rules that managers want them to follow (e.g., it is ok to spend $X now to create a savings of $Y per year)
3. the bigger picture view of what’s being worked on

Lean ignores the trustworthiness of the peoAbout this Blogple and focuses on creating a system that provides the above so that people can decide well. This is important because there is a fourth type of required knowledge – how to do the work itself, something typically the knowledge worker knows best.

After the decision, management needs to see the results. Visibility of workflow and results work both ways – they facilitate good decisions while providing validation as well.

“Trust in Allah and tie up your camel” – ancient Arab phrase

Delegation and self-organizing teams are at the heart of Agile. Trying to impose the same methods across an organization that people must follow is the anti-thesis of it.

Virtually all Agile methods talk about the first two while still imposing the third. At the heart of this is a lack of understanding of systems-thinking and trust.

One aspect of systems-thinking is that the system informs behavior. The combination of trusting our people and attending to the system is at the heart of Lean’s Middle-Up-Down Management. Middle-Up-Down Management has middle managers look up the value stream to get direction and then look down the value stream to see what’s needed to support the people doing the work. This includes creating visibility of intentions and results for all to see.

Achieving consistent behavior with self-organization is only possible when clear objectives are present. This enables teams to self-organize in the best way for them to meet these objectives and not be shackled to a particular way of doing things.

Please contact me if you want to learn how Disciplined Agile / FLEX can help you incorporate these ideas in your work