Occupy Scrum: How Sprint Retrospectives Brought us to Agile Nirvana

Loomio is a tool made by a ragtag bunch that grew out of the Occupy movement, anarchist and activist circles, free-thinking musicians and artists, open-source advocates, techno-utopians, social entrepreneurs, and collective community builders. We’re a worker-owned cooperative company with no bosses. As you might expect, we aren’t predisposed to enjoy being told what to do, having role titles, or submitting to strict rules.

Like most developers, we’d heard of the Agile Method of Software Development, and we picked up bits and pieces gleaned from blogs or conversations. But we still resisted any kind of “oppressive” restrictions on our freedom.

We just didn’t get it – the Agile Manifesto isn’t so different from what you might see in an Occupy manifesto. It says right in the Scrum Guide that Scrum teams are “self-organizing”. We were hyper-conscious of process in our general meetings right from the start, but it took us a lot of trial and error, and practice, to apply the same rigour to process in our workflow.

Turns out, Scrum is what freed us, but only when we submitted to it fully.

Embracing Scrum In Its Entirety – It Ain’t Easy!

Because we’re stubborn, we had to learn the hard way, by making mistakes. More than a few times, just as we thought something we were building was nearing completion we’d realise it was not quite right (or even very wrong). Or things would take way longer than we thought. Or people would get frustrated at the way the team was working.

We’d have informal conversations about process improvements, or just carry on building until it worked. Tasks could continue indefinitely. We had no way of tracking our performance, and as the team and project grew, we were finding it increasingly difficult to make changes. Sometimes we felt like the app was locking us in to a particular trajectory against our will.

Loomio co-founder and lead dev Jon was frustrated by this dynamic but didn’t quite know how to change it. One day, he stumbled across a video by Ken Schwaber, and was inspired to study up hard.

Jon asked for team buy-in. He asked for permission to be an asshole about it until we actually got whipped into shape and started following Scrum for real. We might be a bunch of wilful individualists, but we wouldn’t be here if we weren’t prepared to do what’s best for the project first and foremost, and we saw that this was it. All consented to some much-needed bossing around.

It certainly wasn’t easy at first, and Jon had to continually repeat the phrase “let’s stick to the process” until he was blue in the face. The main thing that Jon asked of the team, and the main take away that he got from Ken’s talk, was this: to get full value from Scrum, you must adopt it entirely, following it to the rule.

Retrospectives are the Most Important Part of Scrum

The real magic of Scrum is not just the Scrum techniques themselves, it’s that continuous process improvement is built in. You can’t do that without retrospectives.

Retrospectives are a formalised way for the the team to reflect on the sprint that just finished and discuss the good and the bad of it. It’s about resolving conflicts or misunderstandings, and celebrating the good things that happened during the sprint, with the purpose of making process improvements for the team to adopt in the next sprint.

Following Scrum process closely is hard. We found that we needed plenty of practice to get a rhythm as a team. To get good at it, we had to learn together through practice, reflection, and communication.

We developers like to think we can teach ourselves anything by reading about it on the internet. But there are some things that you just don’t comprehend without stepping out of your comfort zone, actually putting it into practice, and making some mistakes you can learn from. You cannot really understand retrospectives by reading about them on the internet (yes, we are aware of the irony that you are reading about this on the internet – go out and try it for real!).

When you’ve got a lot of work you want to get done, or you’re already sure your opinion about something is correct, facilitated processes can feel like they are slowing you down. But our experience has taught us that in the long term, they absolutely pay off.

“I usually approach any meeting with a certain degree of trepidation, as it feels like it is getting in the way of real work. However giving the retrospective the time it needs has paid off time and time again. The simple exercises you participate in as a team brings out how everyone is feeling about the state of the project. You can’t help but address the major issues in the room. Having timeboxed conversations in order of priority and finding process improvements to address issues is the therapy that the team needs. Despite initial resistance, I regularly come away from a retrospective with renewed faith in the team.” – Rob (crotchety old Loomio dev)

