Agile lessons learned

Lasse Diercks
Mar 19, 2017 · 4 min read

I’ve been working in agile environments for 6 years now. Working in an agile manner as been proven to be a huge booster in team productivity. So I decided to share the lessons I learned along the way.

Its always done and its never done.

A core factor of the agile mindset is iteration. Whatever is in the master branch (or whatever your production branch is called) is done. What you do afterwards is creating tasks for additional features or bugfixes.

You always take the current situation into consideration and how to improve it or repair the designed product. The mission of the stakeholder (it might be yourself on a personal project) afterwards is to communicate which iteration is complete enough to ship it to users. Then again the master is done and you can focus on what to next.

There is always too much to do

When you work with an issue tracking system (jira, github, trac etc.) there is a fairly big chance there are a lot of issues older than one year. There are braindumps, feature requests, bug reports and some random things you created during a meeting.

Working agile doesn’t mean you have one big backlog that decides for you what you should do next. Working agile means you, your team and your stakeholder decide on a batch of tasks that are feasible (I like the smart framework) and complete the tasks in the next iteration. After the iteration is over, everything goes according to plan (I’ll talk about surprises later) you decide on what to do in the next iteration.

Agile means you set yourself free from the amount of things you could do and focus on the things you actually want to achieve next.

Embrace the process, always change the process

After the completion of an iteration there is a retrospective where you talk about what went well and what went wrong. This is a precious moment that allows your team to reflect on the current process and decide where it’s working well and what you have to tweak. Take in consideration that the surrounding circumstances are always changing. Team members come and go, people go on holidays, maybe some new tool has been released or a new technology has arrived (if you’re not working in css). So it is natural that an environment, that is always changing, demands a always changing process.

If you want to learn more about that in particular I highly recommend to take a look at the Toyota Kata by Mike Rother

Always propose

If you think something is not working well take a step back and come up with a proposal how you would improve the situation. Talking about a proposal allows you and your team members to go into a constructive direction and avoid pointless discussions.

It’s also helpful to not connect the proposal directly to you. It has happened in the past that I created a proposal that sparked a talk about the topic and after a constructive discussion I myself thought the proposal wasn’t a good idea anymore. That’s okay and it’s awesome.

Surprises are natural

Spoiler alert: you will encounter things that are more complicated than expected. What’s important is to communicate this to your team and stakeholders early.

Let’s say you’re in the middle of an iteration and a task is way more complex than expected. Call it a surprise and have a chat how you should proceed.

What you could ask when facing a surprise is: Is it important enough to be taken over to the next iteration? Should you spike a solution? (spiking here means to create a not polished prototype to prove a concept) Should you hotfix it for now and come up with a proper solution when it arises again?

I usually hotfix something smaller and apply the rule of three before refactoring something.

The rule of three means: When something happened 3 times, it’s not a exception and will most likely happen again.

Also communicate to your team if the surprise was caused by technical debt.

A blocker is not a type of bug, a blocker is a priority

Given you have a task you want to accomplish and something unrelated prevents you from achieving it. That’s a blocker.

When a blocker is mentioned in your team chat or office-space, take at least 5 minutes to see if you can help. It might be a huge fuckup in webpack (a magic tool that bundles all your css & js to production files) that requires rethinking everything. It also may be a small configuration bug that is solved in 5 seconds. Either way, your team should always be free of blockers and be able to complete the given task.

If it hasn’t happened before you should talk with your team about the definition of a blocker and when and how to communicate them. It’s definitely not another feature request that should be squeezed into the current iteration because someone thinks it’s important.


Let me know in the comments what your experience with working agile in software development is and if you think something is absolutely missing here.

Also pushing the green ❤ in the bottom would mean a lot to me if you appreciate what I wrote here.

Honorable Mentions

I have this knowledge because I had the amazing opportunity to work at Jimdo with agile ambassadors like Arne , Nadja and Sebastian.

They did an awesome job introducing it to the teams and Sönke even started a Kaizen Cop where we took time to talk about this huge topic in detail.

And at least all this was only possible because Fridel, one of the founders of Jimdo truly believed agile is the right way to go and decided to hire the right people to spread the knowledge.

Thanks for reading ❤

I’m Lasse, a freelancer helping to realize ideas in the web. If you want to keep in touch, make sure to follow me on twitter

Thanks to DAN

Lasse Diercks

Written by

I help people to succeed in the web.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade