Poster image for this article
Source: Rodrigo Pereira on Unsplash.com

Tuning and Adjusting Our Agile Processes

Share this post:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Principles behind the Agile Manifesto

The CTL development team has committed to refining our processes this year. Our goal is to craft a more efficient, repeatable design and development approach that adheres to agile values and principles, and also boosts collaboration and transparency.

The Center has long thought deeply about how we do our work. We were guided first by the Design Research methodology, which married “digital technologies with pedagogical theory and practice.” This iterative methodology ensured that new projects align with our teaching and learning mission, but lacked details on how the design and development work were completed. We borrowed elements from Gov.UK’s Design Principles to fill in those gaps. But even then, we’ve still felt the need for a clearer implementation path.

Our Associate Director Shashi Yellambhatla started us with the Scrum methodology early last year. We warmed up with stand-up meetings and two-week sprints. Daily standups started in the summer, along with regular sprint review meetings. The Scrum introduction coincided with our tooling shift to Jira.

In fall 2019, we were ready to reflect and consider how to deepen our practice. We decided to engage in short readings and discussions on Agile in general, and Scrum in particular. During these discussions, we all agreed that the principles expressed in the Agile Manifesto reflect our core values. The stand-up meetings were mostly okay, and the sprint review meetings gave us a chance to demonstrate our work. But, we also pointed out rough spots:

  • Our team is small, and we are each working on at least two projects at a time. Scrum is organized around individual project teams. How do we tune this methodology so we can plan and prioritize work across projects?

  • Planning was taking place at the individual level. Our multiple project backlogs were united, but each project team was entering tasks in different ways, or not at all. What was the “right” way to go from user stories to tasks? How could we integrate the project teams into this planning step?

  • Jira felt awkward. We weren’t sure how to use epics, tasks, subtasks, components and other organization elements to reflect our work. We all expressed frustration with the interface, and the inability to see a solid view of our work in progress.

What to do? Inspired by this training video from Don McGreal, we decided to take a break from Jira, and paper-prototype our planning and task creation process.

Our project manager Meesha Meksin and I took the the job of collecting a set of user stories to prepare a sprint, and handwriting those stories on sticky notes. In the first unified planning meeting, team members grabbed their user stories and wrote out their tasks. That first planning session went well, and took less time than the old meetings.

A few quick reflections:

  • The process of backlog grooming and curating a set of user stories for a sprint actually doesn’t take long, two to three hours at the most. I was holding back on doing this as I felt that all the project backlogs needed a perfect set of user stories. We actually only need a few good stories that encompass the prioritized work for the upcoming sprint.

  • The unified planning meeting organically creates a space for team members to chat about how work would get done.

  • We need to more clearly define what a “user story” is, e.g. a small bit of functionality written in English, without too much implementation language. Ideally, Meesha and I will begin working with project teams to have a few user stories prioritized, estimated and ready to go into a sprint.

  • Handwriting our tasks on sticky notes has a nice feel to it. Developers took their tasks back to their desks and stuck them on the wall for easy reference. We’ll definitely get back to tracking in Jira at some point, but for now, going old school feels right.

We’ve clearly just started this experiment. We haven’t even completed a sprint close yet, but will soon. Stay tuned…I’ll add another post to describe where we end up.

End of this article.

Printed from: https://compiled.ctl.columbia.edu/articles/practicing-agility/