Leading an autonomous Agile environment

Andrew Sharpe
Aug 23, 2017 · 7 min read

There are countless articles on what successful agile processes look like. Similarly, there is a lot of academic writing and thinking on agile best practices. And, for the record, I am not a by the book agile person (do not ask me to recite the rituals, the purposes, etc).

What interests me is how do you create an environment that allows for the successful adoption of agile. This pertains to teams that are new to agile as well as those continuing on their agile journey. For a variety of reasons, I have played a role in multiple teams developing agile systems and most recently been the champion of agile transformation.

Simply, how do you create an successful agile environment?

I believe Agile is the best way to deliver product in a technology environment. And paraphrasing Winston Churchill: Agile is the worst form of software development; except all others that have been tried. Agile is a no-brainer.

This is not a review of agile. This covers some of my experience in building and supporting agile environments as an Agile Champion and team leader. This is what has worked for me:

Championing agile

There needs to be an agile champion. You don’t necessary have to call them the agile champion. They do need to be the voice of the benefits of agile. This role is as much internal to the agile team as it is to external stakeholders.

To the team, the champion needs to set examples of how to act and be willing to call out when the team is slipping. They need to continually remind the team why they are adopting agile as a system and what it means for individuals within the team. They will likely own an agile principles document or similar that everyone should be referencing.

Is this person the Scrum Master? Long term, if you need a Scrum Master, your team is clearly not embracing agile. For a truly autonomous agile environment, everyone in the team is living, breathing, and improving the agile experience. I was on a panel recently that changed my thinking on Scrum Masters. Simple put by one of the panel members, Syed Ahmed:

A healthy agile team should think about firing their Scrum Master every sprint.

Externally, there needs to be a champion of agile between stakeholders and the team. In all likelihood, a software development team is the largest line item expense of an organisation. As a result, it will garner a lot of interest from the stakeholders especially about what is being delivered. Having stakeholders constantly checking in on an agile team defeats the purpose of the autonomy that agile offers and doesn’t let an autonomous agile environment develop.

The biggest part of this is reminding stakeholders of the shift from defining solutions to problem solving. Stakeholders won’t know specifically what they will get. It is up the champion to continue to fight this battle (it is always a battle) and remind them they will get a better solution to the problem.

Buy time

Especially when you are first shifting to agile, you need to effectively communicate to stakeholders that initial results might take some time. It is crucial time is given to get at least initial results.

It is also important to remember things like availability and positive memory biases: stakeholders will clearly remember they were give a clear, concise quote of both time and dollars for a particular project. Of course, they won’t remember that the time doubled and cost tripled.

Ship early; Ship often

Following from the role of external communication, it is crucial that the team delivers early and often. It cannot be over-estimated how important a good delivery culture is in tech development.

This is not CI

Simply, if stakeholders see something being delivered (even better if they can play with it) they are far more willing to buy into the process. As an example I once took a senior executive’s phone for an hour to install the current agile build our team was working on. This wasn’t a special build, just the one from the last sprint. His response on playing with the build was: “This is great. Exactly what I wanted. How long will it take this prototype to be built?”. To his credit he was knowledgable about the gap between UX prototypes and a production version.

Imagine his surprise (actually disbelief) when I said this could be pushed to production in days?

Regardless of stakeholder engagement and that an iterative build process will deliver a better product (for another post), shipping product builds a great team. We are wired to build things. We are wired to be proud of what we do. Delivering something we can show others regularly is wonderful for morale. It also reinforces the culture and environment the team is building.

It’s Agile, not random

Of course, said Senior Executive immediately wanted a series of minor aesthetic changes to the build I showed him. As my co-collaborator Marc Thompson is quick to remind:

Agile is a way to deliver product without all the information, not the ability to reserve your right to change your mind

There needs to be someone (be it the Champion and/or the team leader) who constantly reminds everyone of this core aspect of agile. In practice this normally means delving to understand the problem that is underlying the changes … and if there isn’t one, pushing back.

There is no greater way to break a team’s agile culture by having a random stakeholder demanding changes without proper justification and respectful engagement.

Being able to capture true problems and getting solutions out quickly because of the ship early, ship often mantra helps in this regard.

Celebrate failure

If we were attempting to be purely by the book, a test, fail, and learn framework falls more under Lean. My experience is that most people equate agile and Lean closely together. Specifically around the expectation that you aren’t going to spend all of your time researching the optimal solution to an identified problem (well, technically first you need to assess how much of a problem it is) before handing over to a delivery team.

In a fast paced agile environment, you aren’t going to get everything right. You might only solve part of the problem. You might spectacularly fail.

It is important to encourage and celebrate these failures. They aren’t going to happen because of anything wilfully destructive the team did. They are a result of the best efforts of the team and a quest for exploring options and innovating novel solutions.

What is important is building an environment that recognises failure and allows the team to review it in a non-threatening way. This builds an environment where issues are raised early, the same failures don’t happen again, and better solutions found (as others have been found to not work).

This is healthy and exciting. Without failure, we don’t learn.

Tickets, Tickets, Tickets

A developer I was working with as we sought to move to a more agile team environment asked about documentation in an agile environment. Specifically that his experience was that not much was captured in agile.

This is low/no-docs doctrine. This is not agile.

If anything, agile should result in more documentation. It is important to get agile teams in the habit of updating tickets and communicating through tickets. Yup, get out of meetings and start communicating through tickets. This has the advantage of capturing all ideas, why they will work, and why they won’t work. Also gets us out of meetings which is an ancillary benefit.

The further benefit is that there is less interruptions throughout the day. If you have to verbally ask a question, you either face the risk of interrupting someone when deep in concentration and/or waiting for the right moment. You also lose the colour of the conversation. Communicating through tickets solves this.

Yes, there is a place for the ‘collabatable’. A good team will always document the results faithfully and add it to the relevant ticket immediately.


This post was the result of a very generous invitation by Alana Fisher to join the brilliant Emma Sharrock and thoughtful Syed Ahmed on building autonomous agile environment for feature team success as a part of the Sydney Chapter of Product Mavens. Thank you to everyone above who kicked this off as well as SiteMinder for hosting and allowing the magic to happen.

)

Andrew Sharpe

Written by

Passionate & Pragmatic Product Leader | Always falling in love with problems

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