Business Driven | LeanOrange

Business Driven – Value Streams

March 14, 2013 — Leave a comment

Value Streams

First we need to take a step back understand the business you’re program, portfolio, or enterprise is in.

Your business can be described as a set of business outcomes we call value streams.

We describe value streams as programs that are in place to achieve or extend a business outcome.

Each value stream may have several application areas that support the delivery of end user value. Important: shed any application specific references from this discussion. Being business driven means just that. Focusing on the business objectives and the set of outcomes necessary to achieve those objectives. Therefore, programs are stood up to drive business outcomes through a given value stream to achieve a business objective.

SMART Objective

Business programs should have a clear, dare I say, SMART objective that business outcomes align to. – Increase leads by 20%. Reduce production cycle time by 50%. Without this, a business program will be spitting in the wind when determining the set of necessary business outcomes…if they do at all. Ultimately its, these business outcomes that define releasable chunks of value often referred to as MMF’s, MVP’s, …etc that make up your business program backlog.

Agile Business Planning

A note of caution, we’re not suggesting a big, upfront, business planning session and then pouring cement on those business outcomes that align to a strategic business objective. Achieving value through productive development is a highly uncertain process and requires adaptive business discovery and delivery practices. So its a given that we expect business needs to change as the market evolves. However, once we understand a program’s business objective and outcomes can put the set of adaptive business practices in place needed to drive value through our IT service providers based on business needs.

In subsequent posts we’ll dive into discovering and prioritizing business value. Stay tuned!

In Business Driven

Being Business Driven…are you ready?

March 7, 2013 — Leave a comment

DrivingBusinessValue

So you want to be business driven. Great! Business should drive value while IT service providers achieve value through product delivery. However, without the business practices to discover, prioritize, decompose, align, deliver, and validate value, business organizations could introduce more delays and confusion into product delivery.

So…are you ready?

In Business Driven

Kanban board or BUFD board?

February 25, 2013 — Leave a comment

Kanban BUFD

This week we had a learning moment and we thought it was worth sharing. We’ve been helping a team transition to Kanban to manage the flow of upstream business and analysis work that has a high degree of variation. Before we dive right in…a little background is in order:

The team has been using a Scrum-ish process
External dependencies are a persistent risk
Upstream work was hampering downstream development flow

After a day of Lean Kanban training, we embarked on discovering how they tackled work. We mapped out their standard workflow on a kanban board. After talking through limiting WIP, pulling work, and managing flow via metrics we kicked them off and scheduled some followup meetings.

Upon returning, a pattern had emerged. It seemed that their kanban board had turned into a BUFD board. The work steps had not changed, but what was flowing through each work step was big, really big. It struck us at that moment, that what this team really needed was a deeper understanding of business decomposition. Typically this is a Product Owner responsibility, however in reality this team was handling some of these responsibilities.

Understanding how to break down large value streams into releasable chunks, features, and user stories seems easy, however the lack of mature software business practices was a clear gap on this team. It makes sense, this is an engineering team…not a product management team.

The lesson learned? Business practices matter. Wrapping a highly optimized workflow tool(Kanban) around work will not increase agility if the right sized work is not flowing through the system. This seems obvious but this was a great reminder that reinforcing the basics during any change initiative is worth while and adequate business practices are not common.

In Business Driven, Kanban

Hypothesis Driven Development(HDD)

February 8, 2013 — Leave a comment

We came across this picture while writing the Agile C’MON Man post. The irrational exuberance in this picture gave us a chuckle, but it also reminds us of an engineering group driving product development. As we articulated in the previous post, engineering driven product development can lead to BUFD. At the same time, we articulated the lack of business driven product development is due to ill equipped product management. In this post we will lay out a high level business approach to product development.

We think this is the new frontier for Agile and software development. The Lean Startup and David Joyce’s talk, 21st Century Portfolio Management, are great resources to start shaping how we need to think about driving product development. The fundamental principle that these two resources drive home is learning. Our ability to deliver higher value products hinges on our ability to learn. These resources also champion the fact that learning on the business side does not end after a business case has been delivered, nor after requirements captured, nor after a team has showcased working software at a demo. No, learning needs to happen with real customers. Therefore, we need to consider how we are going to learn throughout the whole lifecycle, including customer consumption.

Learning_Adoption Learning is not a new concept, especially when we talk about feedback loops in SDLC’s. However, the difference here is the measured approach to learning. We should not just ask what should be built, but why it should be built. Therefore, we should wrap measurements by which value returned can be measured and validated. It is this process of being intentional about quantifying results based on predetermined measures that helps accelerate learning. Documenting measures that align to our assumptions, force us to gain a deeper understanding of why our customers want what they want.

Experiments – You may have heard these forward leaning thinkers refer to this process as “running experiments.” At face value, this conjures up thoughts of lab rooms and scientists, but we’re doing software development…right? Well think about it. If we’re making assumptions and documenting what to measure after a capability has been delivered, it’s safe to say that this sounds like a hypothesis. If we build out that hypothesis and then measure the results, we essentially are running an experiment So it’s not that crazy after all.

Recently, a new “xDD” (x Driven Development) has hit the radar. Hypothesis Driven Development(HDD). Its so new, that there isn’t even a Wiki page for it! Mind blowing…I know! Whether you call it HDD, Lean Startup, 21st Centrury Portfolio Managment, or whatever, we think this is an area business product developers can gravitate towards to build better products. If you have thoughts to share on this topic, we’d love to learn with you! Please comment or DM us to continue the conversation.

In Business Driven, Continuous Delivery, Delivering Software, Lean Agile

Agile C’MON MAN – BUFD

January 17, 2013 — Leave a comment

BUFD = Big Upfront Design = C’MON MAN!

Its been 12 years since the Agile Manifesto was signed and we are now living in a world where Continuous Deployment and HDD(Hypothesis Driven development) are driving rapid, profitable, product development. It seems Lean|Agile methods should be peaking mainstream adoption. So why is BUFD still prevalent? Why do I feel compelled to say “C‘MON MAN?”

bufd Simply put, I think its a case where the wrong people are in the driver’s seat. Often, we see IT driving product development instead of the Business. The larger the IT organization or project, the more “steering wheel time” IT seems to have. So what happens when you put a bunch of engineers in charge of product development? You get BUFD. That’s just how engineers think. I know…I am one!

So how did we get here?

After all Agile Manifesto principle #4 clearly states business and IT should work together daily. So aren’t they? Well yes…kind of! We usually see business folks involved with product development at planning, demo’s, and grooming sessions. However, they aren’t driving it. Why not? I think its largely due to the fact that they don’t know how!

Agile practices organically grew out of pain from development teams. Naturally, mature Agile practices consolidated on the delivery end of product development where development teams play. I think this has put product development organizations in a situation where they have relatively immature discovery practices as compared their delivery practices.

In layman’s terms organizations need better business practices to discover what IT should be working on and when!

In the next blog we will explore how we can put the business in the drivers seat to drive value and steer away from BUFD.

In Business Driven