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.
Subscribe to:
Post Comments (Atom)
4 comments:
As you know, I think there's merit in this approach. The funding for a bucket is going to mostly be peoples' salaries, although perhaps with some additional (fixed) OpEx for the first level. For projects that "graduate", I could see two possibilities: (1) having gathered some data, ask for specific team allocations plus OpEx, or (2) just have fixed allocations for each additional layer.
It would be interesting to think about a few other things, too:
1. What's the cost of a typical 7-person team for 3 weeks? My math suggests a little under $50K, so that fits your experimental definition.
2. Given that the pyramid scheme is hopefully going to always have some "6mo", "2mo", and "1 sprint experiment" projects going, how many teams do you need and what does a sample schedule look like so that you know who is available for experimenting at any given point in time?
3. Will Big Co. be fast enough at decision making to allow teams to properly groom and transition between sprints, esp. when rolling off an experiment that did not get selected for a 2mo project?
4. How do you handle maintenance for existing products here? Are those just proposed as new experiments?
On 1) If we said that on avg. each person were making $80k, then 7 people for 3 weeks would be about $32k, round that up to say $40k due to insurance costs and other incidentals. Leaving $10k for development and equipment and the like - which seems about right to me. My guess is that we would have to actually test this out to see if $50k is the right number or if it needs to be a little higher or a little lower to get the desired affect on the team. I would of course propose to run the experiment to find out. 8-)
2) I think that this will require a fair amount of experimentation to determine what the real system should look like. My hypothesis is that the lower level teams will have to operate with upper level teams as if the whole system were a series of pistons such that some percentage of the lower level teams are finishing up a batch of 2 week work such that they align with some percentage of the level above them. The interleaving is not straight forward but should be possible to arrange such that there is always work moving up from a lower level.
3) This is an interesting question: in the case where Big Co. can't make decisions fast enough, my hypothesis is that we will have provided transparency to a bottleneck that needs fixing and should be addressed. I am not sure I have a good answer to what happens IF this happens and Big Co.'s decision process is too slow. Transparency will most likely drive someone to 'fix' this as a problem however.
4) Maint I think has a similar but separate pyramid of people, where the experiments are around fixing issues at a root cause level which means investigating, and then refactoring or other needed work to fix bugs at deeper than surface levels. Working to verify and validate that the problem will not come up again by making sure tests are in place to prevent regressions etc. I would suggest also that people rotate into and out of this group as it can be difficult to work on maintenance for long extended periods.
This sounds cool - sort of like a Kickstarter for "Big Co". Maybe to seed the teams you could have people committ "dollars" based on interest in the project and at the end of each time box investors could reup to support the next step in your process. A sort of crowd committment to ease you up the pyramid !
Yeah - That is certainly a possibility Laura, I think they only thing that you might need to be careful with there is people getting attached to the ideas too early. Big Co. like anyone and possibly more than others can suffer from the Sunk Cost Fallacy (http://en.wikipedia.org/wiki/Sunk_costs) - so you want to be able to cut things off that don't work or that only 'sort' of work for customers.
Post a Comment