Posts tagged agile process improvement

Process Improvement and Agile

Agile is quickly becoming the accepted method for project management these days. Once organizations start moving toward agile projects, quickly they want everything delivered in an agile manner. This has led many to ask how process improvement and agile work together.

One of the first misconceptions is that agile is not a process. Of course it is…there is a process flow in agile, just like any other project management approach. Agile has a set of repetitive steps to gather epics and stories and perform iterations. Without a process (series of steps), how would you effectively train agile to others and ensure everyone is doing it right and the same? Yes, agile is a process.

So process improvement can take a long time and often does not feel very agile. If your organization is moving to an agile environment, how does process improvement move there too?  Well, in process improvement, there are three ways to become more agile: proper project scoping and transfer, rapid improvement events (known by many names), and true lean/continuous improvement. The following briefly discusses all three.

Process Improvement Projects.  Running an improvement project using a formal methodology normally follows a waterfall approach, whether it be DMAIC, DMADV, PDCA, or whatever alphabet soup approach you use. Waterfall, as anyone agile will tell you, is not agile! The problem with these projects is they can take a long time to get to root cause and implemented solutions that the lead is confident will solve the business problem. Want it bad, get it bad…right? However, if you take that huge ‘boil the ocean’ problem from your sponsor/client and scope it down into a single area, you can get to an initial solution fairly quickly. Rik Taylor and Associates teaches a very specific project scoping tree that is very effective at getting to a manageable chunk of work. Then, Rik teaches students how to transfer that solution to quicker iterations in other areas, focused on the same problem. This turns the waterfall approach into a very agile-like iteration process. It is still not agile, but it is much quicker at getting to improvements and builds over time.

Rapid Improvement. This is know by many names, like Kaizen Blitz, Work Out, Action Work Out, Rapid, Rapid Improvement, etc. Although still a waterfall approach to process improvement, the actual improvement activity is compressed into a week or less of hands-on dedicated activity. The lead still needs to define and measure in preparation for the workshop event, but what most participants see is a week or less of activity. Also, the solutions, though generally lean-based, are identified and implemented very quickly. This can be a much more agile process.

Lean Shop. Lastly, working in a continuous improvement organization focused on business process management creates an environment and culture of agile improvement. See a problem, fix it, at the lowest level.  That is the nature of true continuous improvement. When you get to a true world of lean daily management backed by solid business process management, agile improvement iterations become the norm. True process improvement projects (waterfall) are only used for large end-to-end improvements.

Even though improvement is happening faster or constantly, it still does not mean it happens without a process. All problem solving must follow a process of understanding the problem, getting to a root cause, and improving. Failing to follow a repeatable approach will result in things like tampering, improper solutions, and improvements reverting back to the old way of doing business.

These are the ways that process improvement and agile are related. Remember, that a process, at its core, is nothing but a series of steps that allow for training, measurement, and consistency. Thus, agile follows a process just like everything else. Although all effective process improvement also follows a process, it can be performed in a very agile manner, getting to iterations of improvement quicker.