Business Analyst Work in Waterfall & Agile
Recently, I delivered a two-week series of training on agile and various supporting in Vietnam. It was a wonderful experience. Here's a question I'd love to share from the team.
Question
Hi Steven
We really impressed and thankful for your presentation series about Agile at my company. I’m so convinced and excited by how the Agile spirit would improve the team performance. However, there is one last point that still pulling me back to the waterfall approach. I wonder if you would help to remove this blocker so that I could become an Agile true fan.
As in waterfall, all the requirement are declared up front and then the design. The BA will have a chance to consolidate the requirement to make sure there’s NO conflict among stake holders as well as no logical conflicts among the requirement itself. This is done via stake holder group meetings, system thinking, requirement analysis, etc.,
The requirement is then transformed into a technical design which again will be validated by the Technical Architecture to see if they can technically cover all the requirement.
The 2 steps above would guarantee a framework that is quite solid in term of both business logic and technical. Of course, there’s going to be changes but that would be minimal and would still - ideally - be within the big picture.
By doing the Agile way, we try to complete stuff in vertical slices which may result in disagreement between the business requirement or technical limitation in later sprints. It’s very likely that the later sprint requirement and technical will be depended by what developed prior to them. It becomes more of an issue overtime.
Let’s me give an example of drawing a picture. I believe the painter will try to sketches the composition of the whole picture before going into details. Imagine if he starts drawing complete areas of the picture from left to right, top to bottom, he would likely realize that he haven’t finish what he intended to draw when he already reach the most right of the canvas.
It raises a concern in me whether we should have a combination of both method to utilize the power of each. In which I believe the requirement and design should be complete or almost complete as what it should in Waterfall. Then we start implementation using Agile with the concepts of Sprint, Standup meeting, Sprint Review, Sprint Retrospective, Burn down chart, etc.,
I know this is a schoolboy debate that already raised very early since Agile introduced but I still want to hear from an expert perspective.
Look forward for your discussion
P/S: You’re the best presenter that we’ve meet so far. Again, thank you so much for bringing us all the Agile knowledge and practice.
Thanks and best regards.
Answer
Hi there,
What your customer always wants is a working piece of software, delivered as fast as possible; that does what they expect it to do and delivers them business value.
The direct answer is that the agile approach is both incremental and iterative. To show this via the painting analogy that you bring up would be to say that:
1. As early as possible an entire sketch is made.
2. incrementally and iteratively, it is built up, clarifying what is built at every stage, with a maximum emphasis on visibility, inspection and adaptation.
http://itsadeliverything.com/revisiting-the-iterative-incremental-mona-lisa
Whilst designing the project upfront, "draw distinctions to reduce permutations". Find which combinations of items produce the highest value; and draw that distinction to deliver first.
Re: the waterfall approach - having had been a BA myself - to clarify:
- I respectfully disagree that there is little to no conflict in requirements - the moment that the document is signed off is the very moment that it is invalidated. People change their minds, market conditions change, must-have-but-unspoken-assumptions exist, misunderstandings exist, etc. Trying to "lock" it down at some point in time only makes harder the inevitable change that must happen.
- Re-writing requirements as technical design duplicates the number of conversations that must happen, and creates a secondary source of truth that will lead to confusion. e.g. the requirements say this but the spec says that. It creates yet another document of expectations, equally prone to error and change as the previous step; and equally valueless - because it is not the working piece of software.
- Lastly, this approach delivers two entire phases of work that deliver zero value to the customer.
One should not aim to create a 'solid' framework. One should instead create a framework that responds to change, because change is constant and change is a given. step 1 guarantees that it will be hard for you to respond to any change at all. Step 2 guarantees that you waste time delivering something that already exists, duplicates what should be a single source of truth, and creates a traceability issue.
Final Thoughts
What do you think? Have any comments? I'd love to hear from you in the comments below.