Skip to main content
Enterprise Agile Planning Image

This post is from the Collabnet VersionOne blog and has not been updated since the original publish date.

Last Updated Apr 02, 2012 — Enterprise Agile Planning expert


Enterprise Agile Planning
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.

More from the Blog

View more
Apr 08, 2021

Making IT services more agile

Enterprise Agile Planning
The agile revolution completely transformed how we create digital prod ...
Read More
Feb 14, 2021

Reflecting on the 20th anniversary of the Agile Manifesto

Enterprise Agile Planning
Over the past 20 years, it’s been amazing to watch an idea from ...
Read More
Feb 08, 2021

How does agile apply to an entire organization?

Enterprise Agile Planning
Before we dive into the main subject of this blog post, it is importan ...
Read More
Feb 03, 2021

It took a pandemic to realize why digital transformation actually matters

Enterprise Agile Planning
Before anyone had ever heard of COVID-19, businesses across the globe ...
Read More
Contact Us