What is Hybrid Agile?
Hybrids are the union of two similar functions that have a different focus combined to do one thing really well. They are meant to provide optimal flexibility, efficiency, and adaptability, without sacrificing quality. For example, a hybrid golf club combines a fairway wood and long iron, allowing for a golf ball to be hit long distances with pinpoint accuracy. It’s a best of both worlds combination. Other common hybrids, such as cars, also provide optimal levels of efficiency, but can the same be said for Agile application lifecycle management?  Is a hybrid approach- a combination of Agile and non-Agile practices- the best option when scaling to enterprise teams?

Though Agile purists would strongly disagree, the answer is yes.  Hybrid Agile, or what we at AccuRev call “Real World Agile,” is a viable option for most organizations and most often the option that best fits their needs. After speaking with Agile team after team, and Agile organization after organization, I saw three repeated trends that challenged a dogmatic adherence to Agile methodology:

• Collocating every team member and team group is rarely possible with today’s globally distributed development organizations
• Multiple Scrum teams working in parallel hinder getting to “done.”
• Not all teams can and will go Agile at the same time – some teams may never go Agile.

Agile Teams Cannot Always be Co-located
The Agile framework facilitates openness with teams through various levels of communication, whether these include daily stand-ups, planning poker meetings, or even updates to burnup or burndown charts. This communication is more than emails and instant messaging; it is important for teams to communicate information related to stories, code changes, and status updates. Agile principles recommend teams be collocated to adequately communicate these detailed updates and developments – requirements can be met when all team members share the same work space and time zone.  But collocated development teams in today’s development environments are rare and rapidly approaching extinction. Think of your own organization. Do you have any developers who work from home? Are any of your development groups geographically distributed? Maybe testing is off-shore? And by geographically distributed, I don't just mean off-shore – how about developers in a different building on the same campus, or different floors within the same office building?  Even if teams are in close proximity to each other, gathering everyone for frequent meetings can be a daunting challenge.

Despite these challenges, development organizations that are unable to meet the collocation requirement can still be Agile. Maybe you have adapted by using a web-based architecture to facilitate communication with your remote teams. Maybe you do daily stand-up via a web conference. Textbook Agile requires collocated teams. But facilitating communication to geographically distributed teams or remote developers shouldn’t disqualify an organization from being Agile- this type of practice makes the organization hybrid Agile.

Complex Merging is Complicated by Agile
Multiple development teams working in parallel on software development projects have become the norm today.  This approach improves software development efficiency but also adds complexity to the merging and integration processes, which can be hampered by rigid adherence to Agile methodology. For instance, many organizations have Scrum teams working on components of the same product, but could also be driving new development in addition to sustaining development supporting multiple releases.  In traditional development timelines, integration or merging with other teams or with past bug fixes usually occurred close to the release date – a period in the development process often referred to as Merge Week (or Hell Week).  This is when the codebase from multiple teams that had been worked on in isolation for a number of months now needed to be integrated with the rest of the codebase as well as with other teams who were often changing the same codebase.  Have you ever had problems identifying what has changed across development branches?  Can you accurately track what stories have been completed and where they have been delivered?  Have you tried to do this for 10, 20 or 50 teams, not just a pilot team?

Implementing a more Agile approach to software development calls for more frequent releases, or at the very least 'shippable' code at the end of an iteration.  To have shippable code you must be integrated with the rest of the changes going on around you, thereby moving the integration point from shortly before a long release (say 6 months) to every three weeks (if you are doing 3 week iterations).  Without that ability to quickly, easily, and efficiently merge changes from multiple development lines you are at risk of not getting to 'DONE', - one of the important requirements of being “truly Agile.” In the reality of today’s software development ecosystem, few developers and development teams would make the cut to join the “Agile team.”  A better approach is to apply Agile methods where they help you improve software efficiency and software quality rather than forcing an Agile approach where it does nothing but gum up the works.

Variations are Inevitable when Scaling Agile
Agile at scale requires the coordination of multiple smaller groups executing multiple and simultaneous releases at a rapid pace. Dependencies across teams increases while visibility into the process decreases. Agile with a single team, such as a pilot team, doesn’t require significant infrastructure change. Conversely, transitioning to Agile from waterfall across multiple teams using a spec-driven approach can significantly stress an organization’s infrastructure and development process. That being said, not all teams will, or can, go Agile at the same time. Some teams may never become Agile due to an organization’s infrastructure. And when Agile is scaled across teams, variations of Agile practices may form based on each individual team and those aspects of Agile methodology which best help rather than hinder the software development process.

This hybrid approach to Agile is the reality we see with our own processes and with the enterprise software companies and development teams who use AccuRev’s ALM solutions.  Within AccuRev’s mid-sized development organization we have several Agile teams that have implemented a hybrid Agile customized to fit their needs.   We have a Core Team performing four week iterations, a Web Team with two week iterations, and an Integrations Team with three week iterations.  We have found our own hybrid approach to Agile that allows all of these teams to mesh and release together.

A company called Petrotechnics also exemplifies hybrid Agile in action.  Petrotechnics provides software and services for the oil and gas industry. They wanted to take full advantage of all of the benefits and efficiencies of Agile methodologies without entirely disrupting their existing infrastructure and development process.  Petrotechnics made a successful transition to Agile by first making changes to their development toolset.  They implemented an Agile ALM solution that allowed them to integrate best-of-breed software configuration management, Agile lifecycle management, and build and release management tools. Retooling has provided Petrotechnics with a turn-key approach for implementing and scaling Agile on their own terms.    

According to Stephan Buchan, ALM Toolset Architect for Petrotechnics, “Our top requirement as we moved to update our tools was to find a flexible Agile solution that would allow us to implement our pre-defined custom Agile methodology without having to compromise our goals or our vision in any way, ” 

However you look at it, Agile methodologies have had a dramatic impact on software developers and the software industry since the publication of the Agile Manifesto a decade ago.  I’m a huge proponent of Agile because I’ve personally and professionally experienced many of the benefits promised by this revolutionary approach to collaboration.  But like all movements and revolutions, there’s no “one size fits all Agile.”  The Agile Manifesto should be taken as a guideline for Agile success, not religion.   Most developers and development organizations have discovered this along the way as Agile continues to evolve, but Agile pain points and obstacles to adoption persist.  If you get one thing out of this article, don’t let the dogma stand in the way of taking your development efficiency to the next level.  Don’t sit on the fence.  Don’t just dip your toe in the water.  Take a dive into Agile and find how to make it work for you.

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment