The Kernel Journals 5: Making the Invisible, Visible

The Kernel Journals 5: Making the Invisible, VisibleThe kernel Alphas are the core, key, critical, central, essential conceptual entities that we need to manage and progress in a controlled way in order to ensure a successful outcome for our project. But, like all concepts, they have the distinct disadvantage of being invisible. A project manager is convinced that his project is important and that managing its progression to a successful conclusion is critical. But if, as an outside assessor, I were to say “bring me this project of which you speak so that I may gaze upon it and assess its status” he would be stumped. He can show me plans, people, documents, but he can’t show me “the project”. These key concepts are the elephants in the room that no one can see because …  well , because they are invisible. To be useful, they need to be made visible and real, so normal people can interact with them.

In our first blog I talked about how domain models can be used to simulate the execution of a business by adding attributes to them and slapping a few crude user-interface screens over them. And we can do exactly the same with the Alphas that are the domain entities in our software development process kernel. This has become known in my sad, process-geeky world as “skinning the kernel”.

A great way to get a quick-and dirty but fit-for-purpose “skin” in place is to use a Wiki: one Wiki page for each required view onto the alpha states and attributes. Wikis are useful because they solve many process problems in one:

  • Where do we put our key information as we gather it?
  • How do we communicate the information to all our stakeholders?
  • How do we get agreement and consensus?
  • How do we record key agreements and decisions?

We capture the key project information where people can see it, contribute to it, refine it and agree it.

To help projects focus on the key project information (the Alpha attributes) and to help them to capture it in a simple, structured, concise and consistent way we can provide a simple set of Wiki templates. (After all it’s better to have a template than to make each project start from scratch with a blank Wiki each time).

(But wait, oh no, not templates!!  We’re not supposed to use templates, because we are recovering document template addicts. How are we going to we stop ourselves becoming addicted to this (admittedly small, lightweight and relatively harmless looking) set of templates?

Fortunately, we already have the antidote in place. Our templates can’t become ends in themselves, because we know that they are only a means to the end of progressing the states of our key Alphas. We can easily define who needs to assess which states and when (e.g. “the product owner needs to agree the target date and scope of the next release before we start incrementally developing the product release”). We then close the evidential loop by stating where the evidence is to be found:  “based on the information in the Wiki Project and Requirements pages. If the assessing party is happy that the progression has been achieved, based on the evidence they see, then the progression has been achieved (even if there is the odd spelling mistake on the Wiki!).

So now we have a simple way of executing our development project by capturing the information we need to progress our project in a controlled way to a successful conclusion. And, once again, this is more than just process theory. I have seen many projects use this approach to reduce their documentation overheads from dozens of documents totaling many hundreds of pages (which of course virtually no one ever read) to a dozen or so Wiki pages which told everyone exactly what they needed to know about the project and its status, when they needed to know it (including CMMI SCAMPI C appraisers in one case, as it happens).