Agile Process Improvement, the Hardest Part

June 5, 2008 by JurgenAppelo

In our company I am responsible for most of our process improvement activities. It's not that I can do everything myself. But I must make sure that there are plenty of initiatives, that they don't bite each other, and that they are moving the organization into the direction that I desire.

Some examples: new templates for standard documents, improving our testing methods, introducing new intranet and project environments, reorganizing teams into cross-functional ones, reorganizing job descriptions and levels, creating new training materials, coupling invoicing to time registration, improving the project estimation procedure, improving the recruitment process, etc...

Basically, my process improvement efforts come down to this:

1. People complain to me about things going wrong, and they request a solution.
2. I add the issue to my backlog, which has the size of an average glacier (and moves forward with roughly the same speed).
3. I plan my work on these issues iteratively, at the beginning of each month.
4. I do not allow new requests during the month. All new requests are saved for (re)planning and (re)prioritization at the start of the next month.
5. The biggest challenge is actually trying to do the things that I planned during a month.
6. At the end of the month I check which issues I was able to solve (usually very few) and I act accordingly (often by moving many issues to the following month).
7. We regularly review our process improvement initiatives in our management team. And, believe it or not, I still haven't been kicked out.

It's a simple process, and it's a fine implementation of the Plan-Do-Check-Act cycle of Deming/Shewhart. It also happens to be a process that follows several agile principles.

Still, I'm having trouble getting things done. Why?

• A large portion of my time is taken up by things I cannot foresee, but they require my attention. I'm required to attend meetings, give feedback on project proposals, interview new employees, attend conferences, offer lectures on software engineering, etc. Sure, I have tried to calculate how much of my time I need to set aside for these activities, but it's like trying to predict the stock market. I believe that three monkeys and a banana have a better chance at getting such a prediction right than I have myself.
• Contrary to software development, process improvement has many dependencies across the organization that are often beyond my (direct) scope of control. For example: I am now waiting for the HR manager, waiting for a systems administrator, waiting for the financial administration, waiting for the business consultants, waiting for our recruiter, and waiting for Microsoft. It turns out that I'm waiting for other people in almost 80% of my cases.

The Hardest Part: Implementation
Knowing what to do often isn't the hardest part. I know how to do process improvement, and I know how to use agile principles. The most difficult part is the actual implemention of these fine ideas. The world isn't perfect, and neither am I. But sometimes I cannot help dreaming of utopic environments that are a little more co-operative with my best efforts...

Permalink