Minimum Viable Process
If I mention the word “agile” to you, a couple of rituals common to agile methodologies probably come to mind. Daily stand-ups and iteration planning probably top the list, and you probably think of other agile concepts like user stories and estimating their complexity with an arbitrary number of points.
But if you read the original Agile Manifesto you’ll find nothing about user stories, or points, or daily standups, or backlog grooming, or estimation. In fact, there is only one specific recurring ritual that is described in the principles behind the Agile Manifesto:
At regular intervals, the team reflects on how
to become more effective then tunes and adjusts
its behavior accordingly.
This is describing a retrospective, and while retrospectives are often a component of Agile methodologies, I’ve found them to get the least love. Many teams don’t even have them. When times get tough and a team needs to cut some meetings out of the schedule, the retro is often the first one on the chopping block.
And what a shame! The retro is the purest embodiment of the spirit of being an agile team.
The retro is your team’s opportunity to reflect on its work and iterate on the process of making things. It’s a regular opportunity for your team to get ahead of any nagging feelings people are having that something could be better, and it’s a regular opportunity to recognize what’s working well.
In fact, if I was running a team that is new to following Agile principles, the only meeting I would schedule is a weekly retro, and I’d get the team accustomed to a way to effectively conduct one. As long as the retro is working effectively and everybody is openly sharing feedback, we’ll uncover any course corrections we need to make as a team, and if there is a need for other recurring meetings throughout our sprints, we will identify them.
There is no particular right or wrong way to conduct a retro, but it’s helpful to foster an environment where people feel they can speak candidly, but also feel psychologically safe. At Carbon Five, we conduct retros using stickies (and if you can’t be in the same room for the retro, we built Stickies.io to provide you with a virtual stickies board). Every participant spends the first five minutes or so filling out stickies that begin with either “I like” or “I wish.” Afterward, everyone takes turns reading their stickies out loud, and we put them on the wall. After everyone has shared their thoughts, we group similar feedback together and begin discussing how we might iterate, and we produce a series of stickies describing how the team will change things going forward, and these stickies begin with the phrase “We will.”
On teams I’ve worked on we tend to discover that we are most satisfied on weeks where most of our stories were small and incremental, allowing developers to finish and ship them quickly, and conversely, we tend to be dissatisfied with stories that are vague and large in scope, so as a result, we make a habit to try to make user stories that are as granular as possible. I’ve had sprints where a lot of developers felt that it was difficult to deliver stories because of intermittent failures and slow build times on the CI server, which led to us investing more time in making the tests work more consistently and upgrading our CI server plan. By having our clients (or if you are not working in a consulting environment, your business stakeholders) participating in the retro, we can keep an eye on how they’re feeling, and get ahead of anything they are concerned or dissatisfied about.
