Successful Top Down Change Starts with Change at the Top

Most of the time, when I hear about “agile change,” someone in management has decided that Scrum (and maybe XP engineering practices) will improve quality and time to market for the company’s software products.

I’ve heard some success stories. And I’ve heard about many failures.

Why do these efforts fail?

Some people blame the failures on mis-understanding Scrum, or not applying it with sufficient rigor. Both of these may be true. But I see a different thread running through these failures. Often the failed change initiatives nibble at the edges, without changing the way work flows through the organization. And that’s a management problem.

What if the change–not just the directive to change–started at (or near) the top?

Here’s are six management practices that will improve the way work flows through the organization.

1. Get Middle Managers Working Together

Many organizations make it difficult for middle managers to work together by structuring goals that foster local optimization and competition. For example, a development manager might be rewarded for meeting a date, while test managers are rewarded for releasing a product with few bugs. It’s easy for the development manager to meet his goal if he doesn’t care about the test manager’s goal.

Other companies are organized so that managers for different products must vie for scarce development resources to meet their goals. The winner isn’t always the organization or its customers.

If you current organizational goals foster conflict or competition, fix them. They take the focus off the real goal, delivering valuable products to your customers. Optimize for the organization’s success, rather than focusing managers on goals that detract from the end result.

2. Decide What to Do and What Not to Do (At Least Not Now)

Ray Cummings said, “Time is what keeps everything from happening at once.” The laws of physics say it can’t happen all at once. So why do we keep trying to do everything at once in our companies? I’ve spoken with several development managers who have a personal policy of never saying no to a request from the business. That keeps the conversation happy for a while—until it becomes clear that it’s not possible for the development team to do everything.

One of the biggest problems in companies is trying to do too much at once. That drives multi-tasking, context switching, and wasted mental cycles. It slows down delivering value to customers and realizing revenue.

But if you want to focus, you need to …

3. Manage Your Product Portfolio

You probably know which products are valuable to your customers and the company. But do you know why? Go and find out. (For some ideas on learning how your customers view your products, see Know Thy Customer.)

Make a retirement plan for products that are waning in value to the customer or the company. Those products will suck up both intellectual and monetary resources.

For the products you will produce, determine which features need to be delivered and in what order. A Kano analysis can shed light on which features have to be there to make the sale, which enhance attractiveness, and which are clear differentiators.

4. Realize the Benefit of the Team Effect

Establish stable cross-functional teams to work on software products. Groups of people who are assigned to one project but report to different functional managers are less likely to jell as a team. When those same people are assigned to more than one project they are extremely unlikely to become a high performing team. Groups of people who have a clear membership and a clear charter jell into teams.

It takes time to build the communication, trust, and commitment that foster high performance. Many organizations rearrange teams every few months to meet the needs of current projects. That obviates the benefit of the team effect. Rather than bring the team to the project, bring the project to the team. A given team may need to add a new member for a particular skill–which is more effective than breaking down, re-staffing, and restarting whole teams.

5. Embrace Adaptive Planning

Don’t use deterministic planning for projects that aren’t deterministic. For most software projects, detailed plans only give the illusion of predictability. Further, they encourage managers to shift the blame for missed dates to the team.

Instead, use adaptive planning. Chart a course, knowing that the competitive landscape and internal factors (e.g., the capability of the team, viability of technologies) may drive the need to adapt and re-plan.

Find a way to measure progress that’s meaningful and reliable enough to let you extrapolate into the future. You won’t find perfect measures of progress or capacity–and if you could they’d probably be too expensive to implement. You need something good enough to make decisions about planning and promises. Gaging team capacity using story points, along with establishing a common definition of done are reasonable starting points.

Adaptive planning works better in the real world of software projects. But it does put responsibility for tough decisions squarely with management.

6. Continue to Improve

Once you have stable teams focused and working on the most valuable products, congratulate yourselves—you are ahead of many companies. But don’t stop. Create a culture of problem-solving leadership though out the company.

Examine policies, procedures, and structures that may have worked at one time, but don’t support the emerging pattern. Some of the first places to look are training policies, hiring practices, differential pay and rating practices, formal approvals, budgeting, and audit policies. Make sure your policies and procedures are working for you and not against you.


Some people say Agile could never work–it’s just the latest silver bullet. Agile may be reduced to silver bullet status, if managers expect to solve significant organizational problems by working only at the engineering team level.

But if mangers address the way work flows through the organization, it will make a real difference when development teams start to use Agile Methods. No software development method can solve problems of throughput, quality, or product fit unless management also changes.