Skip to main content
Enterprise Agile Planning icon with arrows

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 Government Cloud
Apr 12, 2022 Government Cloud receives FedRAMP Authorization through sponsorship from the United States Department of Veterans Affairs

Enterprise Agile Planning
Flagship Agility solutions can effectively scale agile deve ...
Read More
Nov 22, 2021

What are the qualities of highly effective agile teams?

Enterprise Agile Planning
A team is the core unit of productivity in an agile organization. Wher ...
Read More
Nov 15, 2021

How an open-first attitude revolutionized government tech development

Enterprise Agile Planning
Public perception of government is often that it is slow-moving, reluc ...
Read More
cross functional
Nov 08, 2021

6 best practices for building resilient cross-functional teams

Enterprise Agile Planning
Agile frameworks prize the quality of resilience within every facet of ...
Read More
Contact Us