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.
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 ;-).
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?
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.
Thanks again for your valuable feedback!
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: 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.
Only registered users may post comments.