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.

A Mastodon post inspired me to ask ChatGPT to compose a song about agility in a Weird Al Yankovic take on Right Said Fred’s “I’m too sexy”.

Hope you like it!

Verse 1: I’m an agile developer, hear me code I’m always delivering, never on the road I’m working in sprints, and I’m doing just fine I’m always on time, and my code is divine

Chorus: I’m too Agile, for your waterfall ways I’m too Agile, for your slow and delayed days I’m too Agile, for your old fashioned ways I’m too Agile, and my code always amazes

Verse 2: I’m using Scrum, and Kanban too I’m always improving, and my team is true blue I’m embracing change, and it’s all for the best I’m always ahead, and I’m passing the rest

Chorus: I’m too Agile, for your waterfall ways I’m too Agile, for your slow and delayed days I’m too Agile, for your old fashioned ways I’m too Agile, and my code always amazes

Bridge: I’m sprinting to the finish, and I’m never done I’m always moving forward, and I’m having fun I’m Agile, and it’s the way to be I’m Agile, and my code is the key

Chorus: I’m too Agile, for your waterfall ways I’m too Agile, for your slow and delayed days I’m too Agile, for your old fashioned ways I’m too Agile, and my code always amazes

Outro: I’m Agile, and it’s the way to go I’m Agile, and my code is always flow I’m Agile, and I’m never slow I’m Agile, and I’m always in the know.

I'm in the middle of Adrian Gostick and Chester Elton's book Leading with Gratitude. I really enjoyed one of their previous books, The Carrot Principle, which provided great case studies on the importance of recognition in the work place as well as multiple suggestions on ways to recognize colleagues without spending a cent. Leading with Gratitude is a very readable sequel to the previous one, and focuses on the importance of gratitude in improving individual, team and company performance.

I've written previously about the importance of creating a culture of appreciation within teams and provided one way to do this regularly via retrospectives, but this book provides some additional insights and ideas.

The authors mention the research conducted by Teresa Amabile and Steven Kramer which indicated that a significant boost to our emotions and motivation comes from making progress in work which is meaningful. The research also shows that the more often we feel that we are making progress, the more creative and productive we are likely to be.

As project managers, we tend to be goal oriented, and recognizing our team's efforts in achieving a major milestone is important. But it is equally important that we express sincere, regular gratitude for the small wins which our team members are achieving.

If you happen to work in person with your team members, it is easier to identify incremental progress and recognize it in real time. But this can also be done virtually if you are watching your team's progress via work boards or following their discussions in collaborative chat tools.

Keeping a gratitude journal (or OneNote Notebook if you prefer) is also a good way to remind yourself about what's going well and what might be acknowledged.

While it is important that leaders express gratitude, if by doing so team members start to do the same to each other, that creates a compounding effect.

One way to do this is during daily coordination events (e.g. Scrums, standups or huddles). While the focus of the events is to help the team coordinate their efforts towards the day's goals, it can also be a good opportunity for an individual on the team to do a shout out for one of their colleagues.

Gratitude can also be baked into the working agreements of the team and how team members will act on it might vary. One example of doing this which comes from sales teams is to have a bell, squeaky toy or other type of noise maker which is triggered whenever someone has done something to be grateful for.

And if you are worried about diluting the value of gratitude by expressing it more frequently or thinking that team members will get tired or numb of it, don't worry. Based on the extensive research done by the authors, they have not run into one instance where someone complained about being praised too much.

A new year has just got underway and if there is one resolution which is worth making and sticking to, it is to be more grateful.

This week, I participated in an interesting discussion on Mastodon in which the initiator asked for input on ways to frame agility based on the core problems which a team might be trying to solve. This is useful as it can help to answer the "why" behind an approach change. However, when I indicated that there were problems which a shift to an adaptive approach wouldn't solve, the initiator wanted clarification about my feedback.

Here are some of the common problems I've encountered which won't be fixed by adaptive delivery.

• Accepting more concurrent work into the system than can be delivered based on available capacity. This causes multitasking, stress, quality impacts and prolongs delivery time. It will also make it difficult to do forecasting.
• A burden of legacy assets. It is hard to be nimble when you are chained to a boulder. If the processes for integrating with or updating those legacy assets can't be improved or if the skills required to do are unavailable, that will be the constraint which defines your delivery speed.
• A tolerance for toxic behavior. If leaders are unwilling to hold themselves and others accountable for actions which reduce psychological safety, quiet (or real) quitting is likely to reduce agility.
• Delivery or control partners who are unable or unwilling to modify their interaction models with delivery teams. If the Finance department sticks to an annual budgeting approach or if the Procurement department prevents close collaboration between the internal team and an external supplier, this will impede agility. If control partners focus on process adherence and artifacts rather than on teams addressing control objectives, teams will lack autonomy and the efficiency of discovering their ways of working.
• A culture of decision by committee. If individual empowerment is given lip service and key decisions have to be reviewed and blessed by multiple stakeholders, this increases delivery time and dilutes the quality of the decisions being made. It can also result in increased friction between key roles (e.g. Product Owner and team).
• An inability to create a "whole" team. If the team lacks specific skills, experience or capabilities needed to deliver the scope of work, it won't matter what approach is used.
• Onerous external requirements for documentation or process adherence. While there is no excuse for not addressing internal inefficiencies, if there are industry or other regulatory pressures to do things a certain way, there will be a limit to how agile a delivery model can be.

While these challenges can't be eliminated by taking an adaptive delivery approach, the increased transparency and shorter feedback loops will surface the problems quicker which will help the senior leaders to create and work down an organization blockers backlog.

As I've done in past years, I like to review the articles I've written over the year and share the ones which were read the most.

2022 was the first year since I started blogging when I took a hiatus of more than a couple of weeks. While I was able to write a few articles in the late Summer based on my municipal election campaign, the overall number of articles this year was less than in previous years.

Here are the top five articles based on views from my personal blog site.

1. Even though the phenomenon of Quiet Quitting has existed for as long as people have been working (I'm sure there was a caveperson going through the motions of hunting for prehistoric buffalo but whose heart wasn't really in it!), it joined the unholy triad of the Great Resignation and Quiet Firing to generate a lot of press. Little surprise then that Are your team members "quiet quitting"? was number one on the most read list.
2. After moving to Welland which doesn't have quite the same sport scene as a major metropolitan city like Toronto, I rekindled my enjoyment in the game of baseball. Our team, the Welland Jackfish, placed very well in the regular season standings but was unfortunately eliminated in the second round of the playoffs. I am hopeful that 2023 will bring the championship to Welland. Watching their games inspired me to write Project management lessons from the old ball game.
3. A chronic challenge faced by project managers in many of the companies I've worked for or consulted with is that rather than spending the majority of their time on high value, strategic activities such as effective managing stakeholder engagement or dealing with emerging risks, they are busy filling out forms and reports. So no wonder that Are your PMs drowning in paperwork? was a popular read.
4. Project management theory tells us that a charter or something equivalent is required to authorize a project's existence. Of course, real world practice varies widely which is why I wrote Are you Batman? If not, get a real charter!
5. When we learn about common techniques to reduce project durations, fast tracking and crashing are often the first two which come to mind. Scope reduction, however, is often a safer and cheaper alternative. While it may not be applicable in all cases, it is worth investigating the option of Do less, finish earlier.

While it was not in my readers' top five, I'd like to close out 2022's final article (which will be published in early January 2023) with a challenge for those of you who are making New Year's resolutions as well as those of you who run retrospectives or similar improvement ideation events: Why hold retrospectives if ideas don't get implemented?

I hope all of my readers enjoy a peaceful, prosperous, and healthy 2023!