As IT shops are adopting bimodal operations, they encounter a multitude of issues. They want to build new applications rapidly using tools like Mendix and leveraging the AGILE principles, but they need tight controls on their deployments for many reasons such as regulatory and audit controls. Enterprises have been trying to make Mode 2 “fit” into Mode 1, and attempt to control risk the same way as they do on traditional Waterfall projects. Here are a few issues I’ve encountered over the years and my thoughts.
Mode 2 does not = AGILE (but it should)
When using a tool like Mendix to build applications or BI tools to create analysis, everyone immediately thinks that the apps “must” be built using AGILE in Mode 2 of the bimodal framework. I can tell you now that one size continues to not fit all. First, you should be asking questions such as, “Is the UI/UX paramount and the data governed with strict controls, or are speed to market and loosely defined app requirements driving this product?” While these concepts are not mutually exclusive, they illustrate different ends of the product paradigms when determining which project management technique should be used to manage it. If you know precisely what you want, how users should interact with it, and how it fits into the architecture of your enterprise, the project is not a good candidate for AGILE and should be approached like any other Waterfall project. You are not going to iterate your product to success. At that point, if you recognize this project should be done in a traditional Waterfall methodology, then why waste your resources that meet with product owners to iterate to success? The blueprinting of a new app that requires low risk IS the Mode 2 operation, and then can be handed off to a Mode 1 team to implement the design.
Accept risk in Mode 2
If Mode 2 didn’t require you or your IT operations to accept more risk, then why have it at all? Being on the leading edge, or getting in front of or staying parallel with a new wave, requires adventure. An AGILE project is inherently adventurous; You don’t know what you are going to find at the end of the journey. If you did know, it’s because someone already mapped it (think Mode 1!). Since in Mode 2 you are supposed to be exploring ideas, accept that you will get things wrong. That’s why you are supposed to iterate your way to success. As your knowledge enhances through the exploration, expect that you will have to pivot and even possibly backtrack. Imaging a geographical explorer encountering a cliff face. They can’t forge ahead; they must iterate their plan and pivot in a new direction. Invest in the risk and don’t treat the projects with the same quantifiable metrics as a Mode 1 project where the map is developed first.
“Hybrid” models don’t work (optimally)
I have been on a number of projects like this and, while you find compromises to “make it work”, you are fooling yourself if you think you are getting the best of both worlds by building a “hybrid”. If the hybrid model was the best, don’t you think we would all be talking about it instead of Waterfall vs. AGILE? Instead, you get a mixture of confusing project processes and dissonance between your AGILE and Waterfall practitioners. Completing Sprints is still an effective way to manage development, but if your users have to wait four or more weeks for sprints to be tested and deployed through a rigorous change control process involving lots of documentation along the way, it confuses the product owners who bought into the idea that, “This time, it will be different (referring to past Waterfall project experiences).”
I have effectively worked on and even managed projects that blurred the lines between the AGILE and Waterfall methodologies, and while it still leads to getting the project work completed, I believe it overly complicates what could otherwise be a lucid process. Pick one method that is tried and true and fully embrace it.
Mode 2 creates Mode 1 work
Finally, if you create something of lasting value in Mode 2, hand it off to your Mode 1 operations. Trailblazers don’t tend to be the best at keeping the trail clear. In business-speak, there are those that excel at rapidly designing and deploying ideas, and there are those who take those ideas and make them better. That is often a divide in the type of people who thrive in Mode 2 versus Mode 1. So once a product reaches that point, whether it is a go-live, or six-months after the major kinks are worked out, transition the project so those resources can move on to the next adventure, and let your Mode 1 practitioners do what they do best: bring governance and change control to the product to make it the best it can be over time.