So, you want to reap the benefits of Agile for rapid development? You’ve come to the right place. I’m going to describe a lightweight approach using Scrum that works super well. This article is the nutshell outline. Following articles will go deeper into this Scrum implementation.
Preface
I attribute all of what I know of Scrum to my boss, coach, friend and colleague, Gint Grabauskas. Gint has a long track record of servant leadership and agile transformations and has helped shape our current department of 6+ major products over the last 8 months, with a proven style of Scrum that works better than I’ve seen in my career.
I’ll share some of his lessons from my perspective in this series of Agile Scrum articles. There may be deviance from what Gint would teach, as this is my interpretation. This isn’t textbook Scrum, but rather from practice doing it. I’ve been practicing rapid development agile software development for more than 12 years, however, this Scrum process was learned in practice over the last 8 months.
You may use these lessons as a guide for transforming your own work practices. Have confidence this method is being used with great success in large software development shops. It may work well for other industries as well. I’ve even heard of folks using Scrum at home for improvement projects.
Agile Scrum, Part 1, Nutshell
In a nutshell, a Scrum team performs work in a series of Sprints. Each Sprint is short, either one or two weeks.
Before the sprint is Backlog Grooming and Sprint Planning. Backlog Grooming elaborates story Acceptance Criteria and prioritizes the stories on the Backlog. Sprint Planning defines the tasks needed in each story to satisfy the Acceptance Criteria.
During the Sprint, the team meets for a short Daily Standup to discuss what’s been done, what’s next and any problems, if any.
At the end of each Sprint, there is a Demo, where the team shows off accomplishments of the Sprint.
Finally, there is a Retrospective, where the team discusses what went well, what went poorly, and defines 1 to 3 SMART goals for the next Sprint.
The sum of the story points completed in a Sprint is the velocity. The average velocity of the last 4 sprints is the Established Velocity. The Established Velocity may be applied to the Backlog to estimate release dates.
When the Backlog is Groomed, meaning all the stories are sized and prioritized, answering when will Feature X be done is simple math: (Prerequisite points / Established Velocity) * Sprint Length.
Scrum is a cadence that creates a predictable stream of value from the team. During the Sprint, stick to the plan. The sprint is sacred, don’t go rogue. If you want to do things differently in the process, use the retrospective to voice concerns. Scrum is very rigid during the Sprint, then very flexible in the transition. Since Agile values adapting to change over sticking to the plan, shorter Sprints are preferred.
In the next article, will define the 3 roles in Scrum: Product Owner, Scrum Master and Contributor.