Deploying Lightweight Processes

Pete McBreen
McBreen.Consulting
email: petemcbreen@acm.org
http://www.mcbreen.ab.ca

Deploying effective lightweight processes in organizations is much harder than it would at first appear. There are many different issues that need to be addressed and few of them are technical. In common with most significant changes, they are mainly cultural, social and inter-personal, which means that they are not amenable to a quick technological fix. My position is that we need to recognize that deploying a different development process takes time and that developers will become comfortable with the new process on different schedules.

Interesting issues to consider

• Will all developers switch to the new process? - This has at least two parts, being willing to switch and being able to switch, and the time it takes for each developer to decide to switch and then becoming comfortable with the new process
• Changing to a higher discipline process - typically lightweight processes need to be followed with a higher degree of discipline than heavyweight processes since there is less redundancy. Unfortunately developers and managers are not often made aware of the consequences of working off-process, so have no real experience of following the discipline of a process.
• Lightweight means inferior - For some cultures, calling something lightweight is a form of insult. Hence a lightweight process is seen as inferior and only to be adopted if all else fails.
• Changing the process takes the familiar landmarks away - So managers are left without their usual control mechanisms and develoeprs do not know what is expecrted of them. Adding elements from the old process into the new lightweight process is a common result, giving a hybrid that is worse than either of the two.
• Software is not that simple - doomsayers accompany any change, and they have lots of stories to tell about the bad old days when programmers just jumped into coding.
• But this is not XP - A common complaint from websurfers who have not read the literature and think that the only lightweight process is XP.
• But we cannot do XP here - because the mythical they will not let us. Resistance to XP is useful as it allows us to talk about other processes.
• We need an acceptable way of failing - so following accepted best practices is the only option since we need to be covered in the (unlikely?) event of failure ... but with that attitude failure is even more likely.
• Change is expensive so we must get it right first time - this myth that arose from Boehm's early work has been a major hindrance to the adoption of all incremental processes.
• I don't need to do that practice - what room is there for personal process variations in a lightweight process?
• Coercion or concensus? - When is it OK to impose a new process on a team? At what point do we say that developers and managers have had enough time to switch?
• Perfection or pragmatism? - Should we aim for best practice, or just to be better than we used to be?
• Is the new way any faster? - Who is to say what is better if we do not have any metrics from the old process? Should we spend time measuring the old before changing?
• Why can't I just do my job? - Why change?
• Why do I have to learn this? - Surely the old ways are good enough?
• You mean you want me to ... - a startled expression of horror as a developer or manager discovers that a change to the process means a change to their minute by minute, hour by hour routine.

Thoughts? Questions? Comments?

The above issues are not exhaustive, but they cover a reasonable sample of the issues that have come up over the last year or so. Addressing these issues was not easy, since many required thinking about how and why we develop systems in the first place.

After thinking on these issues my current hypothesis is that "software engineering" is an inappropriate metaphor for what we do. Currently I'm leaning towards a Software Craftsmanship metaphor as a way of addressing the issues raised above.