|
 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 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 As in, "No, we don't have the capacity to do A & 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 Comments (6)
|
| Last Updated on Tuesday, 23 June 2009 18:01 |
Show/hide comment form
Agile Marketplace - Announcements and Special Offers
AgilePalooza - Serious Learning in a Fun Atmosphere
AgilePaloozas are community events sponsored by VersionOne and Agile Journal. These one day conferences provide serious learning in a fun atmosphere. Two tracks are included: Learning Agility and Advancing Agility. Speakers include internationally recognized agile coaches and trainers. The next seminar will be held August 27th in Dallas, TX – use discount code agilejournal and save $20!
Register Here
CollabNet Subversion Edge Improves Governance, Security, Administration
Quickly configure SVN, Apache, and ViewVC with one certified stack, fronted by a powerful UI.
Try our beta version and let us know what you think!
Virtual Conference: Agile ALM for Distributed Development
Learn how Agile technologies can create efficiencies for your business, hear from industry experts, and network with your peers. CollabNet and their technology business partners present two tracks of valuable information—business and technical. This environment will be available until July 20, 2010 at 3:30pm PDT, so please come back as often as you like to access the resources and presentations.
Register Today!
I also agree that it is inappropriate for the customer (product owner) to bypass the PM and move onto development. You not only open a can of future worms for yourself (dev), you also minimize the role of the PM and therefore the project.
Where I disagree is that development has or should have the ability to provide additional functionality to the customer without involvement of the PM. The PM or manager is ultimately responsible for the project. The PM may have other tasks which need to be inserted. Again this minimizes the project in the end because you have just increase the work load for test and so forth. A change that may take dev 10 minutes to make, may take your test team 8 hours to test.
In reference to the article, 'No' does not mean 'No' if a single part of the team is willing to bypass it.