Overcoming Agile: Why we iterate our process often
We’ve started doing by-the-book Scrum a while back. We got ourselves a Scrum coach. We were doing ceremonies with beautifully crafted event descriptions. We were splitting stories to the last atom, discussing endlessly every story point given, planning each sprint for hours.
I’ve dove down a bottomless pool of Scrum literature to the point where I could quote Kenneth Rubin in the middle of the night, verbatim.
And it just wasn’t working.
Our sprints were messy affairs, with almost all of our stories shooting past sprint deadlines. That made our releases late and our merges created conflicts more often than not. Everything we were doing was as prescribed, but our output was nowhere near that what we were preached our input would generate.
So, we took a step back and gave it a deep thought. The solution was painfully obvious. If we were to instruct a front-end developer on a learning path, we’d advise them to first learn vanilla JavaScript and only then start looking at available frameworks. Yet, when it came to process, we were the ones doing it backwards — trying to implement one of the Agile (capital A) methodologies before we’ve mastered agile (lowercase a) principles.
We wanted to be up to the latest trends and believed too much in silver bullet promises of a System that we ended up blinded to simple fact: point of being agile isn’t to make all-encompassing flawless detailed process path in advance and then stick to it to the bitter end. Hell, slap a Gantt chart on top of how we worked, and you got yourself a textbook example of a waterfall project.
First thing we did was to get the process down to a clean slate. Almost everything that had to have scheduled calendar event had to go out. Every ceremony and every artifact have been binned and we started thinking about the process in a truly agile and lean manner: what should be our first iteration, our minimum viable process, and how to iterate it quickly and efficiently?
We made a couple of educated guesses about what our starting point should be:
- Continue doing daily stand-up meetings to help the communication going
- Use a Kanban board to visually track progress
- Concentrate on swarming on items as a team to get better flow and reduce WIP
- Concentrate on clearing accrued Work In Progress to be able to iterate the process once WIP is under control
- Concentrate on doing things just-in-time to avoid waste
- Substitute previous scheduled all-hands-on-deck ceremonies with ad hoc meetings on a need-to-know basis attendance to avoid waste and to adhere with just-in-time philosophy
- No estimations whatsoever to avoid waste created by focusing on velocity
Having some sort of minimum process in place to make sure things are still moving forward (and these seven points really are as far as you could go before creating chaos), we had to start thinking about how to actually iterate the process to make sure we’re constantly improving it.
This is the point where most powerful and most often overlooked part of any agile (or Agile, for that matter) process — The Retrospective — comes into play.
Retrospective is often used as-prescribed in a certain methodology, being just one of many required ceremonies and focusing merely on “how to max out velocity” problems using some of many retrospective games and generating basically no returns. But we knew there’s something more to it.
Before I continue, I should note here we’re incredibly blessed with two important factors that made our plans work: our company’s culture of openness and transparency and team members with amazing introspection capacity, carefully hand-picked to fit our culture.
We decided to use retrospectives as our main progress driver. Keeping in line with our starting points, retrospective format we decided to use was informal just-in-time event. No sailboats, no glad-sad-mad, no retrospective games at all — I believe those just kill brainstorming potential open and transparent conversations within cross-functional team have.
To be fair, Scrum should also be iterative process, with retrospectives driving the iteration — at least in theory. What ends up happening in practice most of the time is variation inside a fixed set of methodology rules, and that wasn’t what we were aiming for.
We didn’t want to answer to questions like “How should we make this ceremony more productive?”, but an answer to questions like “Does it make sense to have this ceremony at all?”. Building up from a smaller set of “rules” is easier than disbanding established methodology.
So, every time we feel we’ve hit a roadblock of some sorts, something doesn’t go as planned or some coffee break conversation snowballs a new idea into existence, we schedule a retrospective. And every retrospective adds a little bit to our process or to our growing list of action points and rules.
We review our process every retrospective. Some things stick, others don’t make sense anymore and we get rid of them. But our main driving force, committed team wanting to create best process possible, keeps the things on course.
We created our own rules and rituals, like going through pull requests and aligning board first thing in the morning. We’ve started writing better tasks, pre-testing our user stories instead of having lengthy refinements.
We brought back release planning within first few iterations, but we kept it lean, deciding what our release should contain and then scheduling the release just-in-time, when we feel it’s ready. And it actually made releases more frequent and less stressful.
Not sticking to a certain methodology but keeping agile mindset enabled us to borrow and steal ideas from all of them while keeping the process our own and best suited for us.
Is our process now perfect? No, far from it — we’re still miles away from what I would deem a perfect process. It’s also miles better than one we had when we were trying to blindly apply the rules of one-size-fits-all methodology.
But the beautiful thing about it is that we’ve nailed the basics. It’s ever-changing and always improving. It’s not perfect, it’s just good enough, as any agile process should be.
Finally, this isn’t a recipe on “How to create a perfect/great process”. That’s one of the downfalls of current “we have to do Scrum/Spotify model” trend. There’s no one-size-fits-all solution that works out of the box. This worked and made sense for us, but it’s almost certain it won’t work for you.
Figure out what makes sense to you and to your team. Create a culture where it’s possible to experiment and find out what works, together.
In Typeqast, we have our PO/PM/agile “chapter” meetings every once in a while, and it seems we all have different processes and different ways of approach. But every one of our solutions is tailored to and works in their respective team microcosms and is in harmony with Typeqast culture.
If there’s one thing in common to all successful workflows I’ve observed, it’s down to this:
Don’t simply do Agile, be agile.
