Loading ...
Sorry, an error occurred while loading the content.

Re: Value streams as closed loops

Expand Messages
  • Dennis
    I promised this board a blog post this weekend. This turned into a bigger project than a simple blog post. I am finishing a white paper over the next few days
    Message 1 of 14 , Apr 5 7:41 AM
    View Source
    • 0 Attachment
      I promised this board a blog post this weekend. This turned into a bigger project than a simple blog post. I am finishing a white paper over the next few days that I hope is helpful to this board. I will post that in the next few days.

      --- In kanbandev@yahoogroups.com, "Dennis" <dennis.stevens@...> wrote:
      >
      > Julian,
      >
      > I think your approach is sound. We have been using "Capability Throughput Models" for almost a decade to map knowledge based work. For example, we might produce a list of capabilities from product concept to payment. Then we place the capabilities in three associated streams.
      >
      > The middle stream contains the Core or Value creating capabilities. These are the things that directly contribute to creating value like product management, development, implementation, and support. This is similar to (and heavily influenced by) a Value Stream Map. We have made a number of adjustments to support the variation in flow and value add of knowledge work.
      >
      > The bottom stream contains the enabling and supporting capabilities. HR, Accounting, Project Management, Quality Assurance, Vendor Management, Training Development, ITIL capabilities, etc. might go here. These are things that don't add value by themselves - but that can improve your ability to create value. For example, the point of doing Project Management is to improve your ability to profitably deliver value to your customers - not to do "better PM".
      >
      > The top stream contains Controlling and Governing capabilities. This can include governance, policy setting, and compliance capabilities as well as customer interfacing capabilities.
      >
      > We produce the model collaboratively. Then we facilitate the assessment of the model for performance, business value, and risk and identify those capabilities where an improvement in performance will result in improved performance in the overall system.
      >
      > This model supports intense focus on the next most important improvement and results in an incremental approach to improvement that is supported by the entire business.
      >
      > I will do a blog entry this weekend on this approach and post a link to it. Its a good excuse to get back to blogging.
      >
      > Dennis Stevens
      >
      > --- In kanbandev@yahoogroups.com, "Julian Everett" <julian.everett@> wrote:
      > >
      > > Hi all,
      > >
      > > Last weekend I was talking to a retired lecturer of Lean Manufacturing
      > > processes about value stream mapping, and he said one of the things he
      > > learned from his consulting work in industry is that value stream maps
      > > should always be closed loops. You start with the customer taking
      > > receipt of your product and then chase backwards through delivery,
      > > construction, ordering and marketing until you get back to the customer
      > > again. Closed loops force you to take a systems view of value
      > > generation, ensuring you avoid local optimisation.
      > >
      > > Whilst being mindful that software is not manufacturing, this was a
      > > something of a revelatory moment for me as my previous value stream maps
      > > have always looked like (software delivery) pipelines. I have just tried
      > > the "closed loop" approach on a new project and discovered it resulted
      > > in something that looks a bit like a use case diagram, but overlaid with
      > > the revenue streams and forecasts described in the business case.
      > > Additionally, the high-level featuresets we need to deliver jump out
      > > from the diagram, and it also highlighted an area of required work that
      > > had previously not made it onto my radar.
      > >
      > > On the basis that value trumps flow, flow trumps waste, etc I decided to
      > > try using the value stream map (in dialogue with the stakeholders) to
      > > determine the order that stories get pulled down the software delivery
      > > pipeline part of the stream. In other words, rather than the
      > > stakeholders directly prioritising work, they own and evolve the value
      > > stream map and the map prioritises the work for them. Then it suddenly
      > > struck me: this is basically a roundabout way of getting to Feature
      > > Injection.
      > >
      > > I was wondering if anyone else had tried this sort of thing?
      > >
      > > cheers
      > >
      > > Julian
      > >
      > >
      > >
      > >
      > > This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
      > >
      > > Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this
      > >
      > > This e-mail has been sent by one of the following wholly-owned subsidiaries of the BBC:
      > >
      > > BBC Worldwide Limited, Registration Number: 1420028 England, Registered Address: BBC Media Centre, 201 Wood Lane, London, W12 7TQ
      > > BBC World News Limited, Registration Number: 04514407 England, Registered Address: BBC Media Centre, 201 Wood Lane, London, W12 7TQ
      > > BBC World Distribution Limited, Registration Number: 04514408, Registered Address: BBC Media Centre, 201 Wood Lane, London, W12 7TQ
      > >
      >
    Your message has been successfully submitted and would be delivered to recipients shortly.