On a cold Sunday evening in February 2001, and on the way back home from a day-long trek in the Grand Canyon with friends, our discussions revolved around a recent project I had been working on. The project was faced with a not so uncommon situation – customers wanted to see the application running before they could decide how exactly it was supposed to run. In a group that included software developers with backgrounds ranging from device automation to OS programming to offshore outsourcing, this was a timely and engaging topic with everyone.
On that same weekend, five hundred miles north in Snowbird, UT, seventeen experts representing various development methodologies, had gathered to identify common guiding principles that would help developers deal with these such common, real-world problems.
In what was to be known as Agile – a new way of developing software, this collection of independent development methodologies emphasize on people, communication, delivering working software and responding to change.
So does Agile Work?
It’s been more than 12 years since these principles known as the Agile Manifesto, was published. Independent groups have published evidence of the effectiveness of Agile methods.
As per the statistics published by the Standish Group (2012), the success rate of Agile projects is at 42% compared to 14% for traditional Waterfall projects.
Truth be told, any particular way of delivering software – Agile delivery or otherwise – cannot necessarily guarantee project success. Agile was never claimed to be the panacea. There are well-publicized examples of failures of Agile projects.
What are the Challenges?
First things first. Organizational culture and executive support play an important role. Principles behind the Agile Manifesto highlight the need for self-organizing teams. These teams are expected to take decisions. When Agile teams change the way the software is delivered, it affects the way the organizations do business. Without executive support, this cannot be achieved.
The Agile Manifesto favours delivery of working software over comprehensive documentation. There is an inherent emphasis on a relation between developers and organizations that is based on trust, integrity, and transparency. It may not sound like a huge shift, but is still a significant challenge for many organizations.
It is crucial that the team is trained and aware of Agile concepts and has the necessary tools needed to perform. A team of skilled and experienced developers is more capable of taking decisions, compared to a less skilled team.
And finally, customer commitment. Agile delivery values business user collaboration and direct interaction instead of intermittent communication at fixed points in the life cycle. Effective business involvement reduces the risk of delivered features not meeting customer requirements. (Gartner, Agile Success Factors, David Norton & Matthew Hotle).
So, how can I go Agile?
More accurate question is, which Agile delivery methodology should I choose for my project?
Though all Agile methodologies recommend iterative and incremental delivery of software, the differences lie in the way each methodology is executed and the artifacts produced.
- Scrum: Focuses on self-organizing teams and client-driven adaptive planning. Prioritizes delivering working software in no more than 30 days, over documentation.
- Extreme Programming(XP): Keeps things simple. Focuses on the continuous implementation of best practices such as code reviews (pair programming), refactoring, ongoing testing, and continuous integration.
- Feature Driven Development (FDD): Breaks down the delivery of a larger software by features. Simple processes, short iteration cycles. Suitable for predictable evolution.
- Kanban: Based on Toyota’s just-in-time (JIT) production system. Incredibly simple and still incredibly powerful Kanban boards. Focuses on eliminating bottlenecks.
- Lean Development: Focuses on providing value for money. Recommends avoiding unnecessary errors, amplifying learning, deciding as late as possible and delivering as early as possible.
- DSDM: Developed from a business perspective. Strong emphasis on project management. Plans evolve based on increments.
Here is a side-by-side comparison of various Agile methods based on key parameters.
|People vs. Process orientation||People oriented||People oriented||Process oriented||Process oriented||Process oriented||Process oriented|
|Distributed Teams||Not Supported||Can be supported||Can be supported||Can be supported||Not supported||Not supported|
|Recommended team size||Atleast 2||About 7||10 – 50||-||-||About 7|
|Iteration length||2/3 weeks||30 days||2 weeks||1 week||-||-|
|Customer Involvement||High (daily)||Medium (Monthly)||Low (as needed)||Low (as needed)||Low (as needed)||High (Daily to weekly)|
|Handled Multiple Customers||No||Yes||Yes||-||Yes||No|
|Risk Mitigation Level||Medium||High||Medium||Medium||Medium||High|
|Supports High Requirement Volatility||Yes||Yes||Yes||-||Yes||No|
|Pros||Simple. Relies on communication.||Time boxed iterations. Relies on communication.||Strong modelling features. Guidelines for distributed teams.||Emphasizes on visualizing work progress & eliminating bottlenecks||Focuses on ROI.||Highly structured.|
|Cons||Lacks documentation. Measurements and transitions can be a problem.||Lacks documentation. Measurements and transitions can be a problem.||Requires skilled modelers||Hard to track dependencies. Can be prone delays.||Doesn’t support frequent changes to requirements very well.||May tend towards bureaucracy.|
Agile does offer the flexibility to combine multiple methods and derive your own version. Scrum and Kanban, for example, go together like chocolate and peanut butter, so they say.
We would love to hear about your experiences in implementing Agile in your organization. And if you’re looking for a team to build an enterprise application using Agile, please start a conversation with us.