If you’ve been in tech long enough, you’ve either been through an “Agile Transformation” or you’ve seen the result of one. Usually what happens is the company brings in a consultant for a short period of time (sometimes a day, sometimes several weeks) and they introduce you to a bunch of Ceremonies that you basically follow by rote description and then they leave.

Congratulations! You’re Agile now! Go off and do the thing!

The problem is that these almost never work. Fortunately, there is a reason why they don’t work and it’s fairly straightforward – each group of people works differently. They all have different needs, and this means that they all have different paths to become “agile”, but almost every agile consultant comes in with a set playbook and either drops it in your lap before leaving or tries to mold your group into what they were taught and got certified for.

Agile consultants often describe their practices as being things that you have to do in order to speed up, but every team will have different things that cause them to speed up (and “speeding up” is the wrong way to look at it anyway).

Becoming “agile” isn’t having a standup, putting “points” on poorly defined “stories”, having a meeting where people say things that went wrong but nobody will ever change, or forcing your team to “commit” to shipping a certain number of points in a “sprint”.

In fact, it isn’t an end point or some finished state that your team reaches – it’s a journey that lets your team discover ways that work better for them. You’ll never “complete” an “Agile Transformation” because you will always find ways to improve.

At its core, an agile team responds well to change and works at a sustainable pace in order to provide value in a timely manner.

Seriously. That’s the secret. Responds well to change and works at a sustainable pace (and the definition of sustainable is not a fixed number of points) while providing value in a timely manner.

Sounds great in theory, right? The question is “how do we get there?”

The first part of the answer is that you need to realize that creating a product is a team activity. It’s not something that you compartmentalize by having someone write a bunch of requirements, hand that off to people who write software, have those people hand the software off to a group of people who do testing, etc.

For the more nuts and bolts answer, it depends on where you are right now. The best way to figure that out is to communicate openly and honestly. This can be done in three basic places – before work starts, while work is being done, and after the work is completed. You should communicate openly and honestly during all three.

Remember those Ceremonies I mentioned and that you’ve probably encountered? Some of them are actually good ideas if you do them in a way that works for your team instead of just using them to check a box. The trick is to do them for a reason that makes sense to your team.

Communication Before The Work Happens – User Story Refinement

At its core, a user story is a placeholder for a conversation. If you’ve been using a user story as a set of requirements that you hand off to the people writing the code and never think about again, you’re doing it wrong because no amount of specificity in a written document can cover all of the edge cases and questions that will arise when something is being worked on.

I’ve seen business analysts and product owners get upset when developers want to discuss the finer points of written requirements because “that’s not my job” (or even worse, saying that it isn’t the place of the developer to question anything). This is a team effort and you’re on the team. Expect to discuss the details of what the business is trying to accomplish and even question if the way you envision doing it is the correct one.

It’s easier and cheaper to fix problems early – ideally before they happen.

Communication While The Work Happens – Standup

If I can make one point about standup meetings it’s this – Standup isn’t a status report. It does not exist for your manager to get a daily update on who is working on what card. It is not everyone going around in a circle and saying “Working on card 123456. Making progress. No blockers”. And it is not a meeting that requires the presence of a Scrum Master in order to happen – the Scrum Master, if you have one, is a facilitator; nothing more and nothing less.

Your team is perfectly capable of speaking among themselves with one of them helping guide the meeting – take turns doing it. It will give the members of your team ownership over their own processes and will help them grow as communicators and leaders.

The purpose you should be pursuing in standup is twofold – to get your team on the same page and to surface any problems as soon as possible so you can work together to solve them. Here’s an example.

Joe: “I’m currently working on the authentication for the app, but I’m having a problem getting the company-provided auth library to work. It just sort of hangs after I send the request. I’ve tried reaching out to the team that maintains it, but nobody’s responded.”

Tomoko: “I’ve had to get that working with another one of our products. Let’s take a look at it after standup.”

Notice that at no time during that exchange was a Jira card number mentioned and that the conversation contained actual information that could make sense to the people on the team. As an added bonus, Joe even helped limit the solution space by saying that he’s already tried getting an answer from the other team.

You might also have noticed that this exchanged surfaced two problems – that Joe was having problems getting a company provided library to work (which may indicate that it is poorly documented or buggy) and that he was unable to get a response from the team that was responsible for maintaining it. Both of these things are important to be aware of because they make the team less able to provide value in a timely manner.

Fortunately, it seems that the immediate problem of getting the library working will be resolved by two of our teammates collaborating and sharing knowledge. This is a great sign and one that you want to see happen as often as necessary.

Communication After The Work Happens – Retrospective

It’s a good idea to get together as a team periodically to discuss how things went. Once every week or two is probably optimal because it’s often enough that things are still fresh in your mind and of a manageable size to consider and discuss but not so often that it becomes a burden.

This is literally just a discussion. Talk about what went well and what you can do to keep doing that thing, the things that didn’t go well and whether you can do anything to improve them, and the things that went okay but might be better with a little work. Celebrate your wins and come together as a team.

Some of you are  probably (quite understandably) wondering how I started off saying that the Ceremonies don’t matter and then advocating for using a bunch of them anyway. The truth is that the Ceremonies don’t matter – what matters is that your team start to come together as a group and have meaningful conversations.

You don’t need pre-set meetings for that, though they can be helpful. If part of a framework doesn’t produce value for your team, don’t use it. Sometimes it’s not a good fit for your team; other times it’s not a good fit yet. Let your team come together and figure out what the next step is to make them be able to work at a sustainable pace while being responsive to change and providing value in a timely manner.