How to build the Right Thing

The software industry is going through a shift of mindset.

Agile basically solved the problem of how to deliver software. Most any company that applies an agile method and mindset can get working software out the door. Now, the biggest waste in software development seems to be building the wrong product, or the wrong features.

“There is surely nothing quite so useless as doing with great efficiency that which should not be done at all” -Peter Drucker

This insight has given rise to methods and techniques such as Lean Startup, Impact Mapping, Story Mapping, Feature Injection, etc. But is there a common denominator, a set of underlying principles?

On Feb 11, Gojko Adzic organized a full-day meetup in London with people deeply engaged in this issue, people like Jeff Patton, Mary Poppendieck, Ingrid Domingues, Chris Matts and others who have been inventing and spreading techniques for dealing with the how-to-build-the-right-stuff issue.

It was a very inspiring day! We compared our different approaches and experiences, extracted the core principles, and (to our surprise) managed to condense it into this shared message:

Great results happen when:
1. People know why they are doing their work.
2. Organizations focus on outcomes and impacts rather than features.
3. Teams decide what to do next based on immediate and direct feedback from the use of their work.
4. Everyone cares.

There. So now just go do it! 🙂
Actually, if you want a more detailed description of each point see Gojko’s post.

Posts from the other participants:

Full participant list (in no particular order): Gojko Adzic, Mary Poppendieck, Gabrielle Benefield, Tom Poppendieck, Gordon Weir, Henrik Kniberg, Jeff Patton, Ingrid Domingues, Karl Scotland, Russ Miles, Christian Hassa, Dulce Goncalves, Aaron Sanders, Shadi Almviken, Chris Matts, Olaf Lewitz and Matthias Edinger.

25 responses on “How to build the Right Thing

  1. Not surprising at all. Simon Sinek has been preaching this message for quite a while now. And I say often that for Agile to work on a product there must be at least one person who cares about it – otherwise the whole thing degenerates into typical corporate game of renouncing any responsibility. When everyone cares the sky is the limit.

    ps. Spotify came to Poland! 🙂

  2. Wow! I would really like to use that as a manifesto at my workplace. Should we call it something special? It is much more easy to explain to an organisation than the Agile manifesto.


  3. Oh, to have been in that room…. These are the same principles I’ve been espousing in my engagements, and even as an employee and manager in years past. I love how succinct the ‘message’ is though – well done! The trick is to help individuals and companies embrace this, instead of fighting against it. I’ve been working on something around ‘beyond agile’, focusing on the behind-the-scenes-important-stuff that needs to be in place and working for things to work great. I keep coming back to human connection – that’s really what it’s all about.

  4. I have a doubt about the point 3: the “Teams” term includes the Product Owner or alike? Because as far as I know, what to build is based on Product Owner decisions and his arragement of the Backlog, even if he can listen to all the stakeholders.

    Apart from that, I doubt that it will be the Team, even counting on the PO, which decides what to build next. Business stuff should be the people that knows what must be built, based on business value, etc.

    1. Business stuff should be the people that knows what must be built, based on business value, etc.
      Hm. That would be a first..

    2. Indeed would it not be nice if the PO or ‘business people’ could just tell us developers what they want, or maybe even what the END USER wants, or maybe even what the end user NEEDS but doesn’t know she wants.

      Sorry to break this to you all: it’s not gonna happen. 🙂 Not without ‘immediate and direct feedback from the use of their work’, ideally based on hard facts.

  5. It’s not so difficult to create organisation like that from scratch.

    But what about organisations which already exists? Especially point 4) “Everyone cares” could be difficult to achieve without firing people.

  6. Not ever a flamer before but this ‘core’ set of principles is so abstracted up into the ephemeral as to be of little practical use. Does anyone else see that? Take note, I say that the principles are 100% correct, but the distillation process has rendered them the Emperors New Clothes.

    The community that will lap this stuff up needs less philosophical and more tangible advice in my honest and frank opinion.

    Before retaliating, please read the title. ‘How to build the right thing’ sets this up as a recipe to do just that but the reality is that if you are good enough to act on these points in an org that doesn’t already do them, these points are stuff you already know, in different words and its even more likely that you are somewhere on the sliding scale of greatness where you know the importance of all of this stuff, and can get there with only half.

  7. What did you meen with “everyone cares”. Who is everyone? The team and it’s surroundings? And what do you mean by cares? Cares for the success of the product?

  8. So simple, yet so difficult. An old saying goes something like : “It is complicated to make something simple and it is simple to make something complicated.”. I suspect this is applicable to all things we humans do. I love the fight against it. Keep it up!

  9. ‘Agile basically solved the problem of how to deliver software.’

    1) I know a lot of people who would contest that statement.

    ‘Most any company that applies an agile method and mindset can get working software out the door.’

    2) I know a lot of people who would contest that statement aswell.

    ‘Now, the biggest waste in software development seems to be building the wrong product, or the wrong features.’

    3) I thought Agile was meant to solve that. See my comment 1 and 2.

    1. I agree it’s not quite that simple as that agile _solved_ the problem of ‘building the thing RIGHT’.

      I also agree that agile claimed also to solve the ‘building the RIGHT thing’ problem, but many agile teams are struggling to do it.

      But XP and agile has brought A LOT of insights on how to do this well over the last 20 years. Maybe it’s the best of all the bad methodologies out there so far…

      I personally think the above principles are at least more specific and concrete than ‘Individuals and Interactions over process and tools’, etc. Time will tell if they provide better guidance.

  10. Maybe I’m jaded, but I’m with Carl here. I don’t see anything new here that we didn’t already know. I would have hoped for more and better guidance on getting there, i.e., the journey is the hard part, these goals are great, but non-actionable. What does this say needs to be done In a dysfunctional organization, where middle management is focused on setting (unreasonable) dates, the environment is low- or no-trust, and top management is disconnected from what’s happening?

  11. @Ted

    there are many practical techniques that will help you get there, such as lean canvas, feature injection, real options, impact mapping and so on. The message was intentionally abstract to try to convey the principles behind all those ideas.

  12. I’m not sure to understand how you can focus more on impacts than feature. I understand than the main indicator shouldn’t be the velocity (or something like that) but more some indicators of success defined with a lean canvas (or something like that). Am I right ?

  13. “If I had asked people what they wanted, they would have said faster horses.”
    ― Henry Ford

    It’s not just listening to the voice of the customer, but understanding their needs that leads to creating the right product. Unless you have a working crystal ball, you will need to go through an iterative learning process to get to that understanding.

  14. Some of the comments are that these are philosophical principles and not actionable techniques. User Stories largely came out because the original intention of Use Cases was lost in a lot of the teaching and practice. A Use Case is a Principle User who is pursuing a goal, and how they will use/interact with the system in an attempt to achieve that goal. Even a complex system was not supposed to need more than a dozen top-level use cases. We ended up seeing too many “User logs into system” examples of use cases (getting the user to satisfy a system goal by performing a single interaction). So someone came up with User Stories to try to get back to the original “User+Goal” capture; again too many low level system needs are captured instead.

    Only by teaching the higher level purpose will get us moving forward. Ten years after the original post this is still true.

    BTW, my main objection to “user stories” is that we need “stakeholder stories” instead. Often times, particularly with IS applications, the user is just a proxy for the actual stakeholder, and it’s not just the customers we need to be concerned with.

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.