A pragmatic approach to agile

I’ve been working as a software engineer for a while now(even started growing white hair!) working for companies in different industries, within teams of various sizes and shapes. Throughout these experiences, I’ve got to realise that some key factors contribute to making a team work well.

When working in a company we are all part of teams that work together and rely on each other to deliver a great outcome, either product, experience or service. In a way, we are similar to the different parts of a mechanical watch, each one of us having a specific role to play so that other parts can achieve what they need to do. And, like with a watch, if we all work in sync and fulfil our purpose, we can deliver the expected outcome with the expected level of quality. 😉

However, like with watches, sometimes there might be unexpected factors, like impacts or dust, coming up that might delay one part and make others not work exactly as expected.

Does it mean the watch will necessarily stop working? Not really… Most of the time, your watch will still be able to give the time because it is flexible enough to absorb some shocks or oiled enough to keep working with some dust…and so should we.

Now that you get the concept (or maybe not…), let me introduce the set of key factors that I think matter the most to help teams to work well with each other and within themselves.

Caveats

• I’m by no means an agile expert, but I’ve worked in enough agile setups to have an opinion on what works well or not. This only reflects my own experience, “my” framework is not a silver bullet for every team out there.
• You should not expect your team (or others) to always deliver features exactly on time.
• The goal of your team should not be dependability, even if it contributes a lot to your team’s success in achieving it. You should always focus on delivering features for your customers.

Scrums or Kanban Goals

Oftentimes, people focus too much on the idea that Scrum or Kanban are the ways to go, but I think that’s not the case. What matters is for your team to be goal-oriented, discussing and agreeing on what you want to achieve in your allotted time. So, in the end, the way Jira is showing you the tickets/your board does not matter. Scrum, Kanban or any other agile framework aim at achieving the same thing, which is slicing work into bitesize tasks. Personally, I prefer scrum because the Jira for scrum allows you to have more control on your tickets, but it’s just a ‘UI/UX’ preference.

You should write your team’s goals down, either as tickets or as part of the sprint “goals” (the reason why I prefer scrums in Jira).

Also, you should talk about them on a daily basis in the stand-ups. This meeting is critical: it shouldn’t be just a status report, but rather the forum where you actively assess your goals, indicating if you think you’ll be able to do your part to be able to achieve them or if you are facing hurdles. If you see your team is more on a ‘shopping-list’ roll, plainly stating what they did/what remains to be done or if your manager only asks you for updates, this is probably because you might be using the stand-ups the wrong way 😅

Finally, discuss the goals during your retrospectives! Retrospectives are very important, and, like with stand-ups, you should talk about topics that matter the most and why you achieved or not your goals during that sprint. Also, don’t forget to thank others for their help, as you are all together in that boat!

Frequency

The agile manifesto explains that you should deliver work frequently, iterate on your work many times and reflect on what went wrong or could be improved. This is not different to the way you should plan your sprints. Big “sprints” are dangerous because you might waste an awful amount of time working on the wrong things. You should rather aim for shorter sprints to be able to readjust. My recommendation is to stick to weekly “sprints”.

Something to note is that your team should have enough work in the pipeline for double the amount of time your sprint lasts. Why? because sometimes you overestimate tasks, and you need something to do, or simply because you need to discard some work and continue with something else.

Retrospectives

You might want to do a retrospective every other week as one week might not be enough to reflect on or that means too many meetings in a single week. I think it’s better to talk about things while they are fresh in your mind, so to keep weekly sprints (and since you have weekly sprints, you should have shorter retrospectives).

What to discuss in the retrospectives? As previously mentioned, you should always talk about the goals, why you met them or why you didn’t and what could be improved so that you are better next time. If you see after a few weeks that you’re always meeting your goals, you might also want to talk about it, as it might be a sign that you are not challenging the team enough.

Estimations

Don’t. Seriously, don’t.

I know most companies have some kind of policy or your team lead needs to report on these magic numbers but, I think they are often given too much importance in the process.

Estimating tasks will slow you down. Don’t do it. We gave it up over 10 years ago.

Jeff Sutherland, Inventor and Co-Creator of Scrum Reference

Ok, you still want to have estimates? Let me explain a small framework and number system that I like to use.

Best teams have small stories

Jeff Sutherland, Inventor and Co-Creator of Scrum Reference

But why is the “A week” estimate so bad? As I already said, you should work week by week. Because of the number of meetings and ceremonies, the available time in your 5-days week is very likely to be 4 days. This means you WILL NOT be able to complete a full 5-days long estimate, unless you estimated it incorrectly, of course 😂.

You may have noticed that task complexity and number of days don’t increase proportionally in my table. The reason is that complexity and numbers of days are just abacus for your manager to have a baseline and something to report on.

Stories

When you create tasks with your team, you need to make sure you have enough description to understand the purpose or rationale but not more (despite writing stories, we are not novelists). If you focus on putting too much context on the story, you might waste time that you could have used to do the task.

I think this is the place to provide some clarity on the task, discuss with your team about the possible approach to follow or something that needs to be considered before doing. For instance, don’t forget to call out any dependencies that the task might have or any other team that depends on this.

In my opinion these are the required section of a story:

• What? What is this task trying to achieve?
• Why? Why is this task important or why do we need it? i.e this is because another team depends on it or because something is broken.
• When can we call it done? These are the acceptance criteria. You should specify what you need to do so that we can consider our job done and move on to another task. Please don’t say we need to add tests, that’s a given.
• Hints: if you know a similar task previously done by your team, then you should totally write this down. This will help to identify the potential issues, get accurate estimates very quickly and to have already an idea of the potential approach to be taken.

Example:

• What? Add product endpoints to API.
• Why? This task is needed by team X as they need to access our internal product information in order to display them in the UI.
• When can we call it done?
  • Endpoint is accessible under /api/v1/products
  • Endpoint is protected by api keys
  • Endpoint returns an empty list instead of 404 when no products are found
• Hints: You can check the endpoint for users as it’s using a similar authentication mechanism.

Conclusion

In the end, the key success factors for a team are:

• Review or reassess goals often to be able to fail and readjust faster.
• Be flexible and make sure you are all on the same page about what needs to be done.
• Don’t focus on following frameworks as dogma, use them as guidelines and make it workable for your team.

I hope you enjoyed this post and that you have learned a different point of view on how to plan your work. I recommend you to try it out for a few months (these changes take time to get used to and sink in) and see how it goes…I’m sure you can become a great and precise Swiss watch 😃

Photo by Pierre Bamin on Unsplash

Thanks

I’d like to thank my wife Marie Dziubich for the help on this post (you definitely did not want to read the previous versions 🤣) and all the people I’ve discussed this topic with in the past.