Outcomes over Features – the fifth agile value?

I’ve been having difficulty recently with a trend I’m seeing on projects. What happens is this: we (an agile development team) engage with a client for a short period – typically 2-4 weeks – to investigate how we might work with them to solve their problem. During this period, we drive out lots of stories, do some technical investigation and estimation, and out of this we generate a high level release plan. All very good, you might think. But then, unfortunately, everything is mysteriously forgotten about except the release plan, which suddenly grows horns and fangs and becomes a Fixed-Price Fixed-Scope Big Up-Front Project Plan. Well ok, it’s not quite that dramatic, but it certainly doesn’t feel very agile to me. Hopefully I can explain why.

To my mind, there are two primary objectives of this initial phase. Firstly, we get to know each other and think about how we want to work together. Secondly, we create a shared understanding of the project’s objectives, timescales and risk profile. Coming out of this process, everyone should have the same sense of “bigness” of the project, in terms of both size and complexity. The release plan is just a detail in the process.

An agile project – in fact any project – should focus on a set of outcomes. How we get there is less important than actually getting there. A CIO or business sponsor wants to solve a specific problem, by a specific date, and has an idea of how much money they are prepared to spend achieving that. By driving out a comprehensive list of stories, estimating them, and then rolling it all up into a Big Release Plan, you run the risk of focusing attention on the features (stories) and defining Success as the delivery of all these stories. This is exacerbated when the release plan is shown to people who weren’t part of the original exercise. They see the release plan and naturally assume that it is the primary “output” of the process.

In the manner of the Agile Manifesto, whilst there is value in delivering a list of features, I value achieving the outcomes of the project higher. This feels complementary to the other four agile manifesto values.

Two recent examples. On one project it became apparent that we were unlikely to meet a particular hard deadline given the current story backlog. The team worked with the client to find a way that they could still meet the project’s outcomes and deadline, by dropping or deferring around a third of the features. The client was delighted! The message was simple: I can meet your outcomes with only two thirds of the effort (i.e. cost) of the previous plan. Who wouldn’t want that? That conversation would have been dramatically different if the client had been wedded to the feature list as the definition of success of the project. Luckily he had the insight to remain focused on the overall objectives of his project, and they hit the date.

Another project had a stability issue in production. The (very critical) application would fail mysteriously every couple of days. They needed a solution now because they were losing business as well as being in danger of getting in regulatory trouble. The project manager simply asked the operations guys to manually restart the application every night as a standard operating procedure. At a stroke the initial problem was solved – the outcome was met – without a single line of code being written. Now the team could focus on solving the root cause, without being under pressure to produce a rush job.

“Scope” is a dangerous word, since it can be used to mean either features or outcomes, but never both. Does “cutting scope” really mean failing to meet objectives? Or were those features not really core after all? A project has to have a goal, otherwise you can’t know when you’re done. Without a goal, you will tend to define “done” in terms of execution of the story list. Similarly, it has to have a feature list, or you don’t know what you’re going to do to get there. So it is just as big a risk to have no clearly defined outcome (i.e. no vision or purpose for a project) as defining a fine-grained feature list up front. Next time you engage on a new project, make sure the entire team – and especially the sponsor – has a clearly articulated outcome for the project. And make sure you regularly review your direction to ensure you are still working towards those outcomes.

