The Three Pillars of Executive Support for Agile Adoption

[article]
Summary:

As an executive sponsoring the adoption of agile methods, you've already spent dollars for training and coaching. You've talked to the management team and the rest of the organization about the need and rationale for using agile development methods.

But your job isn't over.

Communication and budgetary support are necessary, but not sufficient for your organization to realize the benefits of agile methods.

If you want the transition to succeed you must provide on-going support. The good news is, that doesn't mean you must keep handing over money. The bad news is that what's required of you is much harder than writing a check.

The Power of No
It's predictable that when there's a new method, process, or policy, people will request exceptions so they can continue to do things the old way. Well-intentioned people in your organization will come to you with a variety of reasons why their situation is different, and why they should be granted an exception.

It might be a production problem, or a feature someone promised to a customer who "simply can't wait" until the next iteration. It might be a request to pull people from a team mid-sprint to work on another initiative.

Demonstrate your support for the agile transition by answering these requests with a firm "No."

There are situations that call for quick action-a production error that's costing millions of dollars, for example. Scrum provides a mechanism to take care of situations like this, abnormal sprint termination. Stop the iteration, take care of the critical problem and then re-plan the iteration.

Don't break trust with a team by stuffing more work into the iteration. Don't de-motivate a team by expecting them to complete their original commitment, despite the extra work of the emergency. After all, managers redirected their efforts and (temporarily) prevented them from working on the agreed upon iteration goal. You've asked the team to commit to completing work; you must keep your commitment and refrain from adding work to the iteration.

Every exception you grant erodes the fundamentals of agile and the chance your effort to change your development method will succeed. Your firm commitment will help your organization stick with the new way–working at a sustainable pace, sticking to time boxes, managing scope one iteration at a time, delivering working software every iteration-until it becomes the new status quo.

Address Systemic Issues
Once you've said "No," ask some questions. Find out what's behind the exception request, and look for patterns. Three common patterns that I see driving exceptions are technical debt, overstuffing the pipe, and misaligned reward structures.

Technical debt is the harvest of cutting corners to meet unrealistic deadlines. Over time, if no one repairs the short cuts, the quality of the code degrades. Eventually, it's nearly impossible to change one section of code without breaking another. Technical debt is like any other debt-some times it makes sense to go into debt to take advantage of an opportunity. But if you don't pay back the loan, you're in trouble. Left alone, technical debt will choke the ability of your organization to deliver working software.

Organizations actually slow their ability to produce products when they try to do too much at once. Overstuffing the pipe leads to multitasking and context switching and delays the completion all projects. While it may look like people are busy, they aren't actually completing as much work as they could if they focused on one project at a time.

Misaligned rewards encourage one part of the organization to act in ways that are detrimental to reaching the overall organizational goals. A common example is disconnecting sales force rewards from the actual delivery of products. Another is rewarding delivering functionality on a certain date without regard to quality.

No methodology can fix these issues. These are management problems, and it takes management to fix them. Without management attention to systemic issues, you will achieve incremental improvements, at best. Worse, you will sow cynicism in the organization.

The Ability to Hear Unwelcome News
Along with the ability to say "No," you need to be able to hear "No."

As in,

"No, we don't have the capacity to do A amp; B at the same time."

"No, at our current velocity,

About the author

TechWell Contributor's picture TechWell Contributor

The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

May 04
May 04
May 04
Jun 01