Easy in theory, difficult in practice

(Before you correct me for misstating the iconic quote in this article's title, read ahead)

Over the past week, I've seen a number of posts from different practitioners on the Mastodon.world instance complaining about agile.

Here are a few of the examples I've read:

• Agile events or meetings taking up most of the productive time each day
• User stories not providing an understanding of a user's needs and wants
• Continuous delivery of changes resulting in significant unplanned outages
• Sprint burndown charts showing zero completed work till the very end of a sprint

Now if someone's experiences with adaptive delivery are limited to such examples it is no wonder that the reaction would be "Agile sucks!"

To which I respond #NotMyAgile.

Until someone invents a bracelet which delivers mild shocks to leaders and team members who ignore the basics of adaptive delivery, adoption challenges will persist.

And the more concurrent teams an organization has, the greater the likelihood of this unless each team has sufficient support and guidance to help them through these growing pains. An in the early days when there are very few people who know what to avoid, their capacity should be the constraint on how much work is done using agile approaches.

But barring that, team members can ask themselves the following question when they, the team as a whole or their leaders are deciding on what to do: "Does this result in greater value delivered to our customers, improvements to the quality of what we are doing or will it help improve our engagement or motivation?".

If the answer is "no", speak up.

In a recent HBR article on what enables companies to thrive, the author identified a number of well known factors including:

• Aligning individuals' personal goals with the meaning and purpose of the work they do
• Creating an environment for meaningful, authentic human connection
• Actively nurturing and protecting a culture of psychological safety
• Empowering staff by encouraging responsible autonomy
• Supporting lifelong learning
• Growing the company itself in terms of the markets it targets, the products or services offered, and the customer problems it focuses on solving

But moving from the macro to the micro scale, could we apply this at a team level with our individual team members?

One way is to start by asking questions which will help us understand where we currently are. Here are six examples to help you get started in your next one-on-one session.

1. How well does the work you are doing align or connect with your own goals as well as those of our company?
2. How connected do you feel to the rest of our team and what ideas do you have on improving the overall sense of connection within our team?
3. What more could I do to support you to make you feel comfortable about trying something new, speaking up when you see something isn't right?
4. How much control do you feel you have over how you do your daily work and what activities or decisions are there over which you'd like more authority?
5. What new knowledge or skills have you gained recently, how are you continuing to learn, and what could I do to make your learning more effective?
6. What are the growth areas for our company which we are currently pursuing and what other opportunities do you feel are worth pursuing?

As these are open-ended questions you will want to follow up after each is answered with other open ended questions (e.g. What else comes to mind?) if your team member provides a brief or closed response.

The insights you'll gain through these conversations will help you to create a backlog of improvement experiments to help individuals within the team or the team as a whole. And by asking these or similar questions on a periodic basis, you'll be able to see whether the changes you introduce are having a positive effect.

The HBR article's author felt that when environments exhibited the six listed factors it would help to unleash "human magic". But there's nothing magical about how to achieve this. Sustained effort and a commitment to continuous improvement on the part of all leaders are two of the necessary ingredients.

I'm just wrapping up Adam Grant's book, Think Again.

I'd first heard Adam speak at the in-person (yes, there was such a thing at one time!) PMI Global Congress conference in 2019 and appreciated both his ideas as well as how he delivered them. His latest book focuses on the skill of rethinking which is a cornerstone of a growth-oriented, adaptive mindset.

Adam provides lots of good insights supported by engaging examples, but one in particular stuck with me.

In his chapter titled "Dances with Foes" regarding the science (sorry, Donald Trump, not the art) of the deal, he covers factors which differentiate average negotiators from skilled ones. While I was already familiar with the benefits of establishing common ground, asking a lot of open-ended, thought-provoking questions and avoiding the knee-jerk reaction of defending against all attacks, providing fewer reasons appeared to be more effective than providing more.

This forced me to do some rethinking of my own.

In past engagements, when trying to gain alignment from a challenging stakeholder, a common "go to" tactic for me was to prepare for the discussion by identifying as many supporting reasons as I could and then volley those at the stakeholder in a prioritized order hoping to sway them towards my way of thinking. This approach usually worked quite well for me in my youth during school debates or in negotiations with my friends which reinforced my belief in the validity of the approach.

However, in my professional career, while it occasionally succeeded, in most cases it didn't. In some cases, the stakeholder disengaged from our discussion and the quality of our relationship suffered as they felt overwhelmed or attacked by the approach. In other situations, it revealed weak areas in my platform which they could then focus on with their rebuttals. And once one reason falls, it can create a domino effect which knocks down the remaining ones.

So the next time you are preparing for a stakeholder negotiation, remind yourself that less is more.

I've worked in the delivery space for thirty years.

Over that time, I've seen delivery approaches rise and fall and wars about ways of working rage on. Frameworks, tooling, nomenclature, roles and rituals have changed, but one thing hasn't. Most executives don't care how you deliver as long as business objectives are met. The question they want answered is not which framework to pick but rather what they need to do to get their business results.

Anything else is just mechanics.

I'm not suggesting that executives shouldn't want to know anything about how those results are produced. Such an "end justifies the means" mindset might encourage a command and control approach from delivery leaders. It is one thing to not know how your car engine works when you take it to a mechanic to be fixed but your car is not part of complex adaptive system the way your business processes and supporting applications are.

Leaders should understand why teams are organized in a certain way, how the members of those teams are feeling, how the decisions they make will affect business outcomes as well as the upstream and downstream implications of those decisions. They should know what technical debt is and how the decisions they make can affect that. They should also understand that they shouldn't create walls between delivery and operations.

They should understand if the delivery targets they've set or the constraints they are imposing on teams are realistic. They need to understand what could go wrong but also how they could prevent those risks from being realized. And they must know how they can best use their power and influence to get their projects to succeed.

But whether you use framework A or B, call a delivery role X or Y, or follow a P or Q life cycle is really not that important to them. If they've come up through the ranks from delivery positions they might have some nostalgic interest in this but beyond that it really doesn't matter to them.

So have your "my Kung Fu is better than your Kung Fu" arguments on social media platforms if that makes you happy. Just don't expect your executive team to pick a side or to cheer from the sidelines.

Two pillars of adaptive approaches are inspection and adaptation.

These can be applied to the product, service or results being produced by the team as well as the way in which those are produced. For the former the use of Minimum Viable Products, Spikes, Minimum Marketable Features and Minimum Business Increments are used to reduce the impacts of building the wrong thing.

But what about changes to the team's way of working (WoW)?

Whether a team uses a scheduled cadence for reviewing their WoW such as the use of retrospectives in Scrum, or they use a just-in-time approach they will come up with improvement ideas.

Some of those ideas will be all or nothing.

For example, if the team has frequently encountered delays with getting support from an external subject matter expert for completing some work items, they could lobby their sponsor or project manager to have someone possessing the same skills to be assigned to the team.

But many times, there might be more than one way to implement the improvement.

Let's say a software development team recognizes that they need to improve their code quality and to do this there are many options available. Coding standards, coding reviews, non-solo coding, test-first development, and automated code quality tools are just a few choices. The team might eliminate some of these based on their context. For example, they might not have sufficient budget left to purchase a new tool. But once they've eliminated these, they still have to make a decision about how they will implement one or more of the remaining options.

This is where a Minimum Viable Improvement (MVI) can be utilized. Similar to an MVP which is used to maximize validated learning about a product with the least investment, an MVI can be used to validate the team's belief that a given improvement idea will work.

In our example, let's assume the team is interested in trying a non-solo development approach.

They could fully commit to it by having the full team adopt pair or mob programming, but implementing one of these practices wholesale might be too disruptive and if it doesn't work, the impacts would be significant. On the other hand, an MVI might be to find two volunteers within the team who are willing to try pair programming for their upcoming work items.

To be a valid experiment, certain variables would need to be controlled. The volunteers should be representative of the average capability within the team (i.e. you wouldn't want to run the experiment with either the best or worst quality developers) and the work items they pulled should be similar to work which has been completed in the past so that comparisons using quality metrics are possible.

Once the work items have been completed, the team can regroup to review the results and decide whether to proceed with a larger experiment, pivot or tweak the pairing approach, fully productize the practice by making it part of their WoW, or punt it if they recognize it won't work for them.

Taking an MVI approach will minimize the cost of learning and change to just the volunteers directly involved and the risk of work being completed at a lower quality level is restricted to just the work items they pulled.

So the next time your team comes up with an improvement idea, propose that they frame it as a hypothesis and design an MVI to prove or disprove that hypothesis.