The Three Pillars of Executive Support for Agile Adoption
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, we cannot see a way to complete all the features you want in the time frame you desire."
"No, adding another person to the team at this time will slow us down."
Let me tell you a story to illustrate what I mean.
I visited a company that was concerned about how their teams we doing after they'd adopted agile methods.
The teams estimated their work in story points, and posted charts showing how many points they completed in each iteration. After working in two-week time boxes for several months, it was pretty clear the team was able to complete between 10-15 points each iteration.
Their manager identified 600 points worth of features for a twelve week release.
The manager could see the teams' charts just as well as the developers could I bet he could do arithmetic, too. But when the team said, "No, we cannot complete 600 points worth of features in six iterations," their manager fell deaf. "But you have to try!" the manger exhorted the team.
The team was trying. This manager's response didn't motivate the team to try harder. They knew that the manager wish for 600 points in 12 weeks was just that-a wish and a hope, not a realistic goal. Teams will try to reach an ambitious goal when they believe there is a chance of success. It was clear to the team that, in this case, there was no chance. The manager's response made him look like a fool.
You don't want to appear foolish, so when the team and the data say "no," take management action. Have the difficult conversations and make the difficult choices to reduce scope or extend the date.
If you can do these three things--say "no," address systemic management issues, and hear "no"--your organization stands a good chance of succeeding with agile methods. Without all three your organization may experience limited success; but you will not achieve the results you hoped for.
About the Author
Esther Derby works on the individual, team, and organizational level to help companies improve their ability to deliver software. She's recognized as one of the leaders in the human-side of software development, including management, organizational change, collaboration, building teams, and retrospectives. Esther has been a programmer, systems manager, project manager, and internal consultant. She currently runs her own consulting firm, Esther Derby Associates, Inc. Esther is co-author of Behind Closed Doors: Secrets of Great Management and Agile Retrospectives: Making Good Teams Great, as well as over 100 articles. Esther has an MA in Organizational Leadership, and is a founder of the AYE Conference and a board member of the Agile Alliance. www.estherderby.com