21 comments

  1. Very Perceptive.

  2. “An agile project [...] should focus on a set of outcomes. How we get there is less important than actually getting there.”

    Isn’t this a contradiction in terms? The way I see it, agile defines the way we get there, which – in my opinion – happens to be one of the best ways.

    1. I think we are violently agreeing. “Agile” is a mindset based on values or principles. When you say “agile defines the way” we deliver, you run the risk of people imitating you in a cargo cult style, adhering blindly to The Practices whilst the project fails around them.

      I don’t doubt that you deliver successfully, because you adapt your practices and behaviours according to what’s happening on your project. When you do this, you are actually focusing on achieving the outcomes over delivering the features. But it’s so intrinsic that you don’t even notice it.

  3. Dan – good post. Problem is that many clients equate outcomes with features. Especially if it is a customer facing product that is being built. “Our competitors’ products have these features. We are being beaten up in the market place. We need these features to reach parity. The outcome of the project is features”. With this mindset they want assurance that the features will be delivered. They look for the security and comfort that a release plan gives them. Getting out of the mindset will be a challenge. So we’ll call it a roadmap instead of a release plan then? :)

    1. Jeff Santini · ·

      One of the things most important to me about what we do is to make sure all interested parties are educated as to the (small) amount of security you can responsibly derive froma release plan that has both hard dates and hard feature sets with no working software actually produced.

  4. [...] 2 – DanNorth.net » Outcomes over Features – the fifth agile value? (tags: planning article agile) [...]

  5. Erik Engbrecht · ·

    I think I agree, but you need to define “outcomes” more precisely. I personally believe failing to define outcomes at the begining of a project is the surest way to create a money pit. Well defined outcomes bring a higher level of understanding to the project team and greatly increase focus. That being said, they are incredibly hard to define. Much of the time customers don’t really know, and I’ve on several occasions killed projects by insisting on their definition. No one understood how the proposed application would deliver value, and once people understood that no one understood that – the project ended. That’s the correct outcome, in my opinion, but it would be hard to reach that conclusion if I was a contract developer.

  6. [...] Outcomes over Features – the fifth agile value? Really interesting post focussing on the advantages of keeping the objectives of the project in mind as opposed simply focussing on the feature list. (tags: agile) [...]

  7. [...] The last paragraph in the article ties in nicely with a post that I read yesterday in which the author describes what he perceives as the 5th Agile value. He thinks the main focus of any project should be it’s desired outcome and that that is often lost sight of when the Customers are considering their desired feature set. I’ve found this to be true recently and feel that I, perhaps, was slightly to blame. I’ve been very keen to play the “let’s get a list of all the features that you require and prioritise those” and the “you can always add more” cards without truly asking whether this was absolutely essential when considering the 2 objectives that we as a Delivery Team have been set. [...]

  8. James Roberts · ·

    Spot on!

    I’ve been banging this drum for some time. There’s a big puch for Agile in the company(I work for), but there is still a fixation with delivering a given feature set by a certain time, where to do so would be considered a successful project.

    The current project was started as a waterfall project, trying to complete a list of features before the users had sight of it – since we changed to Agile, the vast majority of those features are still in the backlog as more useful and valuable features take priority.

  9. [...] The problem comes when this list suddenly grows horns and fangs and becomes a Fixed-Price Fixed-Scope Big Up-Front Project Plan. Craig Larman once joked that the waterfall process has strong antibodies that reject iterative processes by warping them into some form of waterfall. RUP has been a common victim of these antibodies, seeing its phases turn into some variant of the analysis-design-build-test conveyor. [...]

  10. Software Architecture Workshop in Arosa: back to reality…

    Last week I had the privilege to spend 5 days in Arosa, Switzerland, among a group of people who were…

  11. Ryan Hoegg · ·

    Good insight, but I think this is really a corollary of “Customer collaboration over contract negotiation”. Perhaps the commitment to a list of features is really a symptom of the product owner’s unspoken assumption that the release plan is a contract?

  12. Ryan Hoegg · ·

    Good insight, but I think this is really a corollary of “customer collaboration over contract negotiation”. If the product owner is resisting changes to the release plan based on new information, perhaps he views the release plan as a contract you’ve committed to.

  13. Role of QA and Testing in Software Product Development…

    With the ever-shortening software release cycles, assuring the quality of codes, while managing the cost and risks involved, is a major challenge faced by a majority of software development enterprises nowadays. With project life cycles decreasing even…

  14. [...] isn’t really news to the agile community, of course. Both Dan North and Martin Fowler have discussed the double-edged power of the user story, the benefits and dangers [...]

  15. This is awesome! I was was thinking the same thing (http://seandenigris.com/?p=63) and I stumbled upon your post. There is a whole other level driving the behaviors.

    - Sean

    Thanks for the awesome work on BDD. It really maximizes the benefits of TDD.

    1. Hi Sean.

      Thanks for your kind words. I took a look at your blog and I’m really pleased you are looking at domain-driven design – it was a real awakening for me. The combination of a strong domain model and a focus on delivering value to stakeholders is unbeatable.

      Let me know how you get on with this stuff in C++. I know the tool support isn’t as strong for much of the process automation, although having said that, make(1) has been around for about 25 years!

      1. The DDD/BDD combination is what got me back into coding. Programming seemed very hit-or-miss before TDD came to town and developed to this point :)

        I’ve been using Boost.Test until I find/create a true BDD solution.

        e.g.
        ///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
        //Specification source file

        class steps {
        public:
        // Givens
        void GivenIHaveNotCollectedAnyMoney() {}

        void GivenThereIsOneMemberInTheSystem(const std::string& member_name) {
        member_repository_.removeAllMembers();
        member_repository_.addMember(member_name);
        }

        //Whens
        void WhenIStartTheApplication() {
        CoffeeFundCGIApp app(member_repository_, output_stream_);
        }

        //Thens
        void ThenIShouldSeeAMenuWithMember(const std::string& member_name) {
        verifyHeader();
        HTMLExpert daveRagett(outputAsString().substr(25));
        BOOST_CHECK(daveRagett.doesOutputContainAMenuWithChoices(member_name));
        }

        };

        BOOST_FIXTURE_TEST_CASE( scenarioStartCollectingWithOneMember, steps )
        {
        GivenThereIsOneMemberInTheSystem(“DeNigris”);
        WhenIStartTheApplication();
        ThenIShouldSeeAMenuWithMember(“DeNigris”);
        }

        ///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
        //CoffeeFundCGIApp specification file

        BOOST_AUTO_TEST_CASE( shouldOutputMenuWithOneMember )
        {
        MemberRepositoryForTesting member_repository;
        std::ostringstream output;
        CoffeeFundCGIApp app(member_repository, output);
        HTMLExpert daveRagett(output.str().substr(25));
        BOOST_CHECK(daveRagett.doesOutputContainAMenuWithChoices(member_repository.member_name));
        }

        As you can see, I’ve noticed when implementing BDD, often my app controller tests and high-level features are almost duplicates of each other. What is the point of having both, if any, unless you’re mocking classes out? Which I’m not doing because the ostringstream is easier to use than to mock.

  16. Giovanni Asproni · ·

    Am I missing something or “outcomes” in this context are what Scrum calls “goals”?

Follow

Get every new post delivered to your Inbox.

Join 437 other followers

%d bloggers like this: