Exploring how "agile" consists of good ideas mixed with buzzwords and bad practices...
So, I started trying to write one single blog post about our entire agile process when working on projects. By “process” I mean all the practical stuff. What routines do we have? How do we handle issue tracking, customer demos, etc. The whole shebang. I felt like I kept skipping a lot of vital information as I cut things down though, so I’ve decided to make this a series of blog posts that I will sprinkle in between my colleagues’ posts here and there. This initial post will simply set the scene. I’ll talk a bit about the team we had assembled for our latest project, and which conditions and circumstances we met.
Why am I writing this?
“Agile” is one of those areas that are just hard to navigate. While there’s a lot of good ideas and practices, there’s also a lot of buzzwords and bad practices. For every good way to implement an agile way of working, there’s probably ten bad ways of doing it. I remember a few years back, when I thought that the key to succeeding with agile work was knowing why you did a certain thing.
Let’s assume that you are about to use Scrum in a project. You’ve read the official Scrum guide, maybe attended a course and got one or more of the certifications. These are all good things, since you’re now hopefully in a position to know why you should be doing a retrospective, and why you should have a daily standup, and so on. It doesn’t really give you any clue on how to actually work in an agile way, day-to-day.
I personally think that one of the more obvious ways to set yourself up for failure is by implementing a framework, following it by the book, without understanding why a certain type of meeting or timebox exists. It’s going to be very hard to answer the question of whether this gives you any value or not. And that’s the core of it, right? Having the answer be “yes” to the question “Does this provide us with any value?”, and avoid doing things that doesn’t.
I actually didn’t want to discuss Scrum in this blog post (or any other framework for that matter). I simply wanted to talk about a concrete way of implementing an agile workflow. Moreover, I wanted to talk about reaching that point. I very much doubt that anyone will just say “Hey, let’s do X for agile work” and just have everything work exactly as intended. I think you need to keep working, improve, rinse and repeat until you get it right. And even then, you might have to change things around as your team changes. I could argue that we’ve “failed” at agile before at Edument, because we’ve definitely had occasions when things were running less smoothly than you’d hope for. In reality though, what we did was gather data on what worked and what didn’t.
The team
I was the architect/tech lead on a project that we recently worked on, and I felt like we finally got a lot of details right, and managed to reach that point where our agile process was just in the background like any other tool. Just like we use Git for version control, or use Jira for bug/feature tracking, this should just be part of your daily routine, and you shouldn’t have to think too hard about it.
One problem with trying to implement a framework exactly, is that you might end up in less than ideal situations. What do you do when someone points out that “Hey, we don’t have a Scrum master”, for instance? The easy answer (one that you’re likely to hear) is that you are doing it wrong, and should go find yourself a Scrum master. This doesn’t really tell you how to handle the situation practically though. From a pragmatic standpoint, I’d personally call this answer utterly useless.
So, as far as I can tell, there are a few different ways of handle this. Do we hire someone new to fill this role? Might be risky, since it’ll probably be someone you haven’t worked with before and who have zero knowledge about the project. This will always be a time investment (and obviously a monetary one too).
The reality for us was very much that we couldn’t do this. This was never an option, and what we had was a small group of programmers (3 developers full time, 1-2 developers coming in/out of the project when time allowed), sporadic access to a UX designer, plus a product owner from the customer’s side, located in Germany.
Later in the project, we also had a second team come in from our office in Prague. This was an additional 3 developers working with our team in Sweden. This also means that we now had a team spread across three countries.
The things I want to cover
In upcoming posts, I will talk about which components our work included, such as the customer demo, how to decide on what to demo, how long should an iteration/delivery cycle be, and how we handled our backlog.
I also want to talk about the process itself. What did an ordinary work week look like? How did we start an iteration after a release? How did we finish up before each release? How did we use story points? (hint: we didn’t).
Finally, I want to talk about some of our hit'n misses during other projects. Things that obviously didn’t work in one project, and how we carried that knowledge over to the next one.
Until next time!
By Eric Lavesson