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?
BTI360’s CEO, MJ Wivell, spoke at the Lean Software & Systems Conference on the subject of Lean Giving Beyond Software. Click below to see how sharing your talents could impact others.
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:
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.
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 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.
Steve Denning, from Forbes, has an excellent article detailing and commenting on the Air Force’s recent $1.3 BILLION debacle. The federal government does not have a stellar track record delivering software projects on time and on budget. Unfortunately, some of these failures are on an epic scale.
However, there is some good news. Despite this bad news, there are scores of software projects that are currently delivering regular value to customers and…wait for it…they are doing it within the Federal government! So it can be done!
What’s the common thread among a large majority of these projects? A vast majority have used Lean Agile methods to do so. The idea is catching on. AgileDC is a well attended conference. GlassCon(Gov’t Lean Agile Software & Systems) conference is gaining steam. Several meetup groups are thriving from the Agile Leadership Network to the Lean Kanban DC group. The icing on the cake is the GAO recommended to Congress and government agencies that Agile methods should be used when doing product development to prevent failures like the Air Force modernization project.
It’s coming folks. There are great people in government who get it. Here’s to hoping that we never have to report on a software delivery failure of this magnitude again!
MJ and Clinton Wivell are the main thrust behind Enterprise Lean|Agile coaching at BTI360. This is where we publish our thoughts and experiences on scaling software agility using Lean|Agile methods and practices.
More about us...
|
|
|
|
