The kernel Journals 10: The essential does not change

The kernel Journals 10: The essential does not changeIn the previous kernel journals we have explored the value that development organizations can get from a process kernel that codifies what each and every project always has to do, in a way that is distinct and separate from how different project teams might choose to go about doing it, some benefits being:

  • The status and progress of diverse projects can be made visible and tracked in a consistent way
  • The overheads associated with evidencing (documenting) project progress can be minimized and does not become an end in itself
  • No teams need unnecessarily reinvent process wheels – teams  can be provided with demonstrably “necessary and complete, but minimal” practice guidance on how they could achieve everything they do actually always have to achieve
  • Teams can be pointed to one or more alternative tried and trusted ways of achieving what they are trying to achieve on their project here and now
  • Process need be prescriptive no more - teams can be empowered to adapt any specific aspect of their way of working in the light of their project circumstances and team experiences
  • Teams can try out new ways of achieving specific things and add them to the corporate memory banks for others to find and use if they work well
  • The fitness-for-purpose of a team’s adopted and adapted way of working can be easily assessed.

The Key to achieving any and all of these benefits is the fact that the kernel is a shared, useful and generally accepted description of the essential aspects of all each and every project within an organization, where essential means:

  1. Critically important and
  2. Invarient

IJI has provided its customers with just such a standard process kernel and supporting practices over the past four years and have enabled them to reap many of these benefits as a result. Other process suppliers (such as IBM and the Eclipse Process Framework (EPF) consortium) are also converging on a similar “kernel plus practice” approach to structuring, presenting and deploying their process offerings.  Currently, the exact nature, shape (and even the names) of the underlying process kernels varies from process supplier to process supplier. If practices from different sources are to be made available to teams as interchangeable pieces within the picture of a team’s preferred ways of working, it is clear that we as an industry need to define and agree some standards for these process kernels.

Standards, standards, standards.  Frankly, the heart sinks at the very sound of the word. However, it really, really, really has got to be a lot easier to arrive at a shared consensus on what all project teams have to do, than it has ever been to achieve any kind of consensus on how they should go about doing it. All software development projects really do have a stack of stuff in common. All we have to do is codify it well.

Just to pluck a few examples of where supposedly warring parties more than agree:

  • We all talk about software development projects and agree about importance of key project milestone dates such as software release dates
  • We all talk about software being a team sport and emphasizing how important team and stakeholder communication and collaboration is to the success of this endeavor
  • Many of us talk about the need to control project progression by iteratively by incrementally preparing and verifying sub-sets of the product release (although some of us tend to call these “iterations” and others “sprints”)
  • Most of us talk about the expedience of achieving early agreement on a vision or scope-level view of what needs to be achieved in a software release, without attempting to predetermine and cast in stone everything about the functionality and behavior of the release(the detailed requirements)

This list of things we all agree on is easy to write and could very easily be made a lot, lot longer. And this should not surprise us, because the various processes and practices out there all share the same problem domain after all. And just beneath the surface we so-called methodologists are all experienced campaigners with similar war stories to share.

If we can’t come together to codify this problem domain in a common way to help our mutual customers find, compare, contrast, select and use the right practices for the right jobs then I for one think it is a pretty bad job.

This is the job that the SEMAT consortium is now embarking upon. I hope you will join us.

P.S. For those of us for whom “the obscurer the better”, “The essential does not change” is a quote from Samuel Beckett, which has certainly those of us well-versed in the Lockean and Berkleyan metephysics rolling in the aisles (I told you’d have to humor me!)