🎹 Music for this post: https://www.youtube.com/watch?v=RY7S6EgSlCI.

“What does it mean to be agile?” might be the most common conversation starter in agility’s entire canon.

I don’t really care what people do to achieve agility. Scrum, Kanban, XP, Scrum-ban…whatever you want to practice, it’s fine by me. So long as you are:

• Trying different things rather than standing still;
• Not afraid to fail;
• Accomplishing something — even if it’s learning — rather than nothing;

…you are being agile.

But I’ve come to believe that the entire point of an agile approach is to reduce the anxiety of analysis paralysis. If your agile methods aren’t doing that, then they aren’t serving the intended purpose. Be agile with your agility, and keep trying other things until your anxieties start to decrease. Then — and only then — will you be on the right track.

If you are scratching your head, continue below the graphic…

How do you mean, Drew?

Look at any of the prescribed techniques of agility, and each seems designed to chisel away anxiety in one way or another:

Scrum’s “three pillars”

• Transparency: people agree to talk regularly — and not hide or make mysterious — their issues, progress, concerns, deliberations and accomplishments.
• Inspection: people agree to share regularly — and not hide or make mysterious — their progress, learning, and accomplishments.
• Adaptation: people agree to change in response to lessons learned, thinking only as much as is necessary in the moment, making choices one step at a time.

The backlog to-do list

• People agree to have a single place to record their needs so that they are always ready for review, never to be forgotten, and readily re-prioritized as needs evolve.

The user story

• People employ this simple device that democratizes and simplifies the articulation of functional specifications, something that once was the domain of highly trained engineers.
• Product owners are liberated to merely articulate the who, the what, and the why of their problem, without having to carry the sole burden of the how.

Meeting reduction

• People employ agile frameworks with an aim, to one degree or another, to reduce the number of random and/or unnecessary meetings that they have to have.
• Agile teams recognize that many meetings are a response to a lack of regular information sharing, and a “smell” of something awry. If meetings are an opportunity to “catch up” and allow conversation when everybody has been working separately for too long, something else needs addressing.

Slicing

• People are asked to break large, abstract needs into small, approachable, and interchangeable chunks.

Waste

• Each small step in an agile process provides genuine and meaningful value that addresses present needs. Even when a past solution is replaced with something else, all participants can appreciate the value it provided en route.

Prioritization methods

• Whether a Kano analysis, Theme Screening, Risk/Value Assessment, or others, prioritization methods remove guesswork from the pressures we face when trying to be objective in determining priorities.

Other tools

• Planning poker: An antidote to the dangers of groupthink, ensuring that each person’s unique perspective is shared and understood without bias from others.
• Backlog systems like Jira, Azure DevOps, Trello, Digital.ai and others allow collaborative work on backlogs that significantly reduce or eliminate email communication, ensuring greater visibility into the conversation and progress behind each item in your…ahem…to-do list.

Are there things you think are missing? Email me!

I’m hard pressed to think of any agile techniques that increase anxiety. If you can, email me that, too!

Discuss this specific post on Twitter or LinkedIn.