SUCCESS = RESULTS – EXPECTATIONS (Part 2 of 2)

In my first post we learned that traditional project management brings with it challenges in achieving software success – for both the software delivery team and the customers. When you ask for all the expectations up front and then don’t leave room for customers’ needs to evolve, it’s tough for results to meet expectations. Agile software, on the flip-side, leverages 4 basic concepts to ensure project SUCCESS. These are:

1. Product Owner Engagement. The customer (a.k.a. Product Owner) stays engaged with the team delivering throughout the project lifecycle. In fact, the PO is part of the team. At no point in the process should the PO disengage; decisions and expectations are set near the time the need is built, and subsequently delivered. Requirements evolve. And since the PO stays engaged, changes should not be surprises to either the delivery team or the customer.

2. Quick, High-Value Wins. Needs are delivered in small, manageable and valuable bites. This means the delivery team and customer work together to understand what is the smallest piece of value that should be delivered first, and they deliver just that. This approach helps both the customer and delivery team by narrowing focus, resulting in faster delivery and a focus on getting the high-value need right (with quality). By the way, if the delivery team falls short of expectations for some reason, it should not be a surprise to anyone and since we handle just a small bite. We fail small.

3. The Checkpoint Demo. At regular intervals, the delivery team (including the PO) shows off the demonstrable product increment. Preferably what is demonstrated is a complete capability; however, this is not always possible. At a minimum, enough is demonstrated so that feedback can be provided and the team can show that they are doing what they said they would. This demo provides a checkpoint for measuring success, as well as a way to continuously mold and refine expectations.

4. Continuous Feedback. Conversations are constant within the delivery team, with the customer and with stakeholders. Instead of having formal meetings that are dubbed “Status Meetings,” we have ongoing, regular discussions about the EXPECTATIONS. When an engineer has a question, he or she grabs key team members and the PO to discuss real-time. This results in a clear understanding and lack of “hand-off breakdowns,” where information is translated as it passes from one person to another.

There are many more things we do with agile software delivery methods that ensure our projects are successful (e.g. continuous planning, short release cycles, engineering best practices and a ephemeral drive to get better). But if you start with the above ideas, I can assure you that the software delivery team and the customers will start getting that feeling of SUCCESS.

What are your thoughts?  How does your software delivery team measure success? Another great question: Do you define software SUCCESS before you start your projects?

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