Consumable Solutions

One aspect of adopting a disciplined agile approach is to mature your focus from just producing software to instead providing a consumable solution which meets the needs of its stakeholders within the appropriate economic, cultural, and technical constraints.  Let’s examine the term “consumable solution”:

Consumable

It isn’t sufficient to simply produce something that is “potentially shippable”, instead it must also be something that is:

  • Usable. People should be able to easily understand and work with your solution.
  • Desirable. Think of it like this – if you ship something that nobody wants to work with, do you consider that a success? Of course not.
  • Functional. The solution must meet the needs of its stakeholders.

Solution

The fundamental observation is that as IT professionals we do far more than just develop software.  Yes, software is clearly important, but in addressing the needs of our stakeholders we will often:

  • Develop high-quality software
  • Provide new or upgraded hardware/platform
  • Change the business/operational processes which stakeholders follow
  • Change the organizational structure in which our stakeholders work
  • Update supporting documentation

Although delivery of high-quality, working software is important it is even more important that we deliver high-quality consumable solutions to our stakeholders.  Minimally IT professionals should have the skills and desire to produce great software, but what they really need are the skills and desire to provide great solutions.  We need strong technical skills, but we also need strong “soft skills” such as user interface design and process design so that we can produce consumable solutions.

Have any Question or Comment?

9 comments on “Consumable Solutions

Greg

It would be helpful if this site indicated the publishing date of articles. For example, I have not way of determining if this article was published yesterday or three books ago.

Reply

Greg, good point. I’ll look into the WordPress engine and see if that’s an option we can turn on. You’d think that there’d be some sort of “Show date of last update” feature but I don’t remember seeing one.

We do our best to keep the articles up to date with the latest version of the material, although as you indicate there’s no way for someone to know that looking at the page itself.

Reply

I think I understand the intention behind the phrase ‘Consumable Solutions’. I also believe that teams will strive to deliver a product that is desirable.

Scrum teaches that every increment should be “potentially releasable”. That doesn’t mean that it is indifferent as to desirability. It simply reflects the reality that we do not know whether the increment is desirable until it is in the hands of the end customer and they provide feedback. A good Product Owner will measure this and test their assertions of ‘value’ (of which desirability will certainly play a part) for all product backlog items.

So I’m curious to understand how Disciplined Agile measures desirability prior to delivering product?

Disclaimer: I’m a Professional Scrum Trainer with scrum.org. My intention in asking the question is to understand Disciplined Agile

Reply

Derek, that’s a very good question. To put things into context, the way that I like to think about consumability is that it’s a combination of usability + desirability. When we say “potentially consumable” it needs to be potentially shippable/releasable + usable + desirable. The usable and desirable aspects are of course in the eye of the beholder. To measure these things the best way is to get the solution into the hands of the actual stakeholders as often as possible and see how they react to it.

But wait, there’s more! (North American joke, sorry)

In DA we use the term potentially consumable solution rather than potentially shippable software. We make it explicit that the solution deals with more than just software, that you need to look at the bigger picture. We’ve found that too many agile teams miss this in practice, often because they choose to focus on what they consider to be the fun stuff, the software. As a result they may write great software but what they deliver isn’t as consumable as it could be.

Reply

Leave a Reply to Cross-functional product management teams | Oliver's Blog Cancel reply

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