Many software engineering teams have adopted Agile. However, teams delivering process change tend to use traditional ‘lifecycle' approaches and have yet to embrace Agile. Why is that? Can the Agile approach be used to implement or facilitate process change?
Achieving buy-in and support is much easier if the process change project mirrors the client organisation. Increasingly, these project teams are confronted with an Agile client environment utilising Scrum. This is prompting process change teams to ask the question, "Should we adopt the Scrum framework for our delivery?" The first port of call when considering this question is the four fundamental values of the Agile Manifesto ( http://agilemanifesto.org/). These values appear to complement the implementation of process change.
The first of these values is 'Individuals and interactions over processes and tools‘ . At first glance this statement may seem anathema to process improvement, but actually it is very much in-synch with how projects should be run. Change is about people, not process. In good process change projects the documents, processes and procedures you develop are merely tools to institutionalise best practice behaviours and smooth interactions between people.
One of the common themes in an improving engineering organisation is the prevalence of tacit knowledge and working practices treated as policy or procedure. Teams well down the process improvement path operate using explicitly defined procedures. As Michael Polanyi famously said, "We know more than we can tell". Engaging the individuals and understanding the interactions are fundamental to turning Polanyi's "Tacit Knowing" into explicit knowledge.
The value 'Working software over comprehensive documentation‘ is straightforward to match. We are not writing code; however, we do develop a wide variety of documents, processes and procedures to support the implementation of the process changes. The aim is to develop effective processes which can be tailored to the situation, but still ensure the necessary rigour to meet the goals of the organisation.
The risk with putting processes in place is that the process becomes the goal in itself rather than the process being a tool to support a specific organisational objective. Therefore, this Manifesto statement could be rewritten a number of ways, but "Working processes over bureaucracy" should resonate with most readers.
The third value is 'Customer collaboration over contract negotiation‘ . If we accept the purpose of process improvement is to institutionalise desirable behaviours, then the key to success is getting your customers to change how they behave. Some process change teams use policy statements as a mechanism to mandate the use of the defined processes. Often, the mandated processes are developed in isolation of the end user. Whilst most practitioners agree policy has a place, used in isolation it will never be as effective as a collaborative approach.
By performing the process modelling and implementation steps iteratively in collaboration with the customer, you get a much better level of buy-in. The result of working in this way is that the client achieves a sense of ownership. With ownership comes accountability and responsibility, which in turn sees quicker adoption, higher quality feedback and understanding.
Process improvement projects are about implementing process change within the client's target organisation. In order to achieve this outward facing change you often have to deal with many internal project changes. Therefore, the fourth value of the Agile Manifesto resonates well, 'Responding to change over following a plan‘ .
It is difficult to predict all the impediments to any type of change. No organisation has the same combination of politics, personalities or delivery pressures. As a result, the level of requirements churn we see can be significant; the subsequent planning and requirement re-factoring is enough to make Agile very attractive.
Given that we have established - albeit at a high level - that change projects appear to be compatible with the Agile values, how do we implement this in practice? The