Sometimes retrospectives are a place for challenging conversations and confronting issues you might otherwise avoid. It’s a place for anyone in the team to say what’s bothering them. These frustrations, which might otherwise fester, can be turned into great process improvements when facilitated properly. When you have great facilitation, the group benefits from shared understanding and protocols, skill at helping everyone communicate effectively, and tools for handling conflict.

Here are some facilitation techniques that have worked for us:

• Visual: drawing progress lines, mood graphs, walls of post-it notes, and writing up the agenda of timeboxed conversations clearly

• Verbal: consciously deciding on speaking protocols depending on time constraints and content, to empower people with varying communication styles. Some examples are a round (going in a circle, everyone speaks once), popcorn-style (people ‘pop’ whenever they feel they have something to say), a stack (people add their names to a list and they are called in order), or other agreed protocol (such as not speaking again until two others have spoken)

• Cultural: personal circumstances, stress and emotions are legitimate dimensions to how people work. We start meetings with a check-in round focused on personal wellbeing. We make it OK to mention issues related to mental health, family obligations, gender dynamics – whatever needs to be acknowledged. We explicitly celebrate people taking time off to rejuvenate or study new skills.

Process Improvement in Practice: Experiment, Learn, Repeat

Here’s an example of how one of our processes improved through formal retrospectives.

When we first started, we deployed code as soon as whoever was working on it and whoever else happened to be around thought it was ready. This worked at first when Jon was the only developer on the team, but as the team grew it meant that we were missing certain necessary checks. Just small stuff like making sure the UX was intelligible, and that what we’d built was actually responding to the original customer need we’d set out to address (!).

During one of our retrospectives, we arrived at the conclusion that we needed a sign-off process. In traditional Scrum, the Product Owner signs everything off, so we decided to try that. This wasn’t the final answer, though, because we found that it wasn’t always clear what criteria exactly the Product Owner should be using. We tried giving the Product Owner a check-list of criteria, but it was time consuming for them to have to chase different people around to see if certain things were done. Also the Product Owner isn’t a code or design expert, so things were still getting missed.

Next we experimented with what we called ‘sign-off parties' – get everyone together at the end of the sprint and do it all at once. We had a senior designer as Design Owner and a senior developer as Code Owner, and everything could be verified at once without the Product Owner needing to track people down. The problem with sign-off parties was that, inevitably, problems would be discovered (a good thing) but we’d find ourselves at the end of the sprint suddenly finding out we had a bunch more work to do (a bad thing). This bottlenecking caused every single sprint to start going over.

Finally we arrived at our current iteration of the process – rolling sign-off during the sprint. Now, when someone thinks their work is ready, they send it for sign-off by the Design Owner and Code Owner. There’s a checklist to make sure it’s been user tested, QA’ed, and cross-browser compatible. By the time it finally gets to the Product Owner for sign-off, they can see that all this has been done and don’t need to chase anyone around to make sure. Deployments can happen continuously and to a high quality standard, and doing this work is incorporated into the sprint itself, allowing us to actually finish what we set out to complete by the time the sprint is up.

It took three iterations of continuous improvement to get to where we are. Of course, our process around sign-off will continue to change as we grow, but we’re confident it will always change for the better because we’ve got rock-solid retrospectives.

Roles are Key, Even if You Are All in it Together as Equals

We are a highly collaborative team making a tool for collective decision-making, and a bootstrapping startup without the resources to employ people in Scrum roles who aren’t also on the Product Team. This creates an inherent tension with the traditional Scrum roles, which call for separation from the dev team, and hierarchical authority to make decisions.

We’ve worked through this tension by learning that Scrum roles are about personas and archetypes, not the individuals who happen to be in them. In fact, many people think that cross-functional managers are ideal for Agile, and at Loomio, every member is a manager. Thinking about the roles this way has helped us optimize them quite separate to anyone’s personal ego.

