So - in a conversation recently where we were talking about how a large corporation like Big Co. deals with financing their programs, projects, products. The conversation turned to when is the appropriate point to include the engineering teams in the product development mix. The jist of the conversation was that similar to the idea in software engineering that it is terribly costly to use production to find basic coding bugs (bugs that can be caught with unit testing, and code reviews) it is terribly costly for product groups to be using engineering resources to test their theories about what the customers would like to see in the products that Big Co. produces. Adding to this conversation was an ongoing undercurrent of finance at Big Co. having a difficult time understanding how to measure and supply money to the organization in an 'agile' way, meaning how do you make the bean counters happy when talking about how to manage finances in an agile development structure.
So the question that followed from the discussion was - if finance at Big Co. is always looking to squeeze cost out of expensive things like engineering and they are having a difficult time trying to predict and forecast the overall cost in an agile development world, what is a way that product development could be structured that would make things easier on both sides (engineering and finance) as well as help the product folk find and refine their thoughts before ever having engineering develop anything?
I tossed out the following idea, what if you structured product development and finance in a pyramid like the following:
At the bottom of the pyramid, you have lots of really small, experimental teams. These teams could be made up of a product individual, an engineer, maybe an experimenter (someone to help setup customer experiments). Each one of the these teams would be financed based on the ideas that they are testing and each one would be given a finite amount of money, lets say $50k. Each team would also be strictly time-boxed to no more than 2 weeks work on a given idea/hypothesis. Big Co. could then run lots and lots of these little hypothesis tests and know for sure how much they wanted to spend because the dollar amount would be fixed to the number of test teams in flight at a given time.
Further up the pyramid each one of the teams near the bottom that uses the $50k they have been granted and produces a hypothesis that they can prove and have proven, a slightly larger team can then take up the mantle. This next step up gets a larger amount of money, lets say $200k, and their time box grows to something in which they can make the idea from the lower level a little more concrete and real - lets say 6 weeks (for Big Co. currently, this is two sprints worth of development). At any time these teams may run into insurmountable road blocks, or things that have no solution - in which case work can stop and they can move onto the next thing coming from the lower level. If however they produce something adding to the previous levels work, this can move onto the next level higher and be funded further.
Even further up the pyramid - we are getting to the point where things are much more well defined, there has been a fair amount of testing and verification of hypothesis indicating that the idea is sound and can turn into a product or a products new feature. The money granted can be quite a bit larger say $500k-1M or more. The time box to create can be slightly larger as well, say 24 weeks (half a year). I should note that increasing the time box does not mean that the shipment of this new thing waits for 24 weeks - it should still follow agile practices and be deployable at the end of every iteration (or in the Kanban case, after every story is marked complete). This is where the final delivery to the customer can happen.
At each of these levels the product team or business can choose to cut their losses based on real data from real customers saving them from having to finance what doesn't work and keeping the process moving as quickly as it can. This also prevents what I will call "Whim Based Product Development" because all the product work becomes based on testable and measurable facts.
Would love to hear your thoughts on these ideas - as they are just that, ideas. Like most things, they need work.
Monday, June 25, 2012
Subscribe to:
Posts (Atom)
