You can’t work in tech and project management without hearing the following buzzwords: Agile, Scrum, Lean, Kanban, and SAFe.
Depending on your working experience then reading those words may have given you a warm fuzzy feeling, or you might have the cold fingers of existential dread trying to creep across your brain. It’s natural to react in these ways, you might have seen dramatic improvements in your working life when these phrases and frameworks were introduced, or you might have wondered why the PM or Scrum Master ever bothered or why your company ever hired this person to begin with.
Well, we bother because we want to see our teams happier, healthier, more productive and consistently creating the best work possible. A lot of this can sound very fluffy and intangible, but as Scrum and Agile project people we track trends, look for major or minor improvements in our teams over time and do our best to quantify it without ever forgetting that we’re dealing with people, not numbers.
Before we get any further into this, I’m writing this with the view that Agile is an umbrella that we use to shelter from the endless documentation and stagnation of Waterfall, and I refuse to be more specific on which frameworks we use at RapidSpike. We draw from different methodologies and frameworks as it suits our team, because that’s what agility is to us.
Startups tend to naturally be quite agile because you’re responding to the market with a small team, going where the data takes you and the company isn’t yet constrained in a thousand sign-off processes. This isn’t to say there isn’t room for improvement, and as startups grow to SMEs it’s vital to keep agility front and centre in our minds as more people come into our teams.
Such is the case at RapidSpike. Across the first five or so years of the company, first there was no project/Scrum/Agile person, then our CEO acted as Scrum Master for the development team and 10 months ago I joined the company to run the projects and Scrum side of things. My first challenge was migrating my team from using Trello to Jira for their tracking. I’m not going to lie, there was some initial resistance and to this day I’m tweaking workflows based on my team’s feedback. After that, I’ve been working on embedding Agile and Scrum practises as standard, encouraging a little more documentation and a little less 11th-hour panic, baby (it sounds better if you imagine Elvis singing it). An early mistake I made was assuming that the team didn’t want to learn the logic of the framework, that they wouldn’t want to know why we started sprint meetings with ice breaker games despite the fact our team includes the platform’s OG developers. Turns out they were more engaged with the seemingly wacky things I asked them to try when they knew the logic behind it.
We’re still learning and growing as we go and it’s all done with scaling in mind. Over the last 18 months we’ve taken on investment from Praetura Ventures, the team size at RapidSpike has more than doubled and we’re not settling down any time soon. With this in mind, the focus in Technology is improving what we have, weeding out the once necessary but now obsolete bits and continuing to engage with our customers and prospects as we consider our next steps. This applies to both our codebase and our working practises. After every sprint we ask:
- What went well?
- What didn’t go so well?
- What do we want to change or try next?
Nothing is taboo, nothing is off the plate and there are no sacred cows — if it’s not working, we work together as a team to improve the situation. That’s actually my favourite bit of my job, seeing the team pull together on solutions, offering advice to one another and making incremental improvements every month.
This isn’t to say there aren’t difficulties or pushback in making these changes, we all have bad habits, occasionally egos and other challenges that come along with systematic change. We don’t use all of the events Scrum preaches, we don’t do all the documentation and RACI matrices that Agile demands, we don’t always limit our WIP for Kanban’s sake. Some weeks I question if Agile is all it’s cracked up to be, if we can overcome those challenges and histories that have been in any company far longer than I’ve been in work… On those days I look at the minute details, how people’s roles have developed and how we’ve adapted along the way so they can push forward as individuals without our whole team falling behind.
All of the Agile practitioners I look up to (and there are many) no matter what framework they ascribe to seem to have one core value, we want the best for our teams, no matter what. That means trying, learning and even sometimes failing. Not every experiment is going to be a blinding success, but we have far more successes than failures and that’s the important part for us. Life in a startup can move so quickly that it’s hard to remember the good that happened even if it was only a few days ago. Track the trends, not the days. This is why we always ask that first question, “what went well?” We so rarely stop and smell the roses in Tech, we’re more focused on the next bug or feature, so we now force a little bit of appreciation into every session. Our team is pretty awesome, and it doesn’t hurt to remind them of it.
Embedding Agile isn’t simple, and I don’t have a formula to wrap this post up with, just one reminder that’s more for me than you dear reader — if you want the best for your team and from your team, it’s okay to kill the sacred cows.
