February 9, 2010 | Author: PM Hut | Filed under: Agile Project Management,Project Management Musings

By Demian Entrekin

Agile has certainly made the rounds as the latest and greatest software development methodology. Scrum has followed right along as a manifestation of this process. They even have, as any good movement should, their own manifesto. It is called, of all things, the Agile Manifesto.

Depending on how you look at the world, agile is either radically different from previous software development methodologies, or it is quite similar to previous methodologies. Agile might be used along with Joint Application Development (JAD) or it might be used alongside a more formal process for defining requirements.

Either way, Agile necessitates a certain set of assumptions and capabilities, most important being the ability to re-factor when we get things wrong, which we always do. Agile is a fine example of an iterative method, where you acknowledge in advance that you will get things wrong, so hurry up and get started.

This is the point where agile begins to falter. I’m sure some of you will have your own views of where agile falters, but here is mine. Agile is a business process, not a software development process. In other words, if the business does not understand what it means to go to market with something that is already accepted as “wrong” and that we will “adjust” as we go, you are in for a very rude set of status meetings.

If the key decision makers on the business side of the business do not understand how to do their jobs in an Agile shop, you will have the illusion of chaos, which will lead to real chaos.

To be more clear: if the CEO and the CFO and the CMO and the VP Sales do not understand what agile implies and what it feels like, then you will most likely get blown up before you get very far. You will “get it wrong” and never get the chance to re-factor.

Agile requires a certain level of trust that comes from experience. This is true of any software process that is inherently iterative, but agile seems to need it more than others. Agile works great, for example, when the CEO, the CFO, the CMO are all the same person, and this person understands technology. Otherwise, tread carefully.

And keep your manifesto to yourself.

Demian is the CTO of Innotas. As founder and CEO, Entrekin oversaw marketing, product development, sales and services for the company. Today, he focuses on strategic product direction. Prior to Innotas, Entrekin co-founded Convoy Corporation and was Chief Architect of its initial products. In that role, Entrekin helped the company lead the middleware market with an annual growth rate of 670 percent and played an instrumental role in Convoy’s subsequent acquisition by New Era Networks in 1999. A recognized thought leader in Project Portfolio Management, Entrekin has published numerous papers on PPM and his blog (PPM Today) explores current issues related to successful PPM implementation. During his 18 year career, Demian has assumed leadership roles as a consultant and as an entrepreneur, delivering commercial and corporate database applications. Demian holds a B.A. in English from UCLA and an M.A. in English from San Francisco State University.

3 people have left comments


This whole article is based on a shallow understanding of Agile. Apparently you have not really used Agile in real world, you just heard about it.

T. Seely wrote on February 9, 2010 - 3:02 pm | Visit Link

Interesting, have you ever ran or been involved in a project ran using an agile methodology?

There is no expectation that anything is ‘wrong’, but a realisation that change is inevitable, and rather than spend huge amounts of time trying to plan, accommodate and mitigate the risk of these changes at the start of the project, usually by way of a long protracted requirements analysis phase which is ‘wrong’ as soon as it’s completed. Agile allows for that change and removes the dependencies on individual deliverables (as much as possible) thus limiting risk.
True there is a need for trust, as there is a more formal PM methodology such as Prince2; however, unlike prince there is no dependency on documents, and more on mutual communication. It is a much more open and pleasurable environment to work in and whilst it may not fir all circumstances, has, in my experience produced much more resilient and robust software than other methods of ‘control’

john morse wrote on February 12, 2010 - 3:27 am | Visit Link

I was encouraged to take a look at this article from a comment made on my blog, where I’ve been talking about the benefits of Agile. I agree with what you are saying about C-level understanding and the implications as ingredients for Agile success. Expectations must be set! We went through an exercise at my company where the management team participated in the crafting of a document called “Agile Expectations” – the document itself wasn’t all that informative to anyone already familiar with Agile development, but the exercise got everyone talking and thinking about how Agile development would change our organization and what our new expectations needed to be. It was a great organizational change effort that helped to align everyone from the top down.

I think that Agile development draws upon experiences and techniques that have been proven to work. You mentioned JAD in your post, and I coincidently made an observation that JAD is one method proven to reduce scope creep in my latest post about reducing risk.

Agile development has been getting a lot of press and attention at the expense of traditional, waterfall-oriented projects, but I think that it is worth examining what we should expect, what is working, and what needs to be re-thought and/or discarded, regardless of the methodology. Determining what to use and when can be based on circumstances, for example. Most business-oriented software tends to need adaptability, and I’m sure other applications like medical devices (I have no experience in this field) need to very crisp and stable requirements that are rigorously tested against the spec.

Dave Moran wrote on July 7, 2010 - 12:54 pm | Visit Link

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=""> <s> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories