The Wormwood Letters: a project management allegory (and tribute to C.S. Lewis)
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.
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.
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.
Re: Weekly Project Update #3
from: Proto@lenture.comRe: Weekly Project Update #4
from: Proto@lenture.comRe: Weekly Project Update #5
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,
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.
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.