We encourage all our team members to learn about the roles and support them upskilling to the point they can take them on. We rotate people through roles periodically, to share the load and the learning, and to prevent anyone from getting too dictatorial. Going out to get external training is a great way to import Agile wisdom and culture into these roles.

We’re a cooperative company, meaning we’re all business owners, so the ‘business team’ serves everyone, and the traditional Agile ‘product owner’ has had to be adapted to our context, making it a highly collaborative role interpreting a wide set of priorities into a coherent work plan.

It’s up to the Scrum Master to facilitate the retrospectives. Once Jon had the process up and running, he handed the scrum master mask onto Mix – having a flair for the dramatic, he literally wears a black zorro mask when acting as the scrum master, so that he can take off the mask and participate in discussions as himself as well, and people don’t confuse the two personas or take it personally when he invokes the powers of his role.

The Scrum Master maintains a structured framework for the two-hour retrospective meeting, and ensures everyone’s voice is heard. We get through complex discussion points with minimal friction. The scrum master needs permission from the group to be a bit of a stickler, e.g. setting time limits on conversation topics and reminding people to stick to the conversational protocols we’ve agreed to.

Since we all own the business, we aren’t working for a paying client. So the idea of having a single product owner making the final decision on what features do and do not get built took a bit of getting used to. But it’s a very essential role to include and respect, to make sure we’re setting the right priorities and responding to feedback, user testing, and business circumstances.

Our current product owner, Rich, took over from Ben when he took off to talk about Loomio around the world. Rich stays in continuous contact with the user support, research, design, development and business teams, synthesizing all of that input into a coherent set of priorities for each sprint. He’s conceived his role as a communicator across different parts of the project, and a synthesizer of all the inputs.

What We’ve Learned:

• Adopt the whole scrum process
  AKA: “Either scrum or don’t scrum. Don’t scrum haphazardly.” Take the time to learn it for real and get good at it, especially retrospectives. Attend a few external classes. Share the job of adopting scrum amongst your team. We owe a lot to the workshops held by Boost Media here in Wellington, who hold classes on many aspects of Scrum.

• Focus on writing good stories
  We’ve learned the importance of writing better user stories, specifying clearly the who, what, and why of each feature. When you’re writing good stories and running good retrospectives, you can really start to feel the self-organising, self-improving nature of Scrum.

• Make your sprints work for you
  Once you learn the rules, then you can start learning to bend them a bit. We started with standard weekly sprints, but found that the overhead of sprint planning and running a good retrospective meant that we didn’t have enough time during the sprint for all of the work we had to do. We’ve since moved to a 2 week sprint and made a strategic decision to start on Wednesdays rather than Mondays. This means we aren’t pressured to deploy on a Friday – meaning we’re no longer enslaved to the project all weekend worrying about bugs and fixes and things. Only through following the process strictly can you control variables enough to effectively experiment.

• Track velocity
  Our mentor and code-guru Craig Ambrose recommended “velocity tracking”, a measure of user-facing value delivered per week. We dropped the ultra-flexible Trello in favor of the highly-opinionated Pivotal Tracker, with velocity tracking built in. Estimation is something that we naturally get all fussed about as developers. It’s hard. The best estimations involve all members of the team looking at well documented stories, and it rapidly highlights if a story isn’t clear. Estimating shows differences in the understanding of each story, allowing us to catch it much earlier. As we improve at this, having a good idea of task sizes helps us have an increasingly accurate view of what we can achieve in the short and long term.

• Visualise progress
  We’ve experimented with visualising the sprint on a whiteboard. This helps us check in on our progress during daily standups, increases the visibility of stagnant tasks, and helps us see who is available for pair coding. In the example at the stop of this post, we were able to note how we slipped up on sticking to the stories in the sprint and made process improvements based on that.

Do you want us to work for you?

All this could be yours. We’ve got capacity over the next few months to work on your project. Join us in Agile nirvana!