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!