Agile/Scrum from the trenches

Since around 2011 most of the teams I worked with have followed some kind of "Agile" methodology. An year ago I joined the IT infrastructure department of an enterprise, which I found to be late to the party of Agile and Devops. One of the organizational goals was to set up Agile scrum and coach team members on the "new" methodology, in which I had a hand too as the scrum master. Below are a few practical observations based on experience.

Establish baseline knowledge

One challenge the team doesn’t need to deal with when starting with scrum is team members who lack a baseline knowledge of scrum framework. Send all team members to a scrum training, if they require it. Send the Product Owner to a PO training if he hasn't followed one. Additionally, ensure the person serving as PO is able to set priorities to the product or service, and has a wider organisational view.

Time-box everything

The only way a scrum event (refinement/review/standup/...) doesn't become a chore is when the team members derive value out of it. Too often these meetings tend to drift into one-sided discussions, rendering attendees thinking "what am I doing here". Time-boxing can be an effective tool to control this drift. Time-box discussions to 5 or 10 minute windows and set an alarm on your phone or browser. When the alarm goes off, let the team vote (with a simple thumbs up/down) whether to continue the discussion for another 5 minutes.

Story readiness

One of the very useful checklists we developed is the "Definition of ready". Anyone can create a story on the product backlog, but it is the ultimate responsibility of the PO to take those stories in. The PO sets priorities, and makes use of the simple "Definition of ready" checklist before pushing the story into the "Ready-to-Poker" status (during what we call "grooming" sessions). Thus, when the team assembles for the refinement session, it has all the information it needs to poker stories effectively. You might have guessed (rightly) we used JIRA.

Sprint goals

One of the challenges we had to deal with is defining what our sprint goals are. Of course the PO has to make a call here, and this must align with longer running epics or themes. In practice, setting limited achievable goals per sprint has been elusive as the team tends to work on multiple epics at the same time with more or less similar priorities. A particularly tough one is how to handle "unexpected" work: create adhoc stories mid-sprint, or handle them in a planned "bucket"?

Daily scrum & Retrospectives

It is safe to say the success of a scrum effort depends on the sanctity of these two particular events. Proper daily scrums forge a sense of team as nothing else. Make sure all necessities for a daily scrum like fixed space, time, visual props, etc are arranged. Keep the communication crisp, and natural (the SM should take backseat). The whole idea around scrum is about inspect and adapt. This is made possibly by a frank and free retrospective session. Remember that this is the time to talk about how things are going with the team, and not anything technical or backlog-related. Try to get action points out of the session, each assigned to someone. Again, time-boxing (see above) is essential in both these events.

In conclusion, scrum should help create a team out of individuals, with focus on the product/service it delivers. However, a lot depends on the individuals playing their parts, be it the SM, PO or team member. The key is not to do scrum as a goal unto itself, but as a means to help the team deliver its goals.