Agile: A Fitness Event
7 July 2017
I started my Agile journey almost five years ago, when I was auditing Agile projects. As an internal auditor and a process consultant, my job was to identify noncompliances in the projects and suggest corrective actions based on the defined quality management system. Though I had good knowledge of ISO standards and Capability Maturity Model Integration, I was a total novice regarding Agile. It took me almost a week to accept the idea that the backlog isn’t something that is a pending liability for the project but a list of work requirements to be done in the future.
Fitness terminology as metaphors for Agile
I must say that the terms used in Agile looked interesting and even a bit funny compared to their meanings in the real world. Sprint, Scrum, velocity, daily stand-up, and burn-down charts are terms one would hear normally only in some sport or a fitness event. Then how would they fit into a software development framework? Though these words might seem like metaphors, they define the Agile way of working accurately.
Scrum comes from the word scrummage, used in rugby, which is a method of restarting a play after a minor infringement or when the ball has gone out of play. It involves players packing closely together to gain possession of the ball. This is aptly used for the daily status meetings, where the team gets into a close reunion at the start of every day to focus on what they have completed, what they will be targeting next, and what might be a hindrance in achieving their goal. No unnecessary attention is given to any long-term problem or issues, which are beyond the Scrum Team’s control.
Sprint is another term that qualifies well for this method. A 100-meter sprint is always interesting to watch, as within a short span of time we see the results. The athlete also gets faster satisfaction and quick feedback on his/her performance, quite similar to the faster delivery of software and early feedback from the client. The length of the track also remains the same, which makes it easier to set baselines and improve continuously. That’s why changes in the duration of a sprint are unacceptable.
In software delivery, we have one sprint after another, which is comparable to a relay race in which a team of four sprinters run a preset distance carrying a baton before passing it on to the next runner. It is important that the last sprinter complete the run well so that there is no time shortage burdening the next sprinter. Similarly, in delivery, the focus remains on completing what has been committed; otherwise, the pending work spills over to next sprint, causing an imbalance in the overall delivery, customer satisfaction, and employee morale.
I can’t skip mentioning burn-down charts. We generally hear the term burn when our fitness expert tells us that we need to burn x amount of calories to cut flab. But it’s always easier said than done. Just burning calories doesn’t help if we do not follow a proper diet and do the right exercises to achieve our goal. In Agile, we can always burn hours against the tasks or work done, but we get the value or story points only when the work is completed per our Definition of Done or the acceptance criteria.
Though these are the fundamental terms of Agile, and I am sure that you all are well versed in them, I thought that presenting them in this simpler way might provide some different insights.
I would appreciate your constructive comments. I am sure they will be motivational. Meanwhile, be fit, be Agile.
Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.
Current rating: 4 (2 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.