Why do we need flat head screwdrivers?

After taking a break from writing for a few weeks, I was planning to write about the importance of conversation in the work we do, but a late day Mastodon toot caught my attention today: “Gantt charts are lies“. Based on the hashtags accompanying the post, the author works in the software development domain using adaptive approaches.

While I can empathize with the frustration underlying the post, it resonated with me in the same manner as if someone had written “Flat head screwdrivers are useless“. While we might wish the folks who chose to use a flat-headed screw had used a Phillips or a Robertson instead when trying to unscrew one which has a messed up slot, depending on what you are trying to achieve, a flat head screwdriver might be just what you need. Apart from driving screws, I have found its value as a small pry bar is understated. One example has been to safely remove the sheet metal cover for my furnace filter which has extremely sharp edges.

When Henry Gantt had originally adapted the chart which is named for him, it had been used to document the activities and timelines for past operational work. Somewhere along the line, it started to be used as a tool for planning, tracking and communicating schedule information on in flight or future projects. This included adding details such as dependencies and baseline information.

The modern Gantt chart has benefited greatly from automation as prior to the introduction of rudimentary scheduling applications, they had to be redrawn any time changes occurred.

Like any tool, misusing a Gantt chart will cause problems and an experienced project manager should have the wisdom to avoid those.

Similar to a work breakdown structure, the level of detail in a Gantt chart should be based on the degree of confidence the team has in remaining activities as well as on the desired degree of monitoring of the work being done. While work whose delivery is highly predictive might benefit from the use of a detailed Gantt chart, one where a highly adaptive approach is required will necessitate the use of a chart at a very high level of detail or a completely different method of visualizing schedule information.

And like most other project management artifacts, if the frequency of updating the Gantt chart is much lower than the frequency of material changes to the schedule, the information presented can’t be trusted.

Does this mean we should stop using them?

In the author’s context, perhaps the risks of using a Gantt chart outweigh its benefits, but pragmatism is required to understand that they can still be useful in the right contexts and when used in the right manner.

(If you liked this article, why not read my book Easy in Theory, Difficult in Practice which contains 100 other lessons on project leadership? It’s available on Amazon.com and on Amazon.ca as well as a number of other online book stores).

Don’t hate the game, hate the player

(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.

(If you liked this article, why not read my book Easy in Theory, Difficult in Practice which contains 100 other lessons on project leadership? It’s available on Amazon.com and on Amazon.ca as well as a number of other online book stores).

Agile won’t fix organization dysfunctions

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.

(If you liked this article, why not read my book Easy in Theory, Difficult in Practice which contains 100 other lessons on project leadership? It’s available on Amazon.com and on Amazon.ca as well as a number of other online book stores).