« Project Risk Management: It’s Either Contingency Planning Now or Emergency Relief Later
EFQM Excellence Model »

Keeping Agile Real (and avoid losing people before you begin)

September 21, 2007 | Author: PM Hut | Filed under: Agile Project Management, Project Management Best Practices

Keeping Agile Real (and avoid losing people before you begin)
By Mike Griffiths

I went to see a bad chiropractor a few months ago and his approach diminished my (already quite skeptical) perception of this medical practice. His outright dismissal of conventional medicine and biased view that chiropractic treatment is the only true solution to all ailments turned me away from him and from any benefits I may have found by continuing with his treatment.

I am not comparing agile methods to alternative medicine, instead I’m just pointing out that zealots who fail to acknowledge alternative views can do a lot to damage their profession. As proponents of agile methods, I believe we can make a stronger case for agile by acknowledging strengths of traditional approaches and explaining how agile can help common challenges, rather than by dismissing traditional techniques.

Encouraged by other recommendations, I visited a different chiropractor and received great benefit. He did not attempt to undermine traditional medicine, instead he explained how he might be able to help and we took it from there. My symptoms got worse before they got better, but I stuck with it since his explanations seemed reasonable. My “conversion” moment came when he also relieved some additional injuries I had been suffering with for many years.

I do not think I am alone in appreciating a considered approach. Most of the people I deal with in the business community are smart, conscientious professionals who are looking for successful projects. Yet, we see the actions of zealots and as a believer it is easy to be caught up in their damaging behaviour.

The following list outlines some common examples of how biased thinking can undermine the value of agile methods and offers some advice to ambassadors of agile methods for avoiding these pitfalls.

Dismissing the Waterfall Process

The waterfall process as originally outlined by Winston Royce in 1970 actually contains some really good advice. For a start it recommends that the waterfall process always be run at least twice for a project because you will not get everything right the first time. Also that there should be regular feedback loops and checks along the way to ensure things are working correctly. Take a look, here’s a reprint of the original 1970 paper, look at page 7.

Agile ambassadors could do better to offer agile as a solution to single pass waterfall challenges on software projects rather than a superior approach period.

Running down the PMI, PMPs and the PMBOK

The PMI is a large organization and like all large organizations has its problems. The PMBOK Guide is a victim of its own success; it is not intended to be a “how to run projects” guide, heck it is not even written for the software industry. Instead it is an industry agnostic set of project management basics; a starter kit of standards from which to build guidelines and management frameworks to fit your own project environment.

I teach a two day agile project management course as part of the PMI SeminarsWorld training program and the PMP project managers who attend are smart and inventive. None blindly follow the PMBOK Guide, instead they run projects with the most pragmatic mix of tools and techniques they know of.

Agile Ambassadors could do better by fully understanding the content and strengths of traditional PMI / PRINCE2 offerings before suggesting other tools for software projects with high rates of change.

Obsessing on Agile Processes

Measuring conformance to agile principles, debating “agile” vs “Agile”, declaring a group more agile than another is somewhat oxymoronic. At the root of agile methods is a focus on delivering business value and removing non-value adding, “compliance” activities (waste) wherever possible. In terms of delivering valuable working software to business, debate and measurement of agile conformance are just waste.

Agile Ambassadors could do better by focusing on pleasing customers by delivering amazing software. “You have one tongue in your head and two in your shoes, use them in those proportions.” Focus on building great software and do not get drawn into non-value adding work or debates.

Claiming agile methods are the new way to develop software

There is little if anything new about the techniques promoted by agile methods. Short iterations, story cards, pair programming, test first, empowered teams, the list of reused processes goes on and on. Craig Larman did a great job of tracing the history of today’s agile techniques back as far as the 1950’s in his book “Agile and Iterative Development: A Manager’s Guide”. What the agile movement has done is collect and popularize grouping of techniques that work well on software projects – which is tremendously valuable.

Agile Ambassadors could do better by recognizing the contributions from many previous approaches and focus on the benefits of their combination over claiming to be the latest, new thing.

Mike Griffiths is an independent consultant specializing in effective project management. Mike was involved in the creation of DSDM in 1994 and has been using agile methods (Scrum, FDD, XP, DSDM) for the last 13 years. He serves on the board of the Agile Alliance and the Agile Project Leadership Network (APLN). He maintains a leadership and agile project management blog at http://www.LeadingAnswers.com

Share this article:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • blogmarks
  • LinkedIn
  • Reddit
  • StumbleUpon
  • TwitThis
  • Yahoo! Buzz

Related Articles

This entry was posted on Friday, September 21st, 2007 and is filed under Agile Project Management, Project Management Best Practices. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

No comments yet.

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

The Stevens Enterprise Project Management Master's Program

Project Management Categories