Lessons Learnt from ACP

I have been managing software development projects for more than a decade. My initial projects were following classical waterfall model. Once the contract is signed, we kickoff the project, approach customers to elicit requirements and have a big-bang plan for the whole project spanning between 6-18 months. Then we do technical design, coding, unit testing, integration testing, system testing and acceptance testing and finally deliver the product to customer. Our typical touch-points with customer during the project are limited to sharing weekly progress report & performance review; at times, we share technical documents for their approval. Team would be casually working initially; towards the fag end of the project, we used to face big challenges in big-bang integration and several defects in system testing and acceptance testing; team would be extremely busy towards the end. For long, we got accustomed to this practice and were not thinking about any change.

 

Like many of you, I too got thrilled by new buzz word agile, the new method of software development. I could see many certifications on agile and decided to take global ACP (Agile Certified Practitioner) certification which is the only global certification targeted for agile project managers. After having some experience in agile projects and passing the ACP, I would like to share my major lessons learnt with agile compared with waterfall model.

 

Change is unchangeable hence be flexible for change. Waterfall is notorious for change resistant while agile welcomes change in requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Customer owns the product backlog (aka product requirements) ordered by value for team to implement in iterations. The customer can change the requirement until it is picked up for implementation. 

 

Waterfall delivers the product at the end, typically in 6-18 months, while agile produces small iterations of production quality software, typically every 2-4 weeks!, demonstrates to customer and adapts to the product feedback. Once the product has minimum marketable features, customer releases to market i.e., shorter time to market (TTM) yielding better return on investment (RoI)

 

In waterfall, Project manager cooks up the whole plan and get the work done by team. In agile, the team is self-managing i.e., the team does estimation, customer commitment, planning, scheduling, resource allocation, execution, monitoring, control and customer management!! Project manager role accordingly morphs to providing infrastructure, managing external stakeholders and removing team impediments. In short, we have empowered and motivated team. 

 

In waterfall, we spent huge amount of time & effort to build requirement, design, test documents; mostly antiquated. Agile believes Just Barely Good Enough (JBGE) documents i.e., the one line user story as requirement and code as living design document!! Instead, agile focusses on software engineering practices (like pair programming, test driven development, test automation, and continuous integration), collective code ownership, informal communication and continuous customer collaboration. 

 

Agile offers satisfaction to all stakeholders:

 

So why not we go for agile?

 

References:

 

1. Agile Manifesto:  http://agilemanifesto.org