Deliver Fast. In a way, that’s a funny principle to have. I would have thought that’s stating the blinking obvious! But the reality is that it isn’t. All too often in software development, things seem to take ages.
It is common for people to think too deeply about future requirements that may or may not ever arise.
It is common for people to be blocked – maybe requiring help or information from others – and not to react to that problem with the kind of urgency it deserves.
It is common to over-engineer solutions, both in terms of the software architecture, and also the business requirements.
Why build a simple solution and get it to market quickly to be enhanced incrementally based on real customer feedback when you can build one gigantic monolithic beast of a system and build it all before you launch anything for your users? (for those that can’t detect sarcasm, that was meant to be ironic btw!).
When a team is held up waiting for someone, others in the team could potentially pick up the task everyone is waiting for and get it done, even if it’s not normally their role. It’s important in agile teams to establish a good team spirit. It shouldn’t be the case that everyone sticks rigidly to their job specs. “That’s not my job” really isn’t a phrase I’d ever like to hear in an agile team. If the team needs something done in order to achieve their objectives, the whole team should feel willing and able to help each other out, even if it sometimes means deviating from their usual speciality.
Speed to market is undoubtedly a competitive advantage. There is considerable evidence that companies who gain ‘first mover advantage’ go on to be the most successful companies in their chosen sphere. Companies can copy, and sometimes even come along later and do things better, but often it is the first to establish itself that wins the day and becomes the long term leader in its field.
Another advantage of delivering fast is that, if there is as little time as possible between the Product Owner stating the requirements and the team delivering the product, there is little chance of the requirements changing. Less time minimises the chances of changes in the market, changes in people, or even simply a change of mind.
So what is required to go faster?
To read more about lean principles, see here the 7 Key Principles of Lean Software Development.
7 Key Principles of Lean Software Development: