Every Agile methodology has its own characteristics.
There are emergent methodologies fit in Agile toolbox, Agile process tools such as Scrum, Lean Kanban, Extreme Programming XP and others bring their own characteristics and advantages to the table. So can you mix different Agile Frameworks and be successful, or the other side of question is, "can you not mix and be successful"?
The technology team should use whatever processes and artifacts suit their circumstances, then measure and improve them continuously. After all, Agile is a just short list of preferences, not a rigid method. Lots of people saying things like, 'What you're doing is fine but it's not Scrum', as though being 'perfectly scrum' is the ideal objective. In fact, what matters is doing a good job, adding value and learning how to improve as you go. If that means mixing different agile frameworks together then so be it.
Every Agile methodology has its own characteristics: For example, Kanban focuses on improving whichever methodology is being used rather than providing its own framework while Scrum provides a definite framework with essential artifacts. The focus of the Agile method is to deliver value rather than fixate on the method itself. Therefore, organizations can customize several Agile framework methodologies to suit their needs, enabling them to deliver maximum value. One can mix and match ideas from any source as long as it is:
1) adequate; it produces the desired results,
2) attainable; it is within the capabilities of the people who will do the work, and
3) efficient; choose your own metric; it needs to suit your needs.
Any project can be successful if you are able to align the project demands with that of the aspects of different Agile methodologies to fulfill the demands. Agile methods are not totally rigid like the Waterfall method. Agile frameworks are divisible and best practices of different methods can be combined to cater to project success, where implementing a particular method does not suffice. Sometimes there may be hurdles in adopting all the aspects of a single method (it can be organizational, change of team and roles or process related).
There’re both cautions and encouragement in such endeavor. Organizations are customizing several Agile framework methodologies to suit their needs.
.. There’s caution against the organization imposing such a mix, but heartily endorse an organization that is prepared to support such a mix, as imposing methods on developers opposes the first line in the Agile manifesto: 'prefer individuals and interactions over processes and tools. The work should proceed with only just enough ceremony
to ensure that:
1) End-users get to use a product that they acknowledge is fit for its intended purpose
2) The customer (the entity that pays for the product) acknowledges that they have received value for the money spent
3) Developers (the whole product supplier team) get to work at a sustainable pace, have a sense that they have produced a technically robust product
Scrumban, the combination of Scrum and Kanban is a classic example of combining Agile frameworks. Kanban was used to regulate, prioritize and monitor the BAU work-stream and when larger, more project-like pieces of work appeared, place a Scrum 'wrapper' around the Kanban process, essentially breaking-up the continuous flow of Kanban into project sprints. You can also ring-fence the sub-team working on the new project to free them from the relentless interruption of BAU. Once the project was complete, developers would fall back into the Kanban/BAU work-stream. Such joint-but-separate process may increase productivity
Doing ‘hybrid Agile’ first implies sufficient expertise in the two or more desired mixed implementations of Agile Methodologies. Some Agile frameworks perform better than others on some of the following bullets. In the end there is no one right way, so we all have to mix, experiment, and keep trying new things until we get something that works better than whatever we use today.
(1) Software is getting built and delivered
(2) The pace of development is "quick"
(3) Bugs are few or nonexistent
(4) Costs/Expenses are reasonable and under control
(5) There are no surprises at the end; surprise you have 500 bugs that didn't surface in Unit Testing; or a bunch of requirements nobody mentioned until t-minus one month.
(6) People who depend on the software like it
(7) The software is relatively easy to fix, update, enhance.
(8) The net ROI is positive
Some studies discover that when organizations start with XP first and Scrum later, these organizations tend to have much better results than those that start with Scrum. XP is insufficient on its own to make an Agile organization, but the foundational principles one gets from starting with XP create a proper foundation for whatever layer you put on next. The other possible reason of starting with XP first works better is the difference between XP coaches and Scrum Masters. XP coaches tend to be pretty hardcore as a group, thus know what it's like to be on the critical path. Scrum Masters are more focused on how to run a standup. Also, Scrum is a workflow framework with lots of little rules and idioms, whereas XP is about fundamentals that split the fence between Agile and Lean.
Agile at its core is a state of mind, mixing framework elements can and probably will be common practice when the overall goal is to practice Agile. This type of Agile journey can be both enlightening and fun-filled and very rewarding. It has the upshot of ensuring that the whole Agile organization becomes fully conversant with more than one form of Agile while still all agreeing on a single consistent approach. The matter of fact is not about what mix of label/brand/fad being used. Surely what really counts is that a group of committed people collaborate to economically produce a fit-for-purpose product within time and cost constraint