Tuesday, 07 June 2011 10:44

Preventing a Trip Over the Waterfall When Introducing Agile Methods

Written by 
Rate this item
(0 votes)

BATimes_Feature_June7While I have reviewed some practices to consider when changing methodologies from traditional waterfall approaches to agile ones in Avoiding Speed Bumps when Adopting Agile Practices the input from a participant at one of the roundtable discussions at this year's ProjectWorld Toronto inspired a few more.

The attendee indicated that his organization had embraced agile methods on a specific technology project but the issues and cost overruns they experienced stymied further attempts to adopt agile practices. 

Further discussion of the specifics of this case study yielded some more lessons.

  1. Start simple and expand complexity progressively (also known as "success begets success") - in most organizations where agile methods have "stuck". A pilot was done using a small (though highly visible) project that satisfied the 3 C's of agile - collocation, collaboration & (open) communication.
  2. Leverage coaching assistance - It is very hard to manage your first agile project while simultaneously coaching the overall project organization (customer, stakeholders & team) through this process and philosophy change. If you happen to be the sole agile evangelist within your company, it may be worth justifying the costs of an outside coach to focus on the change aspects.
  3. Trust is mandatory - As with any other strategic change, commitment to the change means more than just focusing on the expected benefits while giving lip service to the costs. As I previously wrote in Trust - a critical success factor for successful agile projects, a lack of trust between key roles on agile projects can sometimes result in worse outcomes than on traditionally managed ones.
  4. Identify "appropriate usage" criteria for agile methods - Not all projects lend themselves to the use of agile approaches (just as not all projects can be successfully managed using waterfall approaches). Developing checklists or similar tools to help project managers decide whether a purely agile, a purely waterfall or a hybrid approach is best suited to their specific projects will help to reduce "square peg in round hole" situations.
  5. Don't get hung up on specific methodologies - unless the nature of your projects exactly fits a particular agile methodology, it is better to focus on adopting (and adapting) principles rather than to blindly follow an off-the-shelf set of implementation practices. Fanaticism towards any specific agile "religion" is hardly likely to reward you with converts.

Through committed executive sponsorship, appropriate staffing and a "walk before you run" implementation approach, you can reduce the likelihood that an agile initiative will go over the waterfall!

Don't forget to leave your comments below.


Kiron D. Bondale, PMP is the Manager, Client Services for Solution Q Inc. (http://www.solutionq.com/) which produces and implements Eclipse Project Portfolio Management software and professional services. Kiron has worked for over twelve years in the project management domain with a focus on technology and change management. He has setup and managed Project Management Offices (PMO) and has provided PPM consulting services to clients across multiple industries. Kiron served as a volunteer director on the Board of the Lakeshore Chapter of the Project Management Institute (PMI) for six years and remains an active member of PMI. Kiron has published articles on PPM and project management in multiple industry journals and has delivered presentations within the PPM/PM domain at multiple conferences and through regular webinars for Solution Q and the PMI Healthcare SIG.

For more of Kiron's views on change management, please visit his blog at http://kbondale.wordpress.com/ or contact him directly at This email address is being protected from spambots. You need JavaScript enabled to view it. .

 

Read 4254 times Last modified on Tuesday, 03 April 2012 14:01

Comments  

 
0 # Dan Clausing 2011-06-07 07:31
Great article. A straight forward take on how to begin considering and delivering agile. I think it is essential for any Agile success to have executive commitment from the top down to be able to ride through the bumps and hiccups of the transition. Even an outside coach or experienced PM cannot be successful with Agile if traditional measures aren't modified for the new approach and environment - maybe we should add an F (flexibility) to the 3 C's. Thanks for sharing!
Reply | Reply with quote | Quote
 
 
0 # Josh 2011-06-07 07:32
Very helpful article, thanks for taking the time to write it.
Reply | Reply with quote | Quote
 
 
0 # laurie 2011-06-09 01:05
In point 4 you mention a check list. Could you either share yours or tell us where to look to create our own? Thanks
Reply | Reply with quote | Quote
 
 
0 # Kiron 2011-06-09 06:02
Laurie - the check list approach was mentioned at the round table so unfortunately I personally don't have such a tool. However, some items in it could include: 1. If a project includes vendor participation, if the vendors have no exposure to agile methods that might suggest waterfall is appropriate as far as their deliverables. 2. How "close" (communication steps-wise) is the product customer/owner from the delivery team? Closer proximity lends itself to agile while long distance proximity (without effective local proxies) might suggest waterfall. 3. What degree of trust exists between the key players - if there are historically low levels of trust, then waterfall with strict gates or sign-offs might be needed. Kiron
Reply | Reply with quote | Quote
 
 
0 # Ellen Gottesdiener 2011-06-10 06:27
Nice set of of suggestions, thanks for your article. i put together a list of 8 suggestions a few years ago (you can find them at http://ebgconsulting.com/newsarchive.php?pid=agile-business-analysis-sept09#transition). This short article, in addition to a few of your point, Kiron, add some tactical actions that we've found important to incorporate. on the tactical side, we continue to find that teams really need to focus on getting 'in flow' with regular delivery, before adding complex practices. to do that, populating and preparing backlog items continues to be a challenge. no matter how much higher-level contemplation an organization does about transitioning to agile, and even if their due diligence or readiness assessment points to using agile practices it so often comes down to this: unless the product stakeholders obtain a shared understanding of what they will build, how they know they build it right, and that it was the right thing in the first place, all their investment in transitioning to agile will be for naught. thanks for your article! ~ ellen
Reply | Reply with quote | Quote
 

Add comment