Are you looking at improving your business processes to be more efficient? Of course you are. You would not be spending your time reading blogs if you were not trying to improve your ability to identify and reduce bottlenecks or to take advantage of new technologies and methodologies that could improve your productivity. Unfortunately, one challenge that most of us have is that we may not know if what we want to improve is actually the thing that we should really be improving. To address this issue, I use Agile and Lean Methodologies. They ensure sure that I am solving the right problem.
There is a lot of literature about Agile and Lean but they are such buzz words that it takes a while to weed through all the marketing material to get to the real core material. You may be tempted to give up in frustration but I’ll explain things as I understand them.
I feel passionately about this topic because I have found from personal experience that if used properly, Agile and Lean can significantly reduce the amount of effort and time required to improve any portion of your business, from process redesign to business process reengineering. By using Agile and Lean I can make sure that a solution solves whatever problem I am trying to solve. That’s a key reason why I like this approach so much.
I was first introduced to Agile via the software development perspective; however, I have found that the key principles are so solid that I now apply them to almost everything I do. I have found it to be so useful that I now apply it in areas that you might not expect.
I use Agile and Lean concepts in the beginning when I am defining what problem I want to solve and this continues throughout a project. In an Agile paradigm, every aspect of a project is continually revisited throughout the entire lifecycle. This continual reassessment allows me to only spend a fraction of the time in determining the requirements compared to traditional “Waterfall” methods of planning. The reason is because Agile does not force me to get everything right at the start of the project as Waterfall does. Agile focuses on quick measurable iterations that we can evaluate and learn from.
This is a huge advantage because it fits perfectly with the reality of every project I have ever implemented. I always encounter multiple challenges and opportunities that I had no idea about at the start of the project. Agile accepts that dealing with unknown problems and opportunities is the reality of working on a project. Agile not only acknowledges this reality, it leverages it.
After I define the requirements (knowing they will change after I start to learn more) I implement a small portion of the solution which should not take longer than 2-4 weeks. This small portion can be to test any of my assumptions or implement a specific piece of the solution which can provide value by itself. This small iteration has several different names depending on the specific Agile methodology you use; however, the fundamental aspect is it that
- It is short in duration
- You can attain value from it
I know it might seem that 2-4 weeks is too little of a time to get any valuable solution but it is amazing the amount that can be done or discovered in this amount of time. Breaking your projects into 2-4 week chunks is probably the hardest part about Agile and is where some companies trying to use an Agile strategy fail. This is a discussion in itself; however, there are many successful examples of using small measurable milestones to complete multi-year projects that are huge in scale and scope. For example, Agile has been used to successfully implement ERP and PLM. I talk about it in blog post Looking at Investing in PLM?
After each 2-4 week iteration I evaluate the results and deliverables. This is where I learn from what I did. In my opinion this is the most important stage and is the key reason this strategy works so well. This is where I may determine that an aspect of the problem I was trying to solve was really not the source of the problem, or I uncovered a requirement I simply did not know, or in the best scenarios I learn that I was right about my assumption. Knowing you are making progress on the right track has tremendous value.
The “worst case” scenario using this method is that I might implement something that did not have value and I “wasted” 2-4 weeks. If we decompose this worst case we find that we only invested 2-4 weeks of our time to determine something was a bad idea (for whatever reason). This worst case is actually something I look on as a positive. It would be much worse if I implemented a solution which would take a year of effort only to find out I was trying to solve the wrong problem. If I’m going to fail, I want to fail early. The worst case scenario for me is if I did not use agile and lean.
After the learning phase I take any course corrections or “pivots” and start the process over.
Closing Remarks
Using agile and lean have allowed me to solve the right problem in much shorter time. The focus on quick iterations, validated learning and embracing change really fit the challenges I am trying to overcome as well as the processes I am trying to improve.
Getting rid of the traditional detailed waterfall “business plan” where you needed to determine all requirements and virtually guess on many aspects of your problem you are trying to solve which can have significant negative affects if you are wrong has been a blessing. Only identifying the key requirements and creating small iterations to test any assumptions has overall reduced the risk of any major and minor improvements I try to make.
I would recommend everyone to learn about agile and lean methodologies and use them in every aspect of your job. I can guarantee you will be impressed with the results.
