April 3, 2012 Matthew Badgley

When I talk with people learning about agile software, I often play the game Presto Manifesto where the room talks about what it means to have a successful project and then breaks up into groups and – based on their experiences – comes up with a list of critical elements they’ve noticed on successful projects. This exercise is meant to bring people to the concept of what makes up the Agile Manifesto.

The interesting thing is that in many cases, we discover that we’re programmed to believe that project failures relate to not knowing everything up front. I almost always hear, “complete, thorough and approved requirements” as elements of a successful project. This programming aligns well with the formula of success, which I learned during my short stint at an ERP consultancy firm:


This formula leads us make sure that we set clear expectations so that we can meet and hopefully exceed them – thus, leading to success. However, as we know and learn in agile software delivery (and really in any process), thinking that the users/customers know everything about a project (a.k.a. need) 6-9 months before they get their hands on it is simply a fallacy.

Sure, we can make the customers agree to the expectations ahead of time. But doesn’t that negate the ability to achieve value and ROI for the project? What generally happens is that the users/customers define the requirements and agree to them; then sometime about a month before the project is delivered, they get their hands on some working capabilities and then say things like:

  • “This doesn’t work like I expected; can you add a screen that does this?”
  • “We’ll need a report that gets generated daily.”
  • “If we don’t get these, we really can’t use this product.”

The response of the software delivery team is usually something like, “But you signed the requirements document” or “Those are great ideas; we’ll need to do that in the next phase” or “That will need to go through the change control process; we’ll need to escalate this.” Ultimately, the team isn’t happy because they don’t get to experience SUCCESS. The RESULTS fall short of EXPECTATIONS. On top of this, the customer isn’t happy either.

In an agile software approach, we can improve our SUCCESS rate by applying 4 very basic ideas. On Friday I will follow up with these 4 ideas and provide some tips on how you can give both your software delivery team and your customers a feeling of SUCCESS that is difficult to achieve in traditional project management.

The post SUCCESS = RESULTS – EXPECTATIONS (Part 1 of 2) appeared first on VersionOne Blog.

Previous Article
The Top 4 Reasons You Need to Attend AgilePalooza
The Top 4 Reasons You Need to Attend AgilePalooza

The people have spoken: “Open Space: Alan Shalloway helped lead discussion. Loved it!!” “Great discussion a...

Next Article
The gift of failure
The gift of failure

Scrum will help you fail in 30 days or less. — Ken Schwaber, c2001 I spent some time talking about risk and...