What even is Agile?

Do you do Agile?

I've recently started working with smaller companies after a period of time working at larger ones. One of the things I've noticed is that the larger companies have a very mature process when it comes to software development. Whilst by no means perfect, they have a process, and for the most part, it works for them.

Working with smaller companies, some who are just getting started with their software development journey, it's been very easy to see how I can take some of what I've learned at the larger companies and very quickly make changes to the way the smaller companies work that have an immediate impact.

Often in a startup environment there is a strong desire to do lots of things at once, everything is top priority and people tend to run around like headless chickens. Agile can really help. It's not a silver bullet, but it can help to bring some order to the chaos!

What even is Agile?

It's a much discussed topic, but I think it's important to understand what Agile is and what it isn't. It's not a process, it's a set of principles. It's not a methodology, it's a set of values. It's not a framework, it's a set of practices. It's not a tool, it's a way of thinking (Thanks Co-pilot!).

According to the The Agile Alliance, Agile is:

The ability to create and respond to change in order to succeed in an uncertain and turbulent environment.

The key principle is that:

It is a way of working that helps you stay focused on what you should be doing.

and because what you should be doing changes often, you need some way of recognising and responding to this on a regular basis.

Tips

So here are a few ways to quickly get started with Agile.

Set a work horizon

Often called a Sprint and often set to 2 weeks, this is a period of time where you focus on a set of work. It's important to set a time horizon so that you can focus on the work and not get distracted by other things. It's also important to set a time horizon so that you can review the work and see if it's still relevant.

A single view of work

For the work horizon to be useful, you need a single view of all the work happening in that work period. If you can't see it all at once then you can't keep track of it. This is where a board comes in. A board is a way of visualising the work. It's a way of seeing what work is in progress, what work is done and what work is still to do. It's also a way of seeing who is doing what work.

If the amount of work you have planned is more than you can get you head around, then it's too much.

Backlog

Let's face it, you've got loads of work to do, and 2 weeks is not enough time to do it all. So you need a way of keeping track of all the work you need to do. This is where a backlog comes in. A backlog is a list of all the work you need to do. And because you have a set work horizon for what you are focusing on right now you don't have to worry about all the other work in the backlog.

Planning

If you have a backlog with loads of work in it, and you have a work horizon of 2 weeks, then you need a way of deciding what work to do in the work horizon. This is where planning comes in. Planning is a way of deciding what work to do in the work horizon. It's a way of prioritising the work in the backlog and deciding what work to do next.

Regular reviews

Both for the work you are doing inside the work horizon and for the work in the backlog.

For the day to day work, you need a way of reviewing the work at the start of the day. This is where a "stand up" come in. It's a regular review meeting, usually focused on the board, usually very short and usually at the start of the day. It gives each person on the team time to talk about anything they want and for people to ask questions. It allows people to feel connected to the team and the work and to understand how it's going.

If you have a work horizon of 2 weeks, then you need a way of reviewing the work at the end of the work horizon. This is where reviews come in. Reviews are a way of reviewing the work at the end of the work horizon. It's a way of seeing what work was done, what work wasn't done and what work is still to do.

Retrospectives

At the end of each work period it's important for the team to reflect on the previous work period, the work in general, how they feel, what went well, what didn't, come up with ideas on how to do it better, basically a discussion for the team to identify how to improve the process. Nothing is off limits - it's a great way to promote team cohesion, understanding, respect and trust.

Estimating

I've mentioned the backlog above, which is where future work is kept until it is ready to be done. However that work needs to be specified in enough detail to be able to estimate it in some way. It's a big topic, but the key thing to remember is that an estimate is relative - it only makes sense within the context of the team making the estimation and it is only useful in trying to get to a point where the team is able to estimate work effectively. This takes a bit of practice and there are no immediate results. As a result, it's possible that people get bored of doing it because they don't see the point and so the discipline of specifying and estimating the work is abandoned and so 'estimates' are always wrong and hinder, rather then enhancing the planning process.

Getting started

So those are the principles, but how do you put them into practice? Here is an example of how you might get started.

Choose a work horizon

I'd recommend 2 weeks. It's long enough to get some work done, but short enough to be able to change direction if needed.

Create a board

At the very least have 3 columns; Next up, In progress and Done. In my current company We've got columns: Next up, In progress, Review and Done. Next up is prioritised so we know what work is next in line. In progress is what is being worked on and there should only really be a single ticket per person in there, any more and you risk getting stuck never actually delivering something. Review is a gate to ensure the product owner is happy with the work before it is marked as done. And Done is well, done :)

I'll create a ticket for that!

Get into the habit of creating a ticket for everything. If it's not in the backlog, it's not going to get done. If it's not in the backlog, it's not going to get prioritised. If it's not in the backlog, it's not going to get estimated. If it's not in the backlog.

Planning

This doesn't have to be time consuming and it doesn't have to be detailed - as long as you got a reasonable idea of what work you've got coming up in the next few days, work can continue to flow. Sometimes the start of Sprint standup takes a little longer as people discuss the work and prioritise it, but that's ok.

Standup

15 minutes, every morning, same time, same place, same people.

As I've mentioned a daily standup is a great way to keep the team connected and to understand what work is happening. It's also a great way to identify blockers and to help people get unstuck. It's also a great way to identify when people are struggling and need help.

Retrospectives

I like retros. They help me connect with the team, they help everyone understand what everyone else is thinking or feeling. They flatten the hierarchy, which leads to better decision making. They don't have to be complicated, they don't have to be long, they don't have to be formal. They just have to happen. A simple board with 3 columns: What went well, What didn't go well, Ideas for improvement. Then just go around the team and ask them to add things to the board. Then discuss them. Then pick one or two things to try and improve. Then try them. Then review them at the next retro. Easy!

Conclusion

This is a very brief introduction to a topic with a wealth of resources available. I hope it's given you some ideas on how to get started with Agile. If you'd like help planning your software development then get in touch!