Easy in theory, difficult in practice

I've almost finished reading "Gigs, Hustles & Temps" by Jason Foster which is about precarious work and the negative impacts it creates on individuals, their families and society in general. While we might think of precarious work as something limited to Uber drivers, home cleaners and other gig workers, such work covers multiple industries spanning both public and private sector employment.

The author does a great job of highlighting the personal impacts of precarity such as reduced wages, reduced leverage with employers and delay or deferment of capital purchases, but the chapter on the economic impacts of precarious work resonated with me as it covers the productivity impacts when a large proportion of a company's work force is experiencing precarity.

The author identifies three reasons for this:

• Leadership teams don't have the same motivation to train and develop precarious employees
• Workers experiencing precarity are less likely to be invested in the organization and its long term success
• There is a ripple effect on permanent, non-precarious staff as they see how precarious workers are treated by their company and are more likely to be concerned about how well they will be treated in the future

The author also writes about the link between precarity and reduced physical and psychological safety as employers are less inclined to invest in exceeding health & safety standards and workers are more like to experience high levels of ongoing stress.

But the kicker for me is this quote from the International Labour Organization of the United Nations (ILO): "The use of temporary workers can over time erode the motivation that workers have to contribute to the organization, and can lower the level of ability available in the organization to innovate or in other ways contribute to firm performance."

This made me think about the companies I've worked with over the years that had tried to increase their delivery agility and the relative differences in success between those which had few precarious workers and those which had much more.

While I wouldn't consider it the sole cause, it is safe to say that those companies which had a higher percentage of workers in precarious positions were more likely to struggle with the transition, especially the organizational commitment to ongoing continuous improvement.

Precarity reduces safety, and without safety, nothing else matters.

I read a number of project leadership books each year but usually I find only one or two which really make an impact. Professor Bent Flyvbjerg and Dan Gardner's book "How Big Things Get Done" is one of the latter.

I have never had the opportunity to lead a megaproject (the term is typically used for those with a budget in excess of $1 billion), but over the last fifteen years I have read a number of the articles published by Prof. Flyvbjerg on the subject and always learned lessons which were applicable to the projects I was involved with.

In the book, the authors provide many case studies supporting eleven heuristics derived from Prof. Flyvbjerg's decades of research into large, complex projects. While the term "heuristic" is apt as each is a useful mental shortcut, they could also be used as principles.

Given that twenty-two out of the twenty-three categories of the projects evaluated are physical projects (e.g. construction, mining, aerospace), it is tempting to assume that these heuristics are only relevant to projects delivered with a predictive approach.

That would be an invalid assumption as out of the eleven heuristics, I found that most are equally applicable to adaptive delivery. Here are just a few which fit well.

Hire a masterbuilder: we want to have someone with significant domain experience and a proven track record of success leading the work. Whether we are looking to fill the role of a project manager, an agile lead (e.g. Scrum Master) or a product owner, relevant experience and knowledge are critical.

Get your team right: The first value statement in the Manifesto for Agile Software Development is "Individuals and interactions over processes and tools". And as Prof. Flyvbjerg states, the main job of the masterbuilder is to pick the right team members to get the work done.

Ask "Why?": While the scope of a project is expected to emerge over its life when using an adaptive delivery approach, it can be a fatal mistake to not spend sufficient time upfront identifying an expected end vision. This North Star enables the team to challenge work items which will not achieve the desired outcomes and reduces the likelihood of an adaptive delivery approach being a random walk to nowhere.

Build with Lego: The idea of creating large systems from smaller components is a natural fit with the incremental nature of adaptive delivery. When a team takes a large work item and figures out a way to slice it into smaller pieces which still individually deliver value they are applying this heuristic.

Think slow, act fast: On the surface, this heuristic sounds like an invitation for big, heavy, upfront paper-based planning which agilists eschew. This is not what Prof. Flyvbjerg is advocating. What he is recommending is to reduce the cost of trial and error by taking the time to identify key areas of uncertainty which could impact successful delivery and to learn and find ways to address them effectively as early as possible in the project's life cycle. The examples which are provided about how Pixar plans its films or how Frank Gehry designed the Guggenheim Museum in Bilbao both demonstrate early de-risking which is a core attribute of adaptive delivery.

Say no and walk away: Prof. Flyvbjerg highlights the importance of focus when delivering complex projects. If an action does not contribute to achieving the project's outcomes, skip it. This aligns well with the tenth principle of the Manifesto: "Simplicity--the art of maximizing the amount of work not done--is essential."

While I have not covered all of the heuristics and their adaptive delivery applicability in this article, I hope that I have encouraged all of you to read this book, regardless of the domain or the approach used to deliver your projects.

A question was posed on my Mastodon instance this morning about combining the roles of Product Owner and Agile Lead (e.g. Scrum Master). The requestor felt that this was a bad idea but wanted to get feedback on whether it was, in fact, possible to do so and under what conditions would it not cause problems.

To answer the question, we need to understand the responsibilities of each role.

The Product Owner has the responsibility of collaborating actively with stakeholders to help them prioritize all the potential needs and wants which might be addressed by the product or service. They are also expected to spend significant time working with the delivery team to ensure they have a clear understanding of these needs and wants and to provide ongoing feedback on product ideas and completed work items by the team.

The Agile Lead is responsible for supporting the team in becoming as effective and efficient as they can be. While the role might facilitate delivery events (e.g. daily coordination events) for the team, their greater value is in the positive changes they are able to catalyze outside of these events. While they are expected to have sufficient delivery expertise to advise the team when they need assistance, the team is expected to define their way of working.

Based on these two sets of responsibilities, there are two main concerns with having a single individual play both roles: knowledge and capacity.

An effective Product Owner is expected to have sufficient product domain knowledge and organizational awareness whereas an Agile Lead is expected to have sufficient breadth and depth of delivery experience. It is rare to find an individual who ticks all of these boxes.

Most of the Product Owners I've worked with are overwhelmed just in their roles with the responsibility of spending enough time engaging with stakeholders and understanding product domain changes along with supporting the team daily. Adding the Agile Lead responsibilities to this mix usually means something will slip which could result in valuable input into product feature prioritization being missed or the team being neglected.

So is there any circumstance where the roles would be combined?

When a new company is formed, unless the leader has sufficient confidence, funding and foresight to fill positions appropriately right away, it is common that the leader plays both roles for at least the first product or service launch. However, in most situations, as the company grows, the leader recognizes fairly quickly that they need to step out of the daily tactical work of delivery and will staff the two roles.

Are there other contexts where you've seen this work? If so, leave a comment below...

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.

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