Published on March 03, 2014
As ‘Agile’ being a trendy project execution methodology now a days and a high volume information available on internet, I don’t want to do any detailing on ‘Agile Project Execution’ methodology here, but want to conclude two most frequently asked questions while thinking about adopting Agile methodology in your next project execution.
1. When is Agile the most suitable?
2. How should be the Agile team?
When is Agile the most suitable?
Software development is a complex process where inputs and outputs are not precisely known. Highly preferred method when requirement is complex or is inaccurate.
When you think ‘Planning is important and not the plan as you will not able to plan your entire project but detailed planning per sprint (weekly/bi-weekly etc…) will be very accurate.
Want to maintain X % work done – 100% usable ratio. Meaning – Small slices of work delivered at predefined period of time and this slice is a workable product.
Want to reduce Time to Market. Rather than waiting till the entire product gets developed and final surprise is delivered to the product owner at last; reach out to the product owner with small shippable deliverable to demonstrate the progress and revisit the scope or correct mistakes at early stage of the project.
Want to work in parallel. BA, Development team, QA team – all can work for the batch together. This will increase individual team members’ overall allocation than standard waterfall cycle execution process but will eliminate last minute surprises, reduce product failure risk ratio and will give very clear visibility of the product to all project stakeholders.
Want to build the system gradually. A slow but steady progress will ensure less rework, more re-usability and higher customer satisfaction ratio.
Welcome changes in requirement – even at later stage of development. The entire team – the product owner, BA, development and QA teams – should have maturity to welcome, discuss and accept changes in the benefit of the product success.
Requirement is complex and you think Estimates are Guestimates and they may change. Especially when the scope is not too short and straightforward, achieving minute level clarity is very hard at early stage of requirement analysis. Maximum chances of estimated efforts getting varied with the actual ones at upper or lower side. This is highly expected scenario and should be considered in project planning.
Primary measure of progress by the QA team or stakeholders is a ‘Working Software’. This is a very positive point of Agile methodology. Apart from any other benchmarking, partially shippable, workable software is used to measure the progress. This mindset keeps entire project team of both the sides – product owners and product execution teams at the same balanced level.
How should be the Agile team?
Each member must be motivated individual contributor – The Best architectures, requirements, designs and quality emerge from self-organizing team. Here are the-must-have qualities of an ideal Agile team:
Able to identify shortest route of goal.
Believes more in frequent and face-to-face communication.
Able to do commitment based planning.
A team clearly knows their vision: ‘Team’s highest priority is to satisfy the customer through early and continuous delivery of valuable software.’
A team whom the management and stakeholders can trust and give them the environment and supporting they need.
That’s all for now from me. I will keep posting more interesting inputs on Agile periodically.
Till then, live Agile and do share your thoughts and experiences 🙂
