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?
Firstly, as with any methodology, it's important to
have the right people
. Lean thinking in the manufacturing industry originally changed the way companies think about their people. Instead of factory lines where the principle is to standardise everything to the extent that all people are performing small routine tasks and are essentially interchangeable, they moved towards the idea of having 'thinking people'. People who are able to think for themselves, solve problems, be proactive, be flexible, take appropriate actions, make decisions. As per
Lean Principle #2 - Create Knowledge
Another way to go faster, as I eluded to earlier, is to
keep things simple. Keep the requirements simple. Keep the technical solution simple. Find the easiest way to meet the users' goals. Don't over-engineer. Don't spend too long considering future requirements that may never materialise. Get something simple to market and build on it based on real customer feedback.
Work as a team. Really as a team, helping each other to make sure that the team achieves it's objectives, whatever it takes. Be flexible in the tasks you are willing to pick up. When you commit to something, do everything in your power to deliver on it.
The first principle of Lean was
. Sometimes it's easier said than done, but this is clearly another way to deliver faster.
And last but not least, in order to go faster, you really need to
build quality in
. A team that suffers from lots of bug fixing, or lots of breakages as changing one area affects another, or lots of post-delivery remediation work, can never go as fast as a team that is delivering good quality in the first place.