We in the software development industry face a seemingly intractable problem. We have learnt the lesson that prescriptive process is a bad thing. Process bureaucrats sitting in ivory method towers, telling highly-skilled professionals how to do their job and setting the process police on them if they don’t follow their instructions to the letter, can (unsurprisingly) be really quite damaging. It disempowers the development team and engrains apathetic attitudes along the lines of “When we inevitably under-deliver, it will not be our fault, but the fault of these ludicrous process hoops that we are forced to jump through, instead of being able to focus on writing great software”. The agile revolution was software engineering’s way of learning this lesson, and the agile manifesto pledge to value “people over process” and “software over documentation” has got to be right. But (… there was always a “but” coming …), we are already finding that the opposite extreme of little or no explicit process isn’t going to cut it either, because it leaves too many problems unsolved, such as:
- Avoiding Confusion – there is a big and noisy world of competing processes and methods out there. How do software development teams find the right practices for their specific needs?
- Team efficiency – do we really want our development teams to constantly have to reinvent new solutions to old process problems when they should be focusing on writing great software?
- Supporting Diversity – some software engineers need / want more explicit practice guidance than others. How do we provide just enough guidance without being overly prescriptive?
- Consistency – if every team works differently, how do we get resource mobility / flexibility?
- Governance – how does the sponsoring organization manage the risks associated with its investments in software and ensure visibility of progress towards a successful outcome?
We face the following Hegelian Dialectic (I graduated in philosophy – you have to humor me!):
- Thesis: Prescriptive process kills the golden goose (development team creativity and motivation)
- Antithesis: Removing the prescriptions can distract, confuse and frustrate the team and its stakeholders
- Synthesis: We need some kind of smart practice framework that enables us to provide clear direction on what needs to be done and just enough default standard guidance on how to do it, but enables teams to easily refine or replace practices that are not exactly right for them.
This smart practice framework is known as a process kernel. In this short series of blogs I will describe in a little more detail at what a kernel is and report on my experiences of using process kernels in practice to enable my customers to find answers to some of these seemingly intractable process problems.