Agile Coach: Where to Begin

It is easy for a team to transition to agile/lean software development: Pick a good pilot project, get some training, re-arrange the workspace, learn the process, and maybe use a coach. It has been done thousands of times. It is easy, but all too often there is no benefit for the organization. The goal is not making teams agile but making the organization agile. This is harder. It involves building a transition plan around the organization so that everyone—customers, organization, and teams—will succeed.

A successful transition plan focuses on the complete set of work that is required to turn an idea into a product that customers can use. It will minimize the time and effort required. This requires looking at opportunities in an organization, management, team agility, and technical practices that will have the greatest impact on removing impediments and improving the flow of work.

Where to Start? Where Do You Want to Go?

The starting point for most journeys is having an idea of where you are going. As obvious as it sounds, many organizations are not clear about this. They know they want to “become more agile” but are not sure what that means. And much of the literature on agile does not help, focusing only on development teams. It seems natural to start introducing agile at the team level, but that is not the goal, not the destination; it is merely a way station on the journey of making the whole organization more agile.

Organization agility focuses on enabling a an organization to respond quickly to competitors, to internal insights, to changes in industry or technology, and so on. All efforts should lead to becoming more and more agile as an organization.

With organization agility as the goal, we can have meaningful measures. For example, the elapsed time between when an idea is first developed until it is implemented, delivered, and customers can begin to use it. We call this the “cycle time.” The shorter the cycle time, the better. Short cycle times let the organization penetrate the market faster and respond to competitive pressures more effectively. The value of this metric is that it focuses on the entire “value stream” for the product.

A value stream is the whole set of work that is done to create a product, from idea to delivery of value. Ideas arise from interactions with customers who could be external or, in the case of IT, internal to the organization. Organization stakeholders and product managers create a list of product enhancements to be built by the development organization and delivered back to the customers (either external or internal for IT organizations).

Product development is just one part of the value stream. If you improve product development but some other step still takes too long or is blocked, then cycle time may remain the same. Reducing cycle time requires optimizing the whole value stream which is a key focus of lean: lean suggests that removing impediments to work (delays which cause waste) improves speed to market while at the same time raising quality and lowering cost.

Impediments to Organization Agility

There are at least four general categories of impediments to organization agility.

Unrefined enhancement requests. The organization side does not properly select, size, or prioritize their desired product enhancements. Yearly planning forces stakeholders to ask for too many product enhancements, which tend to be too large. Faced with long delivery cycles, they pile on requirements just to be sure they get what they anticipate they will need. Trying to accommodate all these requirements results in working on too many projects at one time. Too large, and too many, organization requirements make it difficult to prioritize. This means that some of the features the team is working on may not be the most valuable to the organization yet, and because they were already started, they have to be finished before the team can take on the next, more valuable feature.

Unrefined enhancement requests also result in delays because developers must go back to the customer to ask for more explanation and must wait while requirements are developed. We would say the feature was not yet “ready” to be worked on. Waiting equals delay.

Improper allocation of resources. To manage this crushing workload, teams are often isolated into “silos.” Unfortunately, this dilutes the efficiency of the organization even more. Developers end up waiting for others to start work or to share information. In an attempt to remain productive, more projects are started. But this just adds to their overwhelm, reducing efficiency and causing even more delay.

Lack of team availability. Team agility holds the promise of shorter development times: take a statement of need and build a system or feature to meet it and then deliver it quickly. Unfortunately, teams may not be available or are difficult to form. Just creating new trams without solving the cause of too many projects may the rest of the organization becoming even more overwhelmed than before.

Poor technical practices. Too often, code becomes complex and brittle and hard to maintain over time. With discipline, it doesn’t have to. The proper use of acceptance test-driven development (ATDD), (unit) test-driven development (TDD), design patterns, and refactoring can keep code robust over time. While these techniques have been around for a long time, they are still not in widespread use. Many organizations suffer from technical debt in their existing code.

Start Where the Problem Is

If you want to make a car go faster, where would you start? Maybe you would put in a bigger engine. But what if the problem is in the transmission? Or the parking brake is locked? Or your tires are completely worn through? Of course, you should start where the problem is. The transition to agile/lean is no different.

Starting with development teams is like starting with the bigger engine. If impediments lie elsewhere, then even if the individual team gets better, overall agility might become less! Even worse, if an agile pilot project ends up causing headaches for the organization, people will turn against the agile initiative.

It is much better to start where the problems are. Here are some ideas that can help address these impediments.

Start Where You Can

The good news is that the transition does not require great organizational changes before seeing improvement. You can start where you are. Here are two effective and relatively painless approaches that can be used.

• Limit work-in-process. Limiting the amount of work-in-process (WIP) in those places where people or teams are clearly working on too many things in parallel. This naturally frees up the parts of the value stream that get clogged up and overwhelmed with work and, therefore, create delays. It will have a ripple effect to unblock the flow of development. This will not seem natural at first, but it does work.
• Make product managers your allies. If your company works on many large projects at the same time, you can enroll product managers into modifying the way they manage the portfolio of products. Not only will this focus the organization on building the right products, but it will also lower the amount of work that is almost certainly overwhelming development teams.

You have many more options available to you today than we had in the past for deciding where to start the transition to agile/lean. Increasingly, there are organization leaders and management who recognize the need to become an agile organization. They may have been trained in lean thinking; they may have been exposed to the Toyota Production System and the Toyota Product Development System. They are more likely to see the need to develop strategic plans for the transition to lean-agile software product development. Involving leadership to create a top-down vision with a bottom-up implementation is always better. Developing this top-down/bottom-up approach requires careful, strategic thought. Consider using a coach who is experienced in working with senior leadership. Such a coach can bring to bear the experience of others to create a strategic plan that is likely to succeed and will have the proper organization justification.

Summary

In your transition to agile/lean software development, it is critical to keep focused on the goal: organization agility. Creating more agile teams is good but only as long it helps the entire value stream deliver product to customers more quickly and sustainably. Work on those changes that will produce the greatest results overall. This involves looking at all four of these critical areas:

• Organization
• Management
• Team agility
• Technical skills 

29.03.23

• Overview

• Approach
• Activities
• Coaching Tips
• Competencies
• Mindsets
• Trim tabs
• Systems thinking and transitions

• Asking powerful questions 
• Attitudes, attributes, and service
• Facilitation tips

• Approaching agile, approaching scrum 
• Common challenges for new teams
• Successful pilots can hurt going agile
• Where to begin

• Considerations for DAD teams
• Considerations for daily coordination 

• Components of a good team board
• Daily coordination
• Designing the kanban board
• Estimation / Team estimation
• Facilitating remote teams
• Iteration planning meeting (Facilitation)
• Iteration retrospective (Facilitation)
• Manage work-in-process
• Visual controls

• Goldratt’s Rules of Flow by Efrat Goldratt-Ashlag. 2023