Ensure success with agile - Three critical precepts
Posted on behalf of Surya Prakash K., SVP - Business IT Services Head - Retail, CPG, Logistics & Life Sciences
The Northern Sea Route helps ships from China reach Germany 2 weeks faster than the traditional Suez Canal route. However, speed (timely delivery) and quality (no loss of original scope) is only guaranteed if the weather's great and the timing is good, which is only for 3 months a year. Agile projects are sometimes this way - they succeed only in fair weather (i.e. business and IT collaborate very well on a consistent basis) and the timing is good (i.e. if the project size is small, one gets great programmers and program leaders).
Today, Agile is a way of life adopted in many new development projects. So doing it only when everything's all right, is not an option. Get a lot out, faster is required at all times. As companies embark on large agile projects, here are a few things to keep in mind.
Scale is not possible without systemically integrating business & IT throught collaborative platforms, and without leveraging distributed delivery
The larger projects/programs inevitably have a lot of things to keep track of. Issues pop up in ongoing work, new features are unclearly defined causing more iterations, things in production give rise to new changes - the number of things to keep track of, on a daily basis is high. Business has to work closely with IT, and track and close impediments. Architects have to regularly remove bottlenecks, programmers have to be moving forward constantly.
A lack of systemic integrated models that facilitate smooth collaboration between Business - IT - Engineering, will clog the supply chain.
Supply chains can also get clogged by the ability (or lack of it) to get scale in people. Distributed delivery brings in scale, but increases complexity and collaboration needs. Offshore locations bring in scale, but how many projects do distributed development properly. But if one can do it well, the cost benefits are quite handy.
Success in large agile projects requires seamless virtual collaboration that enables scale and distributed development. Success also means usage of tools and ready to use custom components that improve productivity. Cost benefits without forsaking the very principles of agile, is useful.
Don't slow down for quality control, but align quality control to the agile way to ensure quality
"Let's go agile" - this does not mean that one gets to roll out crappy stuff. Quality control and testing is as important in agile programs as in waterfall programs. Traditional testing though, often means meticulous planning, and uses a prolonged pit-stop phase. Ask anyone who runs an agile program; they don't want anything to stop. Multiply the complexities of parallel development that happens in agile and you have a quality disaster waiting - Features often need other features to be ready & ready data before they can even pass basic quality checks.
Agile quality way - this requires process map driven test planning, test case generation, and service virtualization to test features while using stubs for dependencies. These are new ideas being tried for quality control in agile programs.
Providers though need to bring in the quality control maturity. They need to bring in tool sets to enable application process map to test case generation, service virtualization kits and the like to enable client IT organizations and businesses breathe easy on quality control
Agile development ain't agile delivery
Huff and puff, get your features built, but wait at the last mile - infrastructure not ready! Not unnatural in agile projects. Environment changes - setup/dismantle/setup - are still traditionally managed. Releases into production are strictly controlled by change control boards. Infrastructure management is at times outsourced to external service providers and SLAs and operating procedures were set up years ago.
In Agile, value realization is important. Value realization is not possible until the "value developed" hits production. This requires one to incorporate frequent releases, speedy test environments and fast releases to production. It is not that agile projects reduce overall time, it's just that the features with higher value get deployed first and feedback from production is used to modulate future sprints. Agile programs often use a term "Demand to Deploy" to mean - choose right (better value) demand upfront and Deploy it fast.
Without the infrastructure teams playing ball, Demand 2 Deploy is often a pipedream.
Saying all these is easy. Bringing in a "show and tell" to complement the "say and tell" is important when one writes blogs like these :)
At Infosys, we have developed a collaborative platform and set of processes and toolkits that address these critical issues I have talked about. There is also additional ready to use domain and technology components for scenarios like ecommerce, digital marketing, talent management - that help add necessary acceleration at high quality - to these time-strapped programs.
Several of our clients have gained-
- A leading US fashion retailer grew their revenue while their release cycle reduced from 3 months to 3 weeks. More features went out and helped them cash in a new promotion trend.
- A leading UK retailer got out 40 new features in 45 days for their e-commerce platform that helped created a marketplace for various sellers.
- A leading telecom and information service provider in Australia reduced Infrastructure provisioning from 10 weeks to 20 minutes and became more responsive to changing business demands.
How did we manage all of these? Keep watching this space for more...