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

Featured
23916 Views
7 Comments
5 Likes

The 3 types of hybrid projects, and how they affect the business analyst’s workI’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:

 

Component Characteristics Requirements model
Plan-driven Elements with high risks of incorrect architectural commitments being expensive (or impossible) to revert. Follows a traditional phased model, with early and formal requirements documentation and validation to support architecture planning.
Agile Elements with high-uncertainty levels and that can be easily refactored without much impact in previous architectural commitments. Light documentation (e.g., mainly user stories and use cases), created

Emergent requirements can be easily incorporated as a result of experimentation and iteration.

Stakeholders and testers collaborate with analysts during just-in-time requirements elicitation and communication throughout the project.

 

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.

Like this article:
  5 members liked this article
Featured
23916 Views
7 Comments
5 Likes

COMMENTS

Tony Markos posted on Monday, May 7, 2012 12:39 PM
Adriana:

Good article, however, I take a different perspective. My view: The primary task of an Agile BA is to come up with the bigger picture (same as with non-Agile projects). With Agile, such is necessary to, among other reasons, scope out the project and to plan the iterations.

Granted, support during the iterations is probably still needed. But, an adequate quality yet minimal documentation bigger picture is still the most important BA contribution.

Seen from the above perspective, decomposition, for example, is not just a Waterfall thing. It is needed for the Agile big picture effort because, frankly, especially on larger scale projects, no one knows enough to just create an adequate quality big picture without doing some decomposition, which is then summarized upwards into a usable big picture.

Tony

ajmarkos
Adriana Beal posted on Monday, May 7, 2012 8:12 PM
Hi, Tony!

Thanks for the compliment and for adding your views as an agile BA. I actually agree with what you said about the importance of the developing a bigger picture in agile projects, and how that can be the most important contribution a BA makes to the project.

I never said functional decomposition is just a waterfall thing. You may have noticed that I don't even use the word waterfall in my article because clearly waterfall is not the only alternative to agile. There are many traditional software development methods based on iterative/incremental models that use techniques such as functional decomposition.

Obviously nothing prevents agile teams from adopting these traditional techniques as well. However, many agile models today rely mostly on an initial short exploration of requirements via initial list of story cards, expanded during the release planning phase to complete the story cards and decide what to do for the next release.

This is not to say that structured analysis is always necessary for project success. I've seen many projets in the "agile sweet spot" do very well without initially identifying the high-level functions of the organization or solution and then breaking those functions into smaller pieces, such as sub-processes, activities, features, etc., like we typically do in traditional IID approaches.

If you typically use functional decomposition and other elements of structured analysis in your projects, in my eyes you already work in a "cross breed" hybrid model ;-).
adrianab
Tony Markos posted on Tuesday, May 8, 2012 9:48 AM
Adriana:

Thanks for the very valuable feedback. Me an you have obviously had different work experiences.

Your comments make me wonder: Was Yourdon right in saying that decomposition is needed to handle complexity, and is the BABOK right in saying that the real challenge in eliciting behavioral requirements not so much identifying stand-alone requirements, but [via modeling] the interrelationships between those requirements?

Maybe they are wrong?

Tony
ajmarkos
Adriana Beal posted on Tuesday, May 8, 2012 10:56 AM
Tony,

My experience with agile comes from two sources: 1) working with a few companies that hired agile consultancies to implement an agile method (and witnessing some agile projects developed with the help of these consulting firms); 2) reading many surveys published by IEEE and ACM (the most recent survey in 2010 with 326 respondents with extensive experience in agile software development).

I notice that in particular BAs working on agile projects often have a different experience with agile, understandably so, since they are familiar with traditional analysis and bring this knowledge to their teams. This is not the norm with the agile teams I've worked with and the ones that have been part of these surveys.

I do not think the BABOK or Yourdon are wrong; in my experience, the most common cause for struggling agile projects is the lack of systems thinking -- failing to look at the bigger picture and understand the interrelationships between the elements of the system you are building, as you mention.

Having said that, I have been through so many different types of projects, in large and small organizations, that I do not believe in "one-size-fits-all" solutions. For some projects in the "agile sweet spot" -- low complexity ones -- a little exploratory design, followed by identifying and prioritizing requirements just for the next iteration, worked very well and helped deliver faster results to the business.
adrianab
Tony Markos posted on Tuesday, May 8, 2012 12:05 PM
Adriana:

Thanks again for your valuable feedback!

Tony
ajmarkos
Microglyphics posted on Tuesday, May 15, 2012 10:14 AM
Thanks Adriana,

One of the larger problems Agile has is the lack of understanding of what Agile is. Agile seems to be a buzzword applied to any semblance of an iterative development process, as if there are no other iterative processes. As a consultant, I have worked with many companies claiming to employ Agile, but the only agility exhibited is that necessary to evade responsibility. In my experience, the largest contributor to failed Agile projects, is lack of SME participation during the sprint. Of course a side effect of this is lack of inputs necessary to arrive at cohesive thought around system design. So, whilst I agree that lack of system thinking is an issue, but I don't see where this is different to failing Waterfall projects with the same lack of thinking.

I have worked on a pure Agile (XP) project that was successful precisely because it the level of management participation throughout the sprints was high. On one hand, I am no methodology purist, but we need to get away from calling Agile hybrids, combos, Frankensteins, and other confabulations Agile. Make up a new name or just say you are interating through some part or parts of the process. Of course, for marketing appeal alone, I see the draw toward the term Agile.
Microglyphics
Adriana Beal posted on Tuesday, May 15, 2012 1:53 PM
@Microglyphics: Thanks for your comment as well.

"So, whilst I agree that lack of system thinking is an issue, but I don't see where this is different to failing Waterfall projects with the same lack of thinking. "

*Sidenote: I hope by now it's very clear that I'm completely against the waterfall methodology, especially for large projects :-).

Having said that, many researchers agree that lack of systems thinking is a problem more likely to happen in agile environments because of the tendency of spend less time in the beginning in architectural aspects (the book from Greg Wilson I mention in my article discuss this very problem). I agree it can also happen in waterfall and any other type of traditional methods, but I think it's a fair statement to say that this is a risk that is more prominent in agile projects (avoidable, but a risk nonetheless).

"On one hand, I am no methodology purist, but we need to get away from calling Agile hybrids, combos, Frankensteins, and other confabulations Agile."

Yes -- we are 100% in agreement here. I'm tired of having people write to me to say that what I'm describing as non-agile IID method is indeed agile. All I can say is that I did my research, and the converging evidence I have is that the people who actually coined the term "agile" think that in order for an approach/framework to be considered "agile" it must follow the 12 principles behind the Agile Manifesto. Guess what, the hybrid and NANW (http://bealprojects.com/a-non-agile-non-waterfall-winning-approach-to-software-development/) methods I use in most of my projects do not follow these principles, and thus, I'm not going to call them agile.
adrianab
Only registered users may post comments.

 



 




Copyright 2006-2024 by Modern Analyst Media LLC