This is the first of many letters from Screwdisk to his protégé Virus[1]. I make no claims to the authenticity or accuracy of these letters, other than they ring true with what I have seen in the field over the last 10 years. Some of what you will read may sound a bit too familiar. It has me wondering if I have ever unknowingly been on a team with Screwdisk or Virus. I have never been able to find out who Virus and Screwdisk really are, but from what I've seen they could have been at many different organizations around the world - maybe even yours.
My dear Virus,
You were a very down in your last email; don't be too worried that your organization has just had a successful Agile pilot deliver on time and under budget and is the talk of the town. Yes, it is unfortunate that they have released their product ahead of our clients. It is sometimes very difficult to get that first team to fail because the individuals on that team tend to be very motivated and, in your case, they had brought a very experienced Agile coach to help them through. This is, after all, only one release of one product, and I have reassured our clients that our goal is to completely sabotage their competitor and not just one project.
In fact, to look at this glass half-full, the success of an Agile pilot will allow you to have more influence in how the entire organization adopts Agile. Proper adoption of Agile values and principles is the one thing you must prevent! Fortunately, it is not very difficult to appear to practice Agile while in fact creating a cargo-cult [2] that will take years to run its course and actually make things worse than they are now.
Take heart, your chance will come soon since, as a member of the successful Agile pilot, you will be ‘farmed out' to other teams to be their resident Agile expert. I suggest you start thinking about building the foundations for success right now. As you know, what makes Agile so dangerous for us is that it builds upon personal strengths and creates all-too-often a high performance team. What many conveniently forget is that, at the core of successful Agile teams, are the individuals on the team and not the process and tools. I always have to laugh at how easily people trade the important for the urgent in their rush to be successful.
So, I understand you have the opportunity to help choose the members of your next team. Do your best to get the least talented folks in communication and human interactions. It is a little known rule that a team can only be as effective as its least effective member, so it won't be hard to do. In general you want to find non-team players, those who will undermine the effectiveness of the whole. Those who will never pick up things that are not in their area of expertise. Those who believe that they can succeed no matter if the team fails to meet its goals or not.
Good candidates are those who are full of pride - arrogant ‘experts' - who will never compromise in their work because it is - naturally - the most important part of any project. Or, if you can't find arrogant experts, those who are always afraid of looking bad are also great candidates. They don't realize that teams learn by failing and that mistakes have to be made if a team is to succeed spectacularly.
One of my early successes involved just such a case; I nominated one of the top developers to lead a mission critical team to build a piece that would make or break a long term project. He was brilliant and regularly built the most difficult components in several previous projects. He was also young, and thought that success meant getting the best technical solution - which almost always tended to be his solution. So, when he took charge of the project, his ‘vision' was the only thing that mattered. He promptly annoyed, alienated, and/or intimidated the rest of his teammates and many of them shut down and stopped contributing in full. Because he could not be everywhere and build everything himself, the parts never came together correctly and many problems that were ‘between responsibilities' weren't addressed. Needless to say, the critical project was delivered late and was full of undiscovered errors that could have been tackled early if someone else was leading the team. Our true clients were very pleased as their competitor failed to get their product to market on time and then suffered from poor customer experiences.
You can also look to the type of person who will never keep quiet, and others who stew without ever saying what's on their mind. Both of these types of people will break down communication and handicap the team. They will impede learning and will each, in their own way, maximize the possibility of a team going in the wrong direction for an extended period of time.
One of my more challenging projects was one that had excellent leadership, experienced and friendly team members, and executive support. It was almost a no-win situation; they were made to succeed. My opportunity came when I was able to influence the addition of a team member whom I knew to be afraid of failure and was not the best of communicators. Eventually she took on a task that was too much for her, and instead of going to the team for help or admitting that she made a mistake, she covered it up and moved on. This, of course, happened more than once, and little mines were planted throughout the project. Luckily, one of those mines wasn't so little, and by the time it was uncovered an entire subsystem had to be rewritten and the project missed its deadline. There is always a way to undermine projects, no matter how good the team is. One individual and a little luck is all that it takes!
These attributes are the building blocks for failure in any team no matter how technically talented they are. My boy, don't underestimate the value of the individuals on the team. Getting at least one wrong person on a team will go a very long way towards the team's inevitable failure and our success. They will undermine communication, trust, and will reduce the chance of any software development practice - Agile or otherwise - has of success.
In my next letter I'll tell you more about what you can do to undermine a practice or two early in the team's cycle while at the same time seeming to ‘be Agile'.
Your proud mentor,
Screwdisk
[1] The idea of a version of the Screwtape Letters for Software Development is that of Ashley Johnson of Gemba Systems. And, of course, the inspiration for Screwdisk, Virus, and the letters themselves come from C.S. Lewis' Screwtape Letters.
[2] During World War II a number of airbases were built on remote tropical islands inhabited by pre-industrial societies. During the war soldiers built airfields and control towers and engaged in various activities that resulted in large airplanes full of cargo landing and discharging their contents. The native inhabitants shared this cargo. After the war the soldiers departed and no more cargo was available to the natives. So they adopted, as best they could, the superficial form of airstrips, control towers, and ritual behaviors intended to induce the return of planes full of cargo. A cargo cult is any group that adopts form instead of substance and believes that doing so will bring about a desired result.
