Kelly Waters is Web Technology Director for IPC Media, one of the UK's largest publishers of consumer magazines and web sites. Kelly has been in software development for about 25 years and is a well-known narrator of agile development principles and practices, as a result of his popular blog 'Agile Software Development Made Easy!' (www.agile-software-development.com). Kelly is a DZone MVB and is not an employee of DZone and has posted 40 posts at DZone. You can read more from them at their website. View Full User Profile
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
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
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 eliminate waste. 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.