The Wormwood Letters: a project management allegory (and tribute to C.S. Lewis)

#1

The demise of an Agile practice can take many routes, but it struck me recently that the steps it takes to get to collapse read like an outline of C.S. Lewis’ Screwtape Letters. Many of the things that Screwtape advises Wormwood to do have perfect parallels in the very things that Agile practitioners find themselves either fighting–often failingly–against, slipping into, or doing overtly and erroneously.

Below are a series of postings that were a little too off-beat for my regular blogs. They are in the form of of “emails” written as much as an homage to C.S Lewis as they are a satirical exploration of the ways an Agile practice can fall apart. The setting I will use will be a series of emails from a senior project manager to his young protoge. They represent a project management vendor working with an unnamed software company that is trying to become Agile. This series is by no means supposed to be a condemnation of vendors or even of waterfall. The vendor and the machinations of the senior project manager in this case represent the forces that negatively impact an Agile practice-new or established.

to: Adev@lenture.com
from: Proto@lenture.com

Re: Weekly Project Update #1,

Thank you for your timely update on introductions with the new client. I had heard that they were dabbling with this agile methodology. It is no trifling matter, but that you have recognized at such an early stage in our relationship with them what an “Agile mindset” could do to speed up the project or even end our contract early is most excellent. We have to be methodical and deliberate at this point. Whatever you do, do NOT engage the client in a debate over the merits of empiricism vs rationalism or Agile vs Waterfall. There is no outcome from that line of reasoning that will benefit us. The likely outcome will be the client coming to the realization that there is a fallacy inherent in assuming rational thought is sufficient for planning a project in its entirety while (and even worse, iMHO) thinking more and more deeply about the importance of using empirical information to plan a project. Instead, dazzle them with as many templates as you can. Templates keep them from thinking more deeply about Why they are building things the way they are and shift the focus to How they should populate the templates. The more branded the templates are, btw, the less likely they are to question them. Remember, our goal at this early stage is to give them the sense that forward movement is occurring by merely populating fields on documents. What benefits us is that they do not want to appear to be ignorant of these officious forms; therefore, use that to our gain. Make yourself the expert in their use. More importantly, do not let them consider getting to development earlier in the project and obtaining empirical data. This could lead to the realization that we are not needed for as long as we had proposed–or even at all.

Finally, use the term “process” as often as possible, and whenever you do, draw a pained and sorrowful expression as though it is the lost and holy grail that will deliver their project. Get them thinking about forms and flows and processes before any code is written. You job, right now, is to get them to believe that any code written without a thoroughly documented process agreed upon by multiple committees would be an utter waste of their development teams’ time. You are, after all, looking out for their best interests.

The future of Devlenture’s contract (and therefore your own), is in your hands.

#2

to: Adev@lenture.com
Re: Weekly Project Update #2

I see that the client is claiming to be Agile and even has an in-house Agile coach on hand–no need to despair. We can use the Agile “industry” to our own ends. There is enough weak or even incorrect information out there, that we can use in our own documentation to help confuse them. At worst, this diluted approach to becoming Agile will eventually wear them down. At best, they’ll give up on it altogether. Additional methods include seeking out other Agilists within their organization who are either failing at Agile or who are simply going through the motions–my preference would be the latter. Pit these people against one another. If they are still trying to become Agile, they will embroil themselves in petty battles about ceremonies and charts and data collection. If one side or another is actually embracing the principles of Agile, determine the chief Agilist within the group contracting us. You’re sowing discord here, so it’s merely a matter of making one group feel threatened by the other. Include comments like “Besides, their way of doing Agile only works because they have a unique, and frankly unrealistic workflow–unlike all the rest of the groups who actually get work done.” Here’s the finishing touch; praise the acts over the substance. When you see the agile team going through the motions of the various agile ceremonies, praise them as ”better than you have ever seen Agile practiced before.” Feign admiration and an Agilist will often forget about continuous improvement and choose to rest on his success.

Your mentor,
A.

#3

to: Adev@lenture.com
from: Proto@lenture.com
Re: Weekly Project Update #3

Thanks you for your most recent email. You sound like you are really digging in to the daily skirmishes. Well done. If your customer or business leaders are vexed and troubled with just day to day issues, don’t offer specific recommendations there–go back to dogmatic approaches. Just read the Agile Manifesto out loud again. Do not offer specific advice or coaching. Don’t encourage them to think deeply. Instead give them general platitudes that lightly address the actual problems at hand.

Our goal here is to frustrate them with what “Agile” has to offer and convince them that the generalities of Agile do not apply to their specific problem. Whatever you do, do NOT let them refer to any of the actual Agile principles, allowing them to make the connections on their own, If they do that, they will then begin to think more about the “Why” of Agile, and even worse, the “Why” of waterfall project management. Keep Agile at the heart of debate or they will begin to question the need for the large amounts of documentation we have worked so hard to convince them are necessary for us to meet contractual obligations.

With regard to all of that documentation, by the way. Always refer to contractual obligations in such a way that they feel that they are the ones who requested it. With any luck, you will have the opportunity to work with their finance team, their legal team, and their development teams individually. This will allow you to suggest that verbiage contained in the contract was requested by any of the other groups not in the room at the time.

If busy-work is our buttress against what the agilists refer to as “deliver, inspect, and adapt,” then paper-work is the brick and mortar.

Stay strong,
A

#4

to: Adev@lenture.com
from: Proto@lenture.comRe: Weekly Project Update #4

It is distressing to hear that they are sending more of their people for Agile training. Again, what we will be wise to avoid is allowing them to review the principles of Agile or any interaction with groups inside or outside of the company who actually have worked successfully in an Agile culture (don’t even refer to it as that–a culture–by the way. That is exactly the kind of thinking that will lead to them ignoring us and doing the work themselves). Instead, use mocking terms to refer to any Agile concepts and be sure to mock what a huge waste of time and money any Agile training or coaching would be.

