Over the last 12 months the term “Hybrid Agile” has come up a lot when talking to my colleagues and clients. It is usually used in combination with Multi-Speed IT, Multi-Modal IT or other terms that mean we are mixing things up because “pure” Waterfall or “pure” Agile is not working in our circumstances. This shouldn’t be surprising as pure methods are rarely seen in the real world. Unfortunately while Waterfall and Agile have some kind of definition that people can agree on (at least mostly), the other terms seems to be used very loosely. In this article I want to bring some clarity to those terms and then explore the idea of “Hybrid Agile”. Is there really such a thing and if there is, where would one use it. While we work our way through the ‘Fog of War’ of methodologies and terminology we will explore different models as we get closer to “Hybrid Agile” by defining models that are not “Hybrid Agile”. As is often the case terminology matters, so let’s get into this by clarifying terms that can be confused with “Hybrid Agile”.
Multi-Method / Multi-Modal IT/ Bi-Modal IT / Multi-Modal Delivery
I think this is the most intuitive. It uses different modes of delivery; usually referring to Agile and Waterfall type methods. Strictly speaking using different Agile methods like Scrum and Kanban would fall in this category (e.g. using Scrum for projects and Kanban for Maintenance). It is quite common for any large organisation to use different methods across the organisation as they have to deal with some applications or vendors not delivering using Agile methods even when the main methodology is Agile or vice versa. This does not classify as “Hybrid Agile” as it uses multiple methodologies to its full extent and not mixing them for a specific application or project. Pretty much all organisations I have worked with in the last 6 years have been doing this. What it means do this well is a different question and something that requires exploration in another article in detail. (you can read about Gartners definition of bi-modal here http://www.gartner.com/it-glossary/bimodal/ )
Multi-Speed IT/ Two-Speed IT
Now speed is a different thing from methodology. It refers to the release frequency of changes. Some applications might release functionality monthly while enabling back-end services only get released every quarter. The methodology is not of concern in this case (e.g. you could have two different delivery speeds using Agile – or Waterfall for that matter). Arguably all organisation have some level of multi-speed and very often this coincides with Multi-Modal IT – faster Agile delivery vs slower Waterfall/Traditional delivery. Again I think it is clear that this is not “Hybrid Agile”. The most common pattern is for projects to be delivered using the ‘slow lane’, while production fixes are using a ‘fast lane’ with both being governed differently. (if you want to read more about Multi-Speed, this article from IT Sceptic summarises it nicely http://www.itskeptic.org/multi-speed )
With that out of the way, we can see that “Hybrid Agile” should mean that we use a hybrid methodology for a project or initiative. By definition a hybrid methodology is taking elements from two methodologies and combining them – ideally the best of both. The right approach for this would be in my view to get someone who is knowledgeable in both “pure” methods and choose the elements from both that make sense to combine.
(On a sidenote: I have only ever heard hybrid being put forward by people from the waterfall world with little or no experience in Agile. So how would they successfully combine two things of which they only know one? – and they never use the term “Hybrid Waterfall”. This should make us suspicious. Why do you think that is? I think it is because people want to get credit for doing Agile without doing the hard work of having the right amount of rigor to make Agile work. Agile is an extremely rigorous methodology and is difficult to make it work. As they say, doing Agile is easy, mastering Agile is really hard).
The characteristics of waterfall and agile are exactly opposite in my view: Waterfall allows you to be very flexible during project phases which each last longer (like development or test where you can move scope relatively freely along the timeline) while being inflexible on the phase transitions. Agile is very rigorous on the smaller scale (the iteration is locked down scope wise and is strictly timeboxed) and hence enabling flexibility at the larger time scale (scope changes between iterations are encouraged). A true hybrid in my view would then either be rigid on both sides (all scope locked down for all iterations for example) or flexible on both sides (waterfall planning but allowing changes within phases and between phases – this is the ‘scary’ project that never gets delivered because scope management fails). Because the principles behind both methods are so different, it is quite hard to envision a true hybrid methodology.
But wait this doesn’t mean that you cannot learn from other methods to improve your basic methodology. You can use elements or practices from each methodology in the other (e.g. stand-ups for waterfall delivery teams are still beneficial, or some Agile projects might require a more detailed first version plan to adhere to governance constraints or budgeting processes), so perhaps those are “Hybrid Waterfall” and “Hybrid Agile” methods.
Let’s look at some of the methods that I have seen and review the details to see in which category they fall and where they are applicable.
Waterfall – this gets an honorary mention, but I don’t believe there are many true waterfall projects out there anymore. In a true waterfall, we would only have one release to production in one big bang. The goal of the waterfall methodology would be to work with the business stakeholders up front to define all the requirements and then practice stage containment to deliver the outcome in one release. Truth be told, I have not seen this kind of delivery outside of some rare government projects and there is no really no reason to do this kind of pure Waterfall.
Iterative Waterfall Delivery – these are basically mini-waterfalls that could be sequential (e.g. one waterfall finishes before the next starts) or overlapping (see diagram for example). This is probably the most common method these days as it is an adaption of Waterfall for the ever higher speed required to support businesses. More often than not it comes with the cost of multiple open codelines and the associated costs for code merges and increased cost of quality control. I have seen the additional work from multiple open codelines consume up to 40% of the effort for projects and you can argue this is pure waste or at least a steep price for faster waterfall delivery. Now if you use some Agile practices here (visual Kanban board and stand-ups come to mind as things I have very successfully used in this method) then you could arguably call this a “Hybrid Waterfall”. As mentioned I have not heard anyone use the term for this kind of method mix – calling it “Hybrid Agile” is certainly not correct as the main influence is from Waterfall in this case.
Agile – my minimum definition for Agile is that ONE team delivers an INCREMENT of a product (at least product tested) within ONE iteration. There are many variants of Agile, especially at scale, but I think my definition covers the gist of it. To make sure Agile works for you, I have developed a small set of suitability criteria that I use:
- Are business stakeholder sufficiently represented by a dedicated product owner for the team
- Can the technology (application and tools) support the fast speed development and testing required for self-contained iterations
- Are enough Agile experienced people involved as coaches, scrum masters, product owners to make the project successful
Everything else can be figured out like contracts, distributed teams, etc. – they don’t make Agile any easier, but with the above three things in place you will find creative answers if you really want to.
A special case is "Schroedinger Agile" - you dont know what it is until you look into it. Those are the Agile teams who do “mini-waterfalls” in each iteration. That means they cover design, build and test, but in a very sequential way yet still as one team. This could go either way in my experience, if it is a transitionary state until the team is able to break up work better and write better user stories that allows them to do more work in parallel then it is a positive. If it is just a waterfall approach under more stress due to the shorter time frame then it is negative. But just like Schroedinger’s cat, until you open the lid and check it out yourself you won’t know which way this is going.
But wait, we still have not defined “Hybrid Agile”. I don’t think any of the above qualify to use this term. As they are clearly either Waterfall or Agile, not both. We can get closer by excluding certain patterns that exclude you from using Agile as base methodology (but perhaps can be called “Hybrid Waterfall”):
· Having separate Development and Test teams
· Having design iterations, development iterations and test iterations
· Doing the ceremonies but without iterations (unless you are truly Kanban, and yes that means you have to have WIP limits)
I have worked with organisations who have made all these mistakes while believing they are using Agile and the results are not pretty. One organisation could never finish stories during the iteration because the handover between Dev and Test took too long, another had all kind of quality problems but no one spoke up during stand-ups because the Iteration Manager was basically holding a 30 min status meeting each morning and it felt like being back in school with a strict teacher. Culture does play a major role and the three symptoms I mentioned should be taken serious to identify a cultural mismatch.
If it is so difficult to define “Hybrid Agile” why do I think it is important to have a clear definition of “Hybrid Agile” (if it exists) and why do we need to differentiate it from the other methods?
Getting this distinction between methods wrong is dangerous for a couple of reasons:
- Usually scope flexibility is an expectation when talking about agile methods whether hybrid or not. Unless you have the rigor of Agile delivery or the rigor of Waterfall scope change management it is likely that you will fail on expectations in iterative waterfall approaches if you label them as “Hybrid Agile”. You will not be able to deal with the level of scope change expected.
- Unless you know which method you are using, you are more likely than not on your own when it comes to getting help. There is lots of documentation for Agile and Waterfall out there that you can use to get guidance from, but such advice is very likely not applicable to your very specific flavour of method if you are not sure what you are using. Similarly the roles of people on your team are different. I have met way too many Scrum Masters who have delivered “Hybrid Waterfall” projects but have no experience with Agile – these people are setup for failure when they get into an Agile project and do not appreciate the difference between the method they have used in the past and real Agile methods.
After many discussions, people convinced me that “Hybrid-Agile” is what is otherwise called Water-Scrum-Fall ( A Forrester coined term that you can read more about here https://www.forrester.com/report/WaterScrumFall+Is+The+Reality+Of+Agile+For+Most+Organizations+Today/-/E-RES60109 )and after some deliberation I admit that this makes sense to me. Of course the term Water-Scrum-Fall or similar phrases are often used with contempt or smiled upon, but when you look closer, this is reality in many places and for good reasons. Let’s look at the three most common elements of Water-Scrum-Fall that don’t align with my ideal for Agile:
- Financial planning
- Setting the goal for the program project
- Go-Live preparation
This means in those Water-Scrum-Fall cases we have an element of up-front planning and an element of post-Scrum hardening before we can go live. Of course ideally we want to make those phases as lightweight as possible, but very often they will be required to some degree. Are there projects that don’t require business cases and annual budget planning? Probably. But not many in larger organisations. So finding a way of making the existing waterfall processes more lean, will enable us to shift from “Hybrid Agile” to “real Agile”. The go-live preparation is different. I think there are many technologies for which we already have good answers that allow us to go-live as required using Continuous Delivery practices. For other technologies, COTS come to mind, we will likely continue to see some waterfall validation and testing practices being used before we can go live, but as the technologies and tools evolve this will become shorter and shorter until this final phase disappears.
In the meantime, if you work across the organisation with an open mindset and have aligned principles then I believe you can combine elements of traditional financial planning, program goal setting and pre-go-live preparations with Agile delivery as the key delivery engine. This is a Hybrid Agile approach that I can agree with (… for now). Of course we all want to create Agile organisations that don’t have those limitations, but until we do “Hybrid Agile” methods will allow us to move forward to incrementally solve the remaining organisational hurdles.
About the Author
Mirco leads Accenture’s DevOps & Agile practice in Asia-Pacific, with focus on Agile, DevOps and Continuous Delivery to establish lean IT organisations. He has over 10 years experience in accelerating software delivery through innovative approaches. In the last few years Mirco has focused on scaling these approaches to large complex environments. Mirco is a regular speaker at conferences and shares his insights on his blog.
