The 3 types of hybrid projects, and how they affect the business analyst’s work

I’ve written in the past about why hybrid approaches that incorporate traditional and agile methods of software development are been applied by organizations seeking to improve the results of their software projects. Here I’ll describe the 3 types of hybrid projects I have identified while working with different organizations in consulting assignments, and what impact each type has in the work of a business analyst.

1. “The Frankenstein”

The Frankenstein is the undesirable but common approach that results from an organization declaring the intention to “go agile” while retaining many of the previous practices of serial life cycles, with strong emphasis on following a predefined plan. You know you are working on a Frankenstein project when you hear things like “yes, we are adopting agile, but the business needs sign-off on the requirements before we start and we are keeping hard deadlines with the expectation of full delivery by our ship date”.

Obviously the attempt to hold on to legacy practices while trying to adopt agile practices such as incremental delivery of new functionality and self-organizing teams, will rarely bring the expected results. A BA working on this type of project is likely to face a series of issues that may include:

• unrealistic expectations that requirements will be entirely defined and detailed upfront, even though the chosen agile approach doesn’t allocate enough time to initial requirements elicitation;

• user frustration caused by the development team pushing back against changes elicited from early user feedback, due to their impact in the commitments made to full delivery by a certain date;

• overall project risks (including not satisfying user and business needs with the final product) exacerbated by the adoption of divergent practices that aren’t aligned to a common set of goals and values.

There isn’t much that a BA can do to fix the problems in a Frankenstein project, except for raising awareness of the risks. The best strategy under these circumstances is to avoid being assigned to this type of project in the first place.

2. “The Cross Breed”

Similarly to the Frankenstein, the cross breed represents a mix of practices. The difference is that these practices fit together, being a result of a thoughtful process that uses integrative thinking to make informed decisions about which agile concepts should be embraced or ignored in a given project. Agile practices are adopted based on evidence of their ability to improve customer satisfaction, costs, quality, cycle time, and/or productivity, taking into consideration the characteristics of the project and the organization, rather than being automatically selected only because they are part of a well-established agile methodology.

Same as with successful agile projects, cross breed projects require following a consistent rhythm in which the requirements are progressively elaborated to an appropriate level of detail. BAs working on this type of project may be working on fixed time iterations that require constant prioritizing of a feature lists. Requirements elicitation, analysis, communication and documentation happen throughout the project as needed.

A BA assigned to this type of project should be in the comfortable position of being able to “borrow” from both traditional and agile requirements practices. Agile artifacts such as user stories and a product backlog may be combined with traditional techniques such functional decomposition and data modeling. In successful cross breed projects, the selection of practices is made based on the value they add to the project, as opposed to the need to adhere to a specific set of practices.

3. “The Combo”

The combo approach is typically used in very large projects that have elements that are high in criticality and stability (e.g., strict safety and security elements), and others that are high in requirements volatility (e.g., user interfaces, interfaces with other systems, database schemas). As explained by Barry Boehm (in: Making Software: What Really Works, and Why We Believe It
By Andy Oram, Greg Wilson -- Chapter 10):

“In such cases, a hybrid approach using Agile methods for the rapid changing parts and plan-driven methods for the more stable and high-criticality parts will work, as long as the overall system is based on an architecture using the [Parnas 1979] information-hiding approach of encapsulating sources of change within modules.”

In “combo” projects, the timing and level of detail of requirements documentation will vary:

Combo projects may benefit from having different BAs working on each component. A BA with solid enterprise analysis, requirements analysis and documentation skills could tackle the plan-driven component during the initial phase of the project, while another analyst with strong user interface, verbal communication, user interface, facilitation and negotiation skills remains engaged throughout the project to define requirements for the next item in the queue or backlog for the agile component.

Author: Adriana Beal received her B.S. in electronic engineering and MBA in strategic management of information systems from two of the most prestigious graduate schools in Brazil. For the past 10 years she has been living in the U.S., where she offers consulting assistance throughout the software development life cycle for organizations implementing large, complex software projects.