Our goal is not to put these thoughts in their minds but to do the far easier task of keeping the understanding of an Agile culture OUT. The best way to do that is to convince them that a large scale single release project is the only possible way to deliver the value they are seeking. This will remove any focus from actually moving to an Agile culture, and put everyone in a heightened state of agitation. This invariably will send them scrambling for familiar methods such as large project planning meetings, however ineffective they have proven to be in the past. The more time you can keep them in planning and not actually executing, the more beneficial they will perceive our involvement to be. Safe and happy and optimistic, planning, imagining, but accomplishing nothing.

Stay loud,
A.

#5

to: Adev@lenture.com
from: Proto@lenture.comRe: Weekly Project Update #5

I could not help but notice in your most recent update email, your feeling of dismay at the client’s acceptance of moving ahead with the project delivering working software while learning from their mistakes. It sounds as though their Agile coaches have maddeningly made management and customers alike appreciate the value of failing fast and adapting. You must act quickly to put more focus on the negative impact of the failures themselves, so that the pain is all that the client can focus on. If that does not work, I recommend a strategy that is more sophisticated but one to which I feel you can arise. Simply put, do not let them fail–completely. At this point, I feel it important to clarify that it is not in our best interest for the project to ever end. Full failure would mean it is over just as much as full success. We want it to continuously morph and bloat until no one even remembers the intent of the project for which we were contracted. Your new goal should be to devise as many sub-projects as is possible to give the appearance that you hope to salvage those failures over a long and arduous process. This will prevent them from actually learning from failure. It will also reinforce the fear of failure culture from which we benefit so greatly. Schedule multiple and redundant meetings to “mitigate the impact.” Treat yourself to a little fun and devise acronyms for every one of these meetings. (It never ceases to amaze me how they will knowingly nod and immediately begin to unquestioningly parrot the name I have just made up out of fear of looking “out of touch with the latest in project management). The main point is to keep them so busy talking about risks that they cannot learn from the mistakes they are actively making.

Cheers to the monolithic Project,
A

#6

to: Adev@lenture.com
from: Proto@lenture.com
Re: Weekly Project Update #6

From our last discussion, it sounds as though your were successful in establishing irreversible fear of failure. Well done. Suspense and anxiety are our friend. Where the client is experiencing real anxiety, we can swoop in to be the voice of calm and reason–even if we are the root cause of that anxiety. This is our chance to get them to take the eyes off of delivery and focus almost exclusively on process. With any luck, the project itself will be brought to a halt by executives within the company for fear that they do not have a process that can be shared via slide decks or elaborate web pages. Further, keep the client focused on what could go wrong rather than on what they are actually doing. Revisit the Risk log as frequently as possible during these times. Get them thinking about as many different simultaneous risks as possible.

The Monolithic project is our friend. Keep them focused on the glory of a major delivery. Like a gnat that will not leave the gardener’s ear alone,–be a constant voice reminding them that Agile seeks only to deliver small value for which customers and executives have no need. Scoff at “incremental value.” You are gaining the upper hand now; therefore, the well placed authoritative chuckle at terms like “iterative delivery” or “early incremental value” will continue to fertilize the vines of doubt choking out any growth in their Agile practice.
Your Fellow Gardener,

#7

to: Adev@lenture.com
from: Proto@lenture.com
Re: Weekly Project Update #7

I am very relieved to hear that the client is asking about project management as a whole. With a subtle turn of direction at this point, you can showconvince them that Agile makes no allowances for full scale monolithic projects at all. No planning for training or marketing by outside agencies, no corss team coordination. At this point, the Agilist may mention Scrum of Scrums or DAD 2.0 or SAFe. Mock these openly. There are enough within the Agile community itself who cannot agree on scaled methods. Use this to your advantage and belittle them all.

It’s doubtful that your in-house Agilist ever claimed that Agile software development was the panacea for all aspects of project delivery, but the executives do not know that, and this is where you plant the seed of doubt. “Agile is really only for developers.” Once Business leaders, executives and customers believe that Agile does not apply to them, the poor Scrummasters will spend the next several years trying to convince the rest of the company otherwise. As most everyone else is accustomed to the trappings of “Delivery” associated with detailed Gantt charts, weekly status meetings, countless change management agreements, and so forth, they will fall back into the warm embrace of the world we control. Publicly pat the Agilists on the head and condescendingly assure them that one day they will find a way to make Agile work.

Confidently,
A

#8

to: Adev@lenture.com
from: Proto@lenture.com
Re: Weekly Project Update #8

I am beyond delighted to hear that management has decided to adopt a Waterfall Agile hybrid model. This means that they no longer hold any trust in the Agilists and view them as an appendage to the project. Well done.

This will shift the entire tide of the project in our favor; therefore, it is precisely at this time that you should begin to take credit for the successes that Agile helped deliver. Review the aspects of Agile that were working and co-opt them for our own use. If retrospectives were helping them with continuous improvement, have all team members retrospect on the project to this point. Do not call it a “retrospective,” however, but instead call it a “milestone checkup” or some such. If the team engaged in story mapping, add a line item early in the project plan and call it “Feature breakdown.” With any luck, the Agilists will raise a cry that these are Agile tenets, and they will be dismissed as whiners. Agilists have a delightful habit of being modest about their successes, sticking to “Delivery of working software is our primary goal,” so their success are easily re-attributed.

This will be our final correspondence. You work is done here. Go forth and continue to confuse and obfuscate in your projects. If you cannot do that, at least work your way into a role as a scaled model coach. No matter what, do not let teams or businesses learn the value of self-organization and focus on customer. If you do, the future of Project management Consulting is doomed.