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.
This post is about some obvious changes we can make to our context and thinking to engage discovery more with business value.
This “discovery model” has three aspects to it I’d like to point out.
Value Engagement – What/When to Build
The change from ‘When to Build’ to What/When might appear to be semantics but it requires a change of mindset to rethink your team’s wall. In practice moving the wall should require the inclusion of people previously on the other side. Seek out the people who can speak to value. They might have been excluded because they couldn’t talk technical or were “business types” but our interaction tools are SO much better now. This is where we apply those visual Discovery practices. [Thanks Jeff Patton!]
In engaging the people who know and expect the Value the entire team benefits from the exchange and most importantly the Value definitions, measurements, goals, etc. can be “re-factored” as development discovery occurs. This is now a collaborative effort that is open to discovery. It’s no wonder we had trouble delivering Value; it was delivered to us through go-betweens and the “value people” weren’t involved in the learning/iterative discovery cycle so we had to guess it right the first time.
Value Based Investment of Resources
One concept the LSSC conference reminded me of is very applicable here. A trained team operating within a mature process will, baring special cause variations, produce a certain amount of output. From this we know that a given amount of time/budget (input) will produce a certain amount of output for this team.
Given this, and considering that the value owners are involved with What/When under this model the optimization is different. It is now focused on optimizing the value that can be extracted from the given amount of resources. This is the scarce resources (time and dollars) versus fixed team output scenario David J. Anderson mentioned at the LSSC conference.
For outsourcing models the engagement contracts could be written to define the amount of work to be performed, not the workscope (what is to be delivered). This approach supports Lean. Customers could choose teams based on their development capability and ability to identify/deliver value. This type of “capacity” model is where SEP feels the industry is heading.
Value Verification (and further pursuit)
To complete the change of mindset and promote Discovery let’s challenge the mindset that a product is “done” once it is fielded. It’s great to celebrate these releases and we need to. There tends to be a focus on “what’s next?” immediately after the release party when the focus needs to stay on delivering the expected value.
On new mindset should be that the product is never complete as long as there is value to be delivered; and the Value is worth the cost.
Do we check and monitor fielded systems for value deliver and new opportunity? This can be a collaborative effort between the customer, the development team and the end-users. Since we would now know these business types it is a much easier task to engage them in asking, “did we get what you paid for from that development?” And I would add “….YET?” to that question.
What Next?
For a company like SEP we need to help our clients better understand how we can work together to address collaborative work areas. We also need to innovate our contracting models to be more supportive of collaborations. We hope to present our experiences in this area in the future.
What’s the next big thing? Deployment services. With the technology we have now many products can be easily updated in the field. SEP is building out service offerings and practices to support this area.
