In the previous kernel journals we have looked at the many practical applications of a process kernel that is based on the key software development entities (known as Alphas) that software projects add value to by progressing through their value states. We have seen that there are many advantages to separating these “whats” (progressions) that we are trying to achieve, from the many possible “hows” (software processes and practices) that describe how we might achieve and evidence these progressions, including the ability to set objectives and track progress in a common and consistent way irrespective of what specific practices a project happens to adopt.
So, our kernel gives projects advice on what to achieve (first / next) without providing any specific guidance on how to achieve it. This is both good (because we are not telling software development teams exactly how to do their job) and bad (because we aren’t giving them any help at all on how to do the things that they have to do).
Clearly there is no shortage of advice out there in the form of the myriad of competing software development processes. But we have seen that they have traditionally suffered from being somewhat monolithic (“all or nothing at all”), and while many contain much useful practice guidance, it is difficult to find and use the specific piece of guidance that we need without getting tangled up in a huge, prescriptive process web of activities to follow and artifacts to produce (and templates to complete).
What we need is a way of accessing process guidance that enables us to find our way straight from what we are trying to achieve here and now (such as establish a shared understanding of the value and scope of a software system) to specific guidance on how we can achieve it (e.g. with use-cases and use-case scenarios).
This is what IJI have done with their EssUP process – provide access to guidance on how to achieve something, that is accessible directly from the progressions that we know our project has to achieve first / next. And we have provided this guidance as a set of modular practices, so that if an organization or project does not like a particular practice (such as the use-case practice), they can “swap it out” and “swap in” a different practice into the same process space instead (such as a traditional declarative-requirements practice or a user-story based practice).
Organizations are now free to choose the balance that is right for them between process consistency and process freedom. At one end of the scale an organization can provide a single set of cohesive practices that provide just one single standard way of achieving all the things that projects need to achieve. At the other end of the scale, they can allow projects to select any “hows” they wish from any practice guidance that is “out there”, and to freely refine and evolve these working practices over time. A project, for example, might choose to scope its system with a use case diagram and then drive the development and test of the system with user stories. Furthermore, as we will see in the next kernel journal, we always know whether the process guidance available to a team “covers all the bases” or not (i.e. whether there are any spaces left in which people are expected to “just wing it”).