The Lean Software and Systems Consortium conference in Atlanta left me with a lot to think about. My main reason to go was to learn more about becoming a more agile enterprise but that is a topic for another day.
To summarize my previous post, software projects are often categorized as “too expensive”. However, it is more accurate to say that the actual cost is higher than anticipated cost or that the delivered value is less than proposed value.
There were many speakers with insights into this topic at the LSSC conference. Being a higher level manager, one of my favorite Lean books is Tom and Mary Poppendieck’s ‘Concept to Cash’ book. The conference featured many great speakers including Mary Poppendieck, Don Reinertson, David J. Anderson and Bob Charette.
Like most organizations SEP has seen great benefit from Kanban. We’ve become more efficient; reducing our development costs and increasing the amount of output we can produce – all awesome stuff. But continuing on this path will ultimately lead to diminishing returns unless we move to the next level.
This conclusion led me to consider the context we use to define the software development process.
The wall represents the context boundary we define for what “we” are doing. We (the development team) are on “our” side, and while some people visit to collaborate, everyone else is on the other. We do this too with project issues and work that affects our flow when we say that isn’t our problem or job. It’s on the other side of the wall.
The Contract represents a commitment to deliver. If you perform some sort of contracted service, this contract is often a written engagement spelling out financial and schedule terms. The contract encourages the boundary and defines where the wall is.
SEP had added Discovery services to its offerings as a means to address some of the upstream delays and unnecessary features feeding our development activities. These services have helped tremendously but we still needed to go further.
Our industry often sets its context too small to address the question of why software is so expensive. While addressing costs, we missed optimizing the other side of the equation – VALUE.
To move to a new level of optimization, we need to expand the context of our development process to engage more of the value oriented constituents.
There are some fairly obvious changes we can make to our context and thinking that I detail in a follow up post about extending discovery into business value.
