Be agile, don’t do “Agile”

Over the last decade I’ve been involved in several projects that are doing Agile. Most of them were using Scrum, and most of them didn’t really deliver what was promised. The promise of Scrum is that the team delivers more value, but what it actually delivers is more reporting tools and ceremonies to keep managers busy. Functionality is also delivered, but I’ve found that the process is more of a burden than it helps.
Our team at Studyportals uses something inspired on GrowthBan, which is a variation on Kanban aimed at teams that are concerned with growth. I’m not really a fan of naming things, because that leads to cargo-culting. “Hey, look! That team uses GrowthBan, and it works for them! Let’s use that too!”. And then you implement the rituals and stuff, and you find out that it may not be working for you at all.

Why does this work for us?

Team setup

First of all, we have a multi-disciplinary team with access to anybody in our organisation that might be able to help us. Our team consists of the following roles:

  • A Product Owner who decides what we should work on
  • A Marketeer who handles the marketing side of our product, like partnerships
  • A Growth Hacker who performs experiments to increase the KPIs of our product
  • A Team Lead who makes sure that the team performs optimally
  • Two frontend engineers, one of them also has another role.
  • A backend engineer
  • Since we’re not doing scrum, we don’t have a scrummaster. We invented the role of Mastermaster instead.

Since our team is not a pure engineering team, we have more knowledge about what can be done and why we do it. This helps us to deliver the right things faster. Each of the team members has his own area of expertise, and is trusted to do the best he can.


What I’m used to in Scrum is that the product owner, toghether with business analysts and architects decide what needs to be done. They create an epic, divide it up in stories, and describe what they would like to see as outcome. In this way, Scrum is a bit like mini-waterfall. Engineers only have a say in how these stories are built, not in what we should work on.
Since our team setup is a bit different, we have actual experts in the domains that we are working on. Everybody can, and should, create stories for work that they think is important. In the end it’s the product owner that decides on the priority, but he can be influenced.


While on projects that use Scrum, I was used to a rhytm om two to four weeks. We now have a rhytm of one week: we have a week planning on monday morning, and a short retrospective on thursday. Fridays are always a strange day here, since we have hack-days. During our week planning session on monday, we look back on the previous week, and determine the focus for the upcomming week. What we don’t do is commit to the work that must be finished at the end of the week. If we’re finished early, we start on new stories. If stories are not finished (because, unfortunate accidents happen), we continue next week. Every day we have a normal standup meeting, where we look at the tasks at hand. I did this before, and I prefer this over the format where you tell about what you did, what you’re going to do and if you need help. At the end of the standup meeting, we take a short look at our KPIs to see if we’re still on track.

Looking back

Retrospective is the time where you look back on the past sprint. Most of the time this session is spent on trying to make the process better and more effective. We also do this.
However, we also look at the effect of our work. Did we improve our google ranking? Did we increase the speed of our website? Did google pick up our content changes? Did we make a difference? Success is celebrated.
We also make a big deal about kicking off and finishing stories. Each story that we start to work on is kicked off, and the team is informed about that. Each story that is finished is burned, and celebrated.


In the end, it looks like we’re finally doing what the agile manifesto told us to do. Working together is more important than our processes (though we have them), we deliver working software (though we also document), we track what our users are doing to see if they like what we did, and when we need to change course, we do. We still have plans and things that we would like to work on.

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *