What’s the biggest benefit of Agile development? No clickbait title here – it’s continuous improvement.

Ever since joining the development world, I’ve heard about the various benefits of agile development. Many teams and agile leaders focus on the process and trying to get people to “do agile”, but as one of my oldest mentors said: “it’s about being agile and thinking agile”.

Well, what does that mean?

I’ll simplify it:

1. Doing the steps in the agile development process simply help you pick up good habits to plan, analyze, design, and implement your work in small cycles called sprints.
2. Being agile offers you the ability to quickly adapt to changes in technology, design, your users’ needs, and your stakeholders’ asks.
3. Thinking agile is where you distill the above two steps into focusing yourself, your team, and your product(s) around continuous improvement.

Yep, I bolded all of #3. It’s that important. Here’s why.

“Individuals and interactions over processes and tools”

It’s right in the Agile Manifesto!

When teams start out with agile development, the focus is often on the process. While it’s important to build good development habits, I believe explaining the why as a development leader is critical to gaining adoption in said process. Furthermore, if you can get the team to align with the why, then they’ll be more likely to take ownership of the process so they can improve it to fit their needs over time.

That’s right, the process is not for you, scrum master, product owner, product manager, producer, program manager, project manager, and whatever other development leadership title we have nowadays.

The development process is for the development team. If they don’t value it, I like to let them pick their process and introduce agile principles of continuous improvement over time as a leader within the space. Why does this work? Because the team gets to pick how they work and deal with the continuous improvement as they go. That’s what we ultimately want isn’t it? Self-sustaining self-running teams? Sometimes, that means leaving your precious, rigorous process behind and accepting what the team wants instead.

Reading between the lines development sprints

Now let’s say you have team buy-in on a base agile process or one of their own. Your responsibility is to setup a cyclical development pattern that enables and encourages continuous improvement.

I don’t care what the process is, or what it’s called. Just ensure these steps are included at minimum:

• A recurring time for the team to meet and give updates on their work and call-out for help.
• A backlog or in-flowing stream of work for the team that’s tracked in a place for everyone to see.
• Regular planning sessions where:
  • Dev leadership keeps the backlog in priority order
  • The dev team defines the work, what it means for the work to be “done”, and how to test it
  • The dev team meets to commit to a body of work for the next development cycle (or two)
• A recurring time for the team to identify how they can continuously improve how they work

That’s it! It’s that simple. Did we have to call that agile or any other process name? Not at all. I bet if you proposed the above bullets to a team without calling it anything, you’d likely achieve alignment on those processes making sense for a dev team to be successful.

However, once we start the conversation with the term “agile” or any other development methodology, all other anecdotal evidence, previous successes, blunders, fear, doubt, and everything else flows into the conversation and muddies the water. Keep it simple.

This system let’s you focus on how you’ll setup communication points, a backlog of work, a steady stream of planning, and most importantly: a recurring conversation about continuous improvement.

Now, it’s your job as a development leader to take your wide view of the development process and progress and steer the team towards success through continuous improvement. Oddly enough, this success is driven by recurring failures and how you fix them rather than a sure-fire way to succeed every time.

Retrospect

In your continuous improvement conversations each development cycle, you can run the general “what went well, what didn’t, action items to improve” retro. That’s fine and gets the job done. What you need to focus on are the following:

Make “what went well” genuine and celebrate people/ teams more than processes. This gets the team in the habit of giving gratitude to each other and that goes a long way in building trust and offering a safe space for positive feedback.

Ensure there are learnings and follow-up discussions to “what didn’t go well”. As a leader, you don’t get to simply say, “well that was crap”, and leave it as-is. You have to learn from it. Not necessarily fix it, but learn from it. Sometimes, that means learning from how the team wants to fix it. Letting the team own the improvement gets them in the habit of dealing with their own dev processes and customizing it for their needs. If they ask you for help, offer it in the form of best practice rather than specific solutions. Otherwise, be a bystander and push the experts to improve their own process.

Of course, you should never let the team fail in a destructive way. If you know the solution in a critical time where failure isn’t an option or there are negative impacts to the user, stakeholder, and team – step in and take the lead. Otherwise, don’t scratch the itch of immediately trying to solve the problems. Unless you’re causing them of course!

Finally, the “action items to improve” section is yours to follow-up on…right? Partially. If your position has you facilitating development discussions, your life is likely filled with follow-ups. However, I want to make something clear – you’re not the dev team’s parent, nanny, or caretaker. They are professional adults that have committed (with you) to do an awesome job and develop value for the users and the company. If they say they’ll do something, leave it to them to do it. If they don’t follow-up on the action item. Mark it as a failure in the next retrospective and ask them if they’d like a reminder and take volunteers from the team to remind them.

After all, the improvements you make in “continuous improvement” are for the process or developer behavior in most cases when it comes to a retrospective. Both of those are owned by the dev team – not you (the dev lead). You can be accountable for the team having a development process and continuous improvement while holding the team responsible for owning the process and improving it for themselves.

I’ve found that if the team generates the action items, it’s easier for them to take ownership of the follow-up. Treat them like adults and let them handle this. If you see an action item that’s clear to you, but the team isn’t calling it out, you can simply state, “…this looks like something we can improve, [dev name] do you or anyone else want to tackle [team-based solution]?”. Once the team accepts, a simple, “Cool, I’ll leave you to it and check in next retro”.

Continuous

Plain and simple: the biggest benefit to agile development is being and thinking with an agile mindset to optimize for continuous improvement – not simply doing agile things in the form of a rigorous process.

1. You, the dev lead, are accountable for ensuring the team continuously improves – not getting them to adopt a specific development process.
2. The dev team is responsible for adopting a pre-existing development methodology or creating their own.
3. The dev team is responsible for identifying ways to continuously improve how they work.
4. You’re here to lead and guide the team through steps 2-3 and all the mini-steps in between.

Want to dig deeper into the studies behind mindset and mastery that inspired this post? Check out these books!

GL HF!