Before we dive right in, let me start with a disclaimer: I acknowledge this is a really broad topic and this post is by no means meant to be exhaustive (not even regarding my thoughts on the topic - I might follow up with a part two someday). Also, I’m not going to explain the various principles commonly used in agile - that’s not the goal of this post. But at the same time, please don’t feel detered by the terminology - as you’ll find out, you won’t actually need it to understand the post.

Also, I’ll start all the agile methodology-related words with a capital letter. That’s not an actually used convention, I just want to make it easier for readers who might not be as well educated in the methodology as myself. Of course I’m kidding - as I’ll try to explain, they might even be better of for not having been introduced to the fancy words yet.

My first encounter with agile was in February 2021, when I started in an establish Czech news company. (The engineering was a disaster there, but I didn’t know that yet. But while my today’s topic is probably a symptom of that, it’s not really important for this post.) I was told we were doing scrum (without any experience with it, I was not able to challenge anything). Our team had a Daily which commonly lasted an hour. Every two weeks, we had a Planning. We were estimating tickets in hours, never made it on time and kept going like that. Our product manager told us what we were supposed to finish in our 2-week sprint, with respect to the estimated hours (which were painfully incorrect, as you could probably have guessed). We even tried introducing scrum poker, to have more diverse guesses of the hour estimations 🙃. That was it. Maybe we did have some kind of Retrospective, but I cannot remember any, so probably not. … Near the end of my 9-month stay in the company (in retrospect, I understand that I shouldn’t have stayed there longer than my 3-month probationary period), some enlightened leader came to us and suggested we should start doing Refinements, that we should not estimate in hours (but didn’t help us understand what we should replace them with), that our Daily should fit into 15 mins and that the engineers should be able to what they’re willing to include in their Commitments, instead of having that imposed on them by the Product manager. “Oh okay, maybe what we have been doing the whole time was not actual scrum / agile”, I said to myself.

Then, a much more pleasant 9 months in a software-first Czech company started. They mentioned during our onboarding that they were probably the very first company to start doing agile, way before the rest of the industry picked it up. All the years back, they invited some Sillicon Valley guy to help them understand and evangelize, and just like that, the whole company jumped onboard. I couldn’t wait to understand what agile really was then. And I got a lot of answers: how Story points work. How Velocity works. What a Daily is actually for. Why a Retrospective is so important. (I’m slooowly getting to my first point - all this kinda helps with predictability, and don’t get me wrong - it can help with predictability quite a lot. But does predictability really mean agile…?)

After getting an offer from Lokalise, my employer to date, I got to meet scrum’s friend Kanban. What it mean in our team was basically no need for Planning. Then, after some reorganization, I switched to a different team and we started discussing whether to go with scrum or kanban. Some were insisting that kanban was simpler and more suited to dynamically changing conditions. Our Agile Coach countered that real kanban is actually stricter than scrum.

It was probably by then when I slowly started to realize what some problems of agile are. I’ll mention some below.

Some time later, I bumped into a clickbait-titled youtube video called something like “Agile is broken” (8-ish minutes). Clickbait worked, I clicked it. And it was super interesting, really on point. I was so hooked that I followed to the uncut version thereof, >1 hour. So on point!

The guy in the video was Allen Holub, and if you feel disgruntled by agile, I cannot recommend him enough. Below are several points (after the months since watching it, I’m no longer sure which ones are direct quotes and which are my followup thoughts):

  • every company, sometimes every team of the same company understand something else under the term “agile”
  • there are often very long arguments about why this or that aspect of whichever agile methodology is wrong / right
  • agile became such a buzzword that it’s quite easy to get detached from what it should be helping us achieve and just debate what is the “right” agile way to do xyz, while kinda losing track of the original objective
  • it’s very easy to get sucked into these discussions, without a clear outcome
  • a lot of people are very opinionated about agile
  • a lot of people has a very strong idea of what the “right way” is
  • agile (as an adjective) should not mean predictable - a big trap of doing agile “well” is estimating your work better
  • estimating your work well enough is often necessary because the stakeholders don’t think in terms of agile - they think in good old waterfall, with clear goals for the quarter, sometimes even year (and of course deadlines)
  • so in essence, we’ve indeed lost track of why agile was created in the first place - to be (drumroll please) agile (because being really agile in the plain English meaning of the word might be unpalatable for the stakeholders/top management)
  • you might be much more agile when doing 0 Ceremonies, if you’re constantly revalidating with stakeholders and customers (and your team!) and don’t see your plans and goals as something fixed

Don’t get me wrong, all the Ceremonies are not a direct obstacle in achieving this, and I’m pretty sure there are a lot of teams doing scrum / kanban and being really agile indeed. It’s just that I feel like it’s very easy to get distracted with all the books and coaching and certifications and kind of forget what was agile supposed to help us with in the first place, and thus end up doing perfectly predictable waterfall.

In the last few months, we’re rushing to deliver an MVP. It’s pretty stressful, everything is changing constantly, we’re discovering a lot of things on the go and I love it. For the first time, I really feel I’m being actually agile. The problematic part? We don’t know how to do it. Our scrum setup is not really helping us with this. It’s totally possible that we’re not doing it “the right way” and the right way would help us there. Or maybe we could try something else entirely. Maybe we could give Extreme programming a try? I’ll let you know how this goes.

Thanks for reading!