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