In Part 1 of this blog, I talked about two main development processes that software developers use, waterfall and agile. In this post, I’d like to examine how those processes are relevant in business process, not just in software development.

It would be nice to be able to say something like “All businesses should move towards agile development processes.” However, I believe that would be inaccurate. Different areas have differing complexities and needs that justify different approaches.

An example of this can be found in manufacturing processes that I recently saw. A business group that I am a part of had the privilege of touring the Ruger factory in Prescott, AZ. Regardless of your stance on guns, there is much to be learned from their manufacturing processes.

In the old days, they manufactured things in large lots but this created a number of issues with quality controls, cost controls and lost efficiencies. From there, they looked to move towards lean manufacturing where a part, essentially, went down an assembly line from start to finish. The benefit to this was that it would increase efficiencies, allow for quicker recognition of quality issues and reduce on-hand inventory costs. They ran into a problem, however. They realized that certain parts of their processes naturally lent themselves to larger lots such as heat treating metal, sending parts off to 3rd parties for processes they didn’t do in-house, etc.

As they have continued to evolve their processes, they have found a way to blend the newer lean processes, where they made sense, and allow for the more lot-based processes where it made sense. This more flexible, hybrid approach has allowed them to experience the best of both worlds.

In our businesses, certain processes lend themselves to be chunked up into smaller, bite-sized pieces that can be handled and developed independently. Other processes, however, are more complex and cannot or should not be sliced up. Often, however, a hybrid approach makes a lot of sense.

When looking at candidates for agile processes, in general, good targets are things that are iterative improvements to something that is already in place. Examples of this might be standardizing e-mail signatures, adding a piece of data collection in a database, etc. In these smaller examples, we can focus in on the need, develop a solution for it and release that solution rather quickly, with confidence. After we make the change, if something needs to be tweaked, it can usually be easily tweaked and fixed.

When looking at candidates for waterfall processes, in general, more comprehensive projects, such as revamping the naming scheme of your document structure, altering the workflow of orders through your procurement, delivery and billing system, etc. are much more suited for more of a waterfall-style process. These projects not only require a lot more thought and involvement throughout your entire organization but they also need to go through more comprehensive evaluation processes, before they are deployed, because they will be much harder to tweak once they are deployed. Imagine, for a minute, that you redefine your entire order workflow only to realize that someone forgot to think of how procurement and accounting would communicate. That has the potential to require a complete revamp of the process. Because of this, it tends to make sense to be more methodical and intentional in the process.

In the middle lies the more hybrid approach that, I find, works more often than either extreme does. In the example of the ordering workflow project, you might start by backing up and reviewing what is currently in place. Then, as a team, working to define what the process should look like. This might expose some different deficiencies in different areas that need to be remedied before the more comprehensive solution can be put into place. This is a great place where each individual area may apply agile processes, to make iterative improvements, to fix deficiencies and prepare themselves to more readily align with the bigger revamp. From there, you might be able to make slightly bigger changes that revamp, for example, how sales and procurement work together or how the warehouse and delivery work together. As these improvements are completed, eventually, there comes a time when the waterfall release of the entire revamp makes sense and the new workflow is released, in full.

How does your business handle continuous improvement and development? Are there ways that utilizing both the waterfall and agile methodologies could benefit your organization and both expedite and bring sanity to that continuous improvement?