Then you go right back into it the next day.
Which will eventually burn you out.
But greed and excitement are wonderful things, so you muster your energy, take a deep breath and dive back in. The launches are satisfying. The acknowledgment from your peers and management are satisfying. The accolades, press releases, funding efforts, and the promise that you are contributing to the Next Big Idea are all satisfying. But you know that it can't continue forever; that at some point the company will need to cross over from Commando stage to Infantryman stage and then eventually to Policeman stage (use what ever stage names you prefer here).
So here's the question; What do you need in terms of process at each stage?
Let's work our way backwards. No one would be surprised to find a mature CMMI and ITIL led organization at the Policeman stage. Some degree of CMMI maturity would quite natural for a company at the Infantryman stage, say CMMI maturity level 2 or 3; repeatable and documented process, improvement processes and some feed back capability.
But what about Commando? What about start ups? Eventually the commandos will move on and the company will be taken over by Infantrymen, but that could take years. For how long will the Commandos be running on their own gumption?
Those who live by process know the value it brings; reduced flailing, more reliable delivery, lower defect rates, greater alignment to business objectives. However, there is the challenge of perception to overcome. Perception that process interferes with creativity, introduces bureaucracy, hinders agility and is too expensive. Especially within the start up environment, which is often Cowboy development. "We have smart people, we don't need all that process stuff"
Poppycock and balderdash.
This is a simple case of "enough." Just enough process to deliver effective products. Just enough framework so that everyone knows that stages. Just enough practices so that a repeatably effective cycle can be created. Just enough monitoring and feedback to that mistakes are not endlessly repeated. Just enough borders to ensure that goals are repeatedly redefined to the point of ineffective thrashing. The basic check list is short:
- Short, but effective cycles -- this allows for flexibility and redirection without throwing away effort.
- Clear deliverable at the end -- the thrill of victory is a strong motivator
- Clear success factors -- New features in this build? Then only new features. Bug fixes? Then only bug fixes. One new feature and three critical bugs? Fine; do only that. What is the least amount that you can do to be successful in solving todays problems.
- Blessing and direction from senior management -- no sponsor, no work. The stakeholders decide what is the most important thing for them to have.
It is quite possible to respond to the short-cycle real-time demands of a start up. After all, the start up is first an idea. That idea will be tested by your customers, who will then tell you what business you're in.
All that stated, you have product to deliver. There is time pressure, and although there are unending pressures to constantly change, tweak and improve your product, you simply HAVE to launch. You HAVE to get to a launch date and the product MUST be released. Never loose sight of that.
So then the next question is "How can you manage the exchange of endless pressure with the real-time need to deliver?"
This is the job of product management. Product management starts with industry and market knowledge, time to market and market opportunity, cost to develop and return on investment. The funnel of endless ideas must be quickly and efficiently evaluated by a capable product manager. The value of the idea needs to be quantified without romanticism. The cherry picking becomes much easier at this point.
In summary, enough software process in the start up will produce superior products more effectively than ad hoc or heavy handed models. Focusing the development work on valuable efforts comes for successfully vetting the opportunities and defining the critical success factors.
No comments:
Post a Comment