Projects and Icebergs

Once, I watched a class being taught to a small group of children. The subject was Aikido, an ancient martial art which utilized much inner energy, or ki. The instructor used an analogy to show internal versus external strength. ‘Ki’, he said, ‘is much like an iceberg. There is a tip, which is visible, much as external strength, which uses muscles; then there is the internal strength, which is at once much greater, and yet hidden.

…

When he had completed his explanation he asked, ‘Are there any questions?’ A small boy of perhaps four or five years raised his hand. ‘What’s an iceberg?’” --Steve Perry “Matadora”

Software development projects hinge on many things. The makeup of the development team. Resources that can be committed to the project. Management and stakeholder buy-in. However, the biggest problem I've seen is communication and the biggest communication problem I've seen is defining terms so that everyone is using a common lexicon.

Some years ago, I was part of a development project that was a miserable failure. The six month project was still in development after two years and eventually a competitor beat us to market. Looking back on it, the core problem could be distilled down to the fact that no two groups of people agreed on what any phase of the project meant. It’s not that anyone wanted to skip defining the project work or goals, or wanted to skimp on testing, or even that no one wanted to go through the time to meet to discuss project progress. The problem was that no one agreed with anyone else on how to define these aspects of a project or what should be done with them.

To some, “Testing” meant developers testing their work, and nothing else. To others, testing meant focus groups. Some thought that the project goals could be adequately communicated in a Project Charter document, others wanted to have agile-like meetings to discuss goals. And no two groups agreed on what “Finished and ready to deploy” meant. One group thought we were building an ecommerce site while another was adamant that the site should not handle payment transactions. One group defined “Deployment” as a full release that would allow all customers to begin using the site. Others defined “Deployment” as a limited release, similar to a beta test.

Even worse, there was no common definition of project roles. Sure, there was a project manager, product owners, executive stakeholders, a dev lead, and QA staff. We hit all those bullet points. The problem was that no two people agreed on what these roles meant. Because of that we had the dual problems of nobody performing certain critical tasks while stakeholders were fighting over how other tasks should be handled because multiple groups believed that the task was theirs to do.

As a result, work stagnated as developers began undoing work that one group had requested. Frustration levels ran high and developers began dragging their feet on work they didn't see a point in doing, knowing that someone else would soon have them undo the work. Testing was a mess as some groups refused to test functionality, thinking that was the developers job, and others submitted the application to a focus group and expected any feedback to be addressed. Finally, the project died when developers started leaving for other jobs.

I want to take a moment and underscore that last point. Not only did a lack of common definition of concepts cause the failure of this project, but it hindered future development projects due to development staff leaving the company.

In contrast is the project I’m on now. Development is going to take at least a year and a half and the resulting platform will have implications far beyond the current business need. We are coordinating three different business units with similar, but not identical needs. Work will be performed by four parallel development teams working separately but coordinating with each other. And this is all possible because before we even began gathering requirements we defined every project concept we could think of so that there was no misunderstanding. The definition of each project role. What "Scrum" and "Agile" meant in the context of our project. And, of course, the definition of "Project Complete".

As a result, milestones have become easier to hit. Not easy, mind you, just easier. We have agreed on what "Acceptance Criteria" and "User Story" mean so that when we do requirements gathering we all know what information is to be presented and in what form. Development milestones are easier to communicate, since we all know what to expect of code that is “Ready for sprint review”. When we talk about testing, we have agreed on what that means. Now everyone knows what has happened at each testing stage. As a result, the state of the code is clear at any given step. We have agreed on what it means to release code to production and we have a clear definition of what it means for this project to be finished.

Better yet, we have a common agreement on all project roles. Because we took the time to define “Product Owner”, we know what to expect from that role. Those responsibilities are clearly documented. As is the meaning of “Project Manager”, “Project Architect”, “Development Lead”, and “Business Analyst”. We know who does what, what to expect from whom, and to whom to look for any needed deliverable.

Of course, a common definition does not guarantee success. Agreement on terms doesn't remove the work of meeting project milestones. Because of the common lexicon, though, we can take a look at any part of the project and make a determination of whether or not it meets the definition it is supposed to. If two parties disagree on whether or not the definition has been met, we know exactly who makes the final decision. If that decision is that the definition is not properly met, we know what needs to be changed and exactly who is responsible for making the change.

Communication is one of the biggest single points of failure in a software development project. Nothing can tank a project faster than misunderstandings or people not clearly communicating their understandings and expectations. But before you can clearly communicate, everyone on the project must know what an iceberg is.