If you have browsed through software jobs on a job portal recently, there would be little doubt that Indian software industry has decided to embrace Agile development processes with arms wide open. Software companies of all sizes are looking for professionals with Agile experience, and being a certified Agile professional (CSM, PMI, SAFe, etc.) is sure to strengthen your case.
When I heard about this Agile meetup in Delhi, it sounded like a good opportunity to share and learn from other people’s experience. And, to say the least, it was time well spent.
To give a flavour of things to someone new to Agile, Saket (our event host) offered to conduct the discussion in an agile format. He took inputs from participants on what they wanted to discuss, putting each topic on a separate sticky (post-it). Thus, our discussion backlog was formed – about ten stickies, or items. Based on voting from members, the items were prioritized, and put on a simple Kanban board. The entire discussion was time-boxed to about an hour – call it a ‘discussion sprint’ if you will. The last rule – before you must speak, please grab the ‘squeeze’ ball. 🙂
Why Agile – pros and cons?
Like most fresh conversations on Agile, our discussion started with the classic ‘waterfall vs agile’ debate. Why Agile? What is so wrong with waterfall –haven’t companies like Infosys, TCS and Wipro grown to their monster sizes (and made a fortune) feeding primarily on waterfall model? Is Agile practical enough to be used for all kinds of software projects?
Here are some reasons that were offered in favour of Agile:
- Waterfall model is too rigid to react effectively to uncertainties(or changes) in requirements. Agile, on the other hand, helps tackle uncertainties by first breaking the development effort into smaller batches called sprints, and then producing a newer version of the working software at the end of each such iteration.
- Agile promotes higher level of collaboration among team members, thereby improving the quality of effort and overall productivity of team.
- Agile strongly recommends frequent client interaction with development team, to validate development effort is headed in the right direction.
Despite the growing acceptance and demand of Agile,it faces some key challengesin India. Members shared some insights from their real world experience:
- Some clients are averse to the idea of Agile, for they feel they are too busy to commit to a high level of collaboration with the development team, on an ongoing basis.
- Few other clients are disturbed by the lack of project visibility over a long time horizon, longer than a few sprints. They like the old ‘waterfall’ visibility where they can predict the project status at the end of this quarter and the next, despite the margin of error.
- Some software companies had bad experience where their team-level tiffs (say between dev and QA) were exposed to the client.
- Some companies are having an unproductive experience with Agile adoption, simply because they have failed to learn the true essence of it. For example, waterfalling within a sprint is aprevalent anti-pattern.
The final word on where Agile could serve better came from Saket– Agile is an evidence-based empirical process that works best when there is uncertainty about ‘what’ and ‘how’:
- WHAT – Lack of clarity on the final solution
- HOW – Uncertainty on what technology or what design will work best for the desired solution
So, while ‘Waterfall’ model may still fit in well for a predictable project scenario, need for an adaptive approach will favour Agile methodology.
The difference between DOR, DOD and Acceptance Criteria?
These terms pertain to user stories in the sprint backlog – feature items picked up by the team for implementation in the current sprint.
Definition of Ready (DOR) – the criteria that a story must meet prior to being pulled into the upcoming iteration. It helps team avoid working on features that do not have clearly defined completion criteria, and may result into costly back-and-forth discussionsand rework.
Acceptance Criteria – the list of functional features that the software product must exhibit before a user story can be accepted.
Definition of Done (DOD) – It is a checklist of items that must be completed before a user story is considered “done” in all respects. Failure to meet these criteria by the end of a sprint normally implies that the story should not be counted toward that sprint’s velocity.Besides validation of Acceptance Criteria as one checklist item, it may include other items like project-wide NFRs (non-functional requirements), deployment conditions, etc.
What Metrics do we use to track and report Project Progress?
Though individual teams may indulge in more detailed reporting, Agile is pretty lean on project metrics recommendations. Following are some basic indicators to ascertain project status and progress:
- Sprint dashboard/whiteboard – It shows live status of the current sprint – what stories are done, in progress and not picked yet.
- Burn-down/Burn-up chart – The burn-down chart is a day-wise recording of how much work (in hours) is still pendingto be completed. Ideally, it should touch zero before the sprint ends. Burn-up, on the other hand, is day-wise tracking of story points completed by the team. Together, they are a good reflection on how well the team has performed in a given sprint.
- Product backlog – it holds a list of prioritized stories (both pending and done) and may provide some visibility on the project schedule based on the current velocity of the team.
- Velocity Graph – It gives a summary of team’s performance over time and helps in forecasting of project schedule.
That was more or less what we could manage to discuss in this short meeting, but no doubt it was worth the visit. The discussion was open and lively, people shared their experiences from the real world, and considering it was a meeting of mostly strangers, the group dynamics were great – thanks to expert moderation by Saket, and the ‘squeeze’ ball.
My special thanks to Saket, the organizer of Discuss Agile group, for making this session happen.
Waiting for my next meetup, may be on Scaling Agile… 🙂