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?

This entry was posted in Agile Adoption, Agile Benefits, Agile Development, Agile Management, Agile Methodologies, Agile Software, Agile Teams, Agile Testing, Scrum Development, Scrum Methodology. Bookmark the permalink.

4 Responses to SUCCESS = RESULTS – EXPECTATIONS (Part 2 of 2)

  1. Mak says:

    This is an interesting perspective on 4 basic concepts leveraged by Agile Methods to ensure project success. I am a strong believer in Agile Methodology and believe above are extremely important for project success in any scenario, though maybe in some varying dimensions.

  2. Ravi says:

    Hi Matt,
    I understand your suggestion regarding PO being part of project cycles. One of the situations that may come up are P1 incidents on systems which are LIVE along with the development team focusing on development activities of the sprint. How can PO keep focus and say the development team should focus on the items in current sprint and not bother about the P1 incident till next sprint? Since PO is in between Business and dev team how should he react to such situation?

    Thanks,
    Ravi.

    • Matt Badgley says:

      Hey Ravi,

      Good question and good point. I’m assuming a P1 is a top priority customer issue. We used to have these and called them “All Hands” issues. For these, the Product Owner was very aware of them and knew that we would have to talk as a team about what will not likely be finished. This discussion was usually pretty easy since the things at the bottom of the list were ranked lower, they usually got moved to the next iteration (if indeed the issue impacted the team that much).

      So to the point of this discussion, the PO is engaged and part of the decision making process about what get’s impacted by dealing with the P1. That being said, we could probably have another discussion altogether about ways to handle support for teams that are also building new stuff. There are techniques like allocating a single team member to support, having an expedite row on the board for the “All Hand’s” type customer issue, etc. I’ll make a point of making this an upcoming post.

      Thanks for the comment Ravi.

      Matt

  3. Julio says:

    A couple of hour before read this post I was listening a podcast about 10 reasons of traditional projects failures. The podcast is good, but the reaction proposed is to apply some of Pmbok Process. Wich ones? Well, you decide…
    With agile I see clearly that the process is light and you don´t need a lot of energy to choose and understand and worst, make others understand, how we must work.

    Thanks for this simple and direct receipt of sucess!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>