Stop the Madness and Frankenstein Projects

My apologies for the delay in the posting but I was under  the weather and also basking in the glow of the Packers SuperBowl victory. I know I stated that the next post would be on why the testing phase is so hard to let go of, but during a discussion with a colleague at Protegra we came up with a perfect metaphor for Waterfall or Traditional projects: A Frankenstein project. Please indulge me:

The Frankenstein Project Body Parts

The Torso: The Frankenstein Torso is the project structure itself. Not the business problem or the project objectives but just the overall structure that is required for the Traditional project to function and execute. This can be thought of as the project methodology, processes, and procedures. (yes the excessive meetings are part of this) In general, it is this body that holds the project together for good or evil. (Author’s note: copious foreshadowing)

The Left Arm: The Left Arm is the limb closest to the heart of the project and as such is the Business users. This arm defines the business objectives, outcomes, reasons, and rationale for the project being required. Unfortunately this arm has to be connected to the project in some way. Traditional projects have chosen this stitching to be in the form of extremely detailed documentation and business user sign off. Unfortunately this arm was grown in a lab separate from the torso, so the parts don’t match 100%. This is addressed by more detailed documentation and eventually the arm is attached.

The Right Arm: The Right Arm is closely connected to the Left Arm and represents the analysis required for the project. (This can be both Business and Systems Analysis) This is the translation of the Business objectives, outcomes, reasons, and rational for the project into Software Development Requirements. This arm is again connected to the torso by the Traditional Project artifact of documentation. Unfortunately the Right Arm was also grown in a lab separate from the Left Arm using mainly the documents used to attach the Left Arm, so the parts don’t match 100%. (Although the Left Arm and Right Arm do look somewhat similar) This is addressed by more detailed documentation to address the inconsistencies and eventually the Right Arm is attached.

The Left Leg: The Left Leg is the critical part of Software Development for the project. This represents the Software Development required to translate the Software Development Requirements into actual code. The code deliverable itself is what is used to connect the Left Leg to the torso. It is actually a pretty good stitching job but by this time the Left leg is not looking at all similar to the Left Arm. Oh dear.

The Right Leg: The Right Leg represents the critical part of testing on the project. Unfortunately the Right Leg can only be attached after the three other limbs are attached fully. The Right Leg is attached via the test cases that are generated from the documents that were used to attach the Left Arm and Right Arm. The stitching is looking pretty inconsistent with some areas covered quite well and others not so much. The Right Leg is really looking dissimilar to the other limbs. The other major problem is that the Right Leg is only half the length of the left leg as we ran out of material; The Schedule. I believe the project will have a limp.

The Head: The Head represents the architecture of the project. It is the Architect that is trying to put together these different parts and produce something that satisfies the understanding of the desired outcome both from a functional and technical point of view. The unfortunate thing is that the Head does not look at all similar to the Left Arm. It is similar in functionality but not intent. Typically the brain that Igor found for the Head is from a brilliant technical person who doesn’t quite understand the business domain. Pity.

The Mad Scientist: Ah yes, the Mad scientist. By now you may have surmised this is the Project Manager. 🙂 He or She is trying to understand all the issues that come with piecing the parts together from different parties but at the end of the day there is a fixed budget and thunderstorm coming to bring the beast to life and we need to make that date. He or She feels they need to come up with the solutions and push the team forward. We don’t need collaboration and team problem solving. He or she will solve the problems and then we just need more Igors!

At the end of User Acceptance Testing when the thunderstorm arrives to bring the beast to life, we really have the ultimate big bang implementation. The beast lumbers to life, crashes through the walls, and pillages the village of business users. The project did not resemble what was intended and the villagers are now rioting demanding the head of the Mad Scientist. Sequestered in his Ivory Tower away from the users, he wonders how it could have gone so very wrong. It seems the business forgot to quantify the non functional requirements.

Eventually the Mad Scientist and the Business write-up a plethora of Change Requests and a good part of them require the removal and re-attachment of the entire limbs. Some require parts of the limbs to be replaced. An elbow here, a knee there. Oh dear, the project is looking even worse than before.

Finally the tamed project lumbers out and does the base functionality that was intended in a way that is not elegant or satisfactory. But we have produced something and on the date! And the business did sign off after all!

Next Post: To build a better Monster.

Advertisement

The obsolete supervisor

I know I was planning to write a post on how hard it is to let go of the concept of a testing phase, but an article I read today really caught my eye. It was all about how hard it was to manage off-site staff. It really resonated with me as it discussed how you supervise and manage people that are offsite. The article relied so strongly on only traditional methods, it could have been written in the 60’s or 70’s. As I read the article it seemed to imply that if you worked with job descriptions, set performance goals, measured progress by deadline and milestones, and created a reporting structure everything would work out ok.

It is articles like this that make me wonder how far we are away from working with people in the manner that Agile proposes. It is so common for people to use the manager and supervisor term and interchange it with the leader term. I firmly believe leadership has nothing to do with status or role and is all about action and initiative. In many projects I have been on, many developers have been better leaders than I. The supervising and managing of people is a holdover from when we believed people were not wanting to do a good job and they needed someone to ensure they were not slacking off.

Leaders on projects provide value by managing the process, not people.  Then together with the entire team they collaboratively discuss the vision and create a plan to achieve that vision.  Leaders assist the team in removing barriers and resolving issues so that the team can succeed and achieve the goals they set together. No where in the article did it mention the value in having the employees together building the collaborative plan. We have to change of thinking that leaders create the plan and bring them down from on high to the people assembled and then instruct them on what tasks are required. Is it any wonder people lack motivation to achieve the goals when it is introduced in this manner?

When people together build the plan and understand the reason behind what it being done, breakthrough performance results. Supervisors are only required when those team visioning and planning activities do not occur.

One of my favourite quotes captures the essence of this discussion:

“If you want to build a ship, don’t drum up people together to collect wood and don’t assign them tasks and work, but rather teach them to long for the endless immensity of the sea.”  ~ Antoine de Saint-Exupery

What does Born Again Agilist mean and what is the purpose of this Blog?

Good Afternoon, my name is Terry Bunio and I have a confession to make I love Agile Project Management but I still have doubts. I have a long history of managing both agile and traditional projects, and I’m hoping this BLOG can fill a void out there in the Blogosphere. I haven’t drank the juice that has convinced me that everything agile is always the way to do things and works 100% for all clients and all projects. I want to use this BLOG as a forum to discuss those issues and share with people my thoughts on what works and what doesn’t work. I also want to share concise, concrete stories instead of just talking about the high level principles and concepts that are easy to agree with. I want to provide more value so that people who read the BLOG will have real world stories that they can benefit from and apply immediately.

Some of the questions I struggle with and will discuss are:

  • How to estimate an Agile Fixed Price Project?
  • When functional specifications are required?
  • How can you do AMS and Package Implementation in a Lean way?
  • When is incremental development better than iterative?
  • When is Planning Poker appropriate and when isn’t it?
  • When are visual boards not enough?

And more…

Tomorrow I’ll discuss my journey away from agile into incremental, which I thought was iterative at this time. 🙂