I recently had a podcast with Ram of #FoundersGyan, where I spoke about the reasoning on why I think Agile would be good for delivery especially in startup arena. I am trying to capture the excerpts. I used the 5Y technique to reason out why I think so.
What is 5 Y technique/Analysis? – It is a mgmt technique to understand the root cause and to explore the cause and effect of a particular problem. We should be able to ask Why? 5 times in an iterative and interrogative way to to determine root cause.
My effort here is to try applying same over Agile for Delivery…
The principle of Agile is to focus on
- Individuals and Interactions over processes and tools,
- Working software over comprehensive documentation,
- Customer Collaboration over Contract negotiation,
- Responding to change than following a plan.
Why shud we stress individuals and interactions over processes and tools? – At the end of the day execution is been done by the people on the ground only, so it relies and recommends directly on the trust in the team, i.e. individuals and the way they interact. The team should figure out what to be done, how to be do and the finally do it as well. The teams themselves interact, identify the items getting in their way, identify the scope and they are responsible to resolve difficulties that is in their scope. They also interact out of their organization to resolve dependencies. They are not limited to just their desk, they get the complete picture and are independent. The take complete ownership, get things Done. Undermining any responsibility will lead to trouble. In short, team has to be self organised.
Why shud we choose working software over comprehensive documentation? – Earlier models like waterfall, completes one phase after the other in SDLC, which takes you through issues like the requirement given at the time when requirement phase was done, does not hold good during delivery. Scrum requires a finished, working product as a primary result of every Sprint. The team works with the Product Owner to set the definition of DONE and works towards the same. End of the sprint, a working product will be available that will allow organization/mgmt to guide the project to success. Sometimes, even can validate it with the customer.
Why shud we collaborate with customer? – Mostly the product owner/manager will be the person who acts as the primary point of contact and he liaisons with actual end users. The product owner comes up with epics/stories which he collects from roadshows, customer interactions and field issues and works collaboratively with the team to understand what needs to be DONE. He is the prime focus and he determines the most valuable things to do, to ensure the product has highest value at every point of time. The Product Owner has to build a rich collaboration with the team. At the end of every sprint, the product owner watches the demo of the product (finished state) and approves.
Why shud we not follow the plan? – At the end of the day the customer wants his problems to be resolved. We may have a beautiful plan for execution, but then if the requirement itself changes no point following it blindly. We should have provisions to adapt to change.
Why shud we respond to change? – Scrum is designed beautifully to ensure all Information is available to access to everyone. With this information they should be able to easily take decisions about the project, by seeing a live product increment sprint after sprint. There is backlogs, storypoints , progress everything that can be measured day to day, sprint by sprint. Problems and concerns are discussed and dealt openly and immediately with retrospectives being conducted at every demo.
Take Away : Agile is not a success mantra, it just brings the problems on the table with data to back it up. It is upto the management/teams to understand, retrospect, take the feedback and correct it.
It will WORK WELL for “teams that are open to inspect and adapt”, it does not for those WHO DO NOT!!!