Even as a traditional business analyst, I can be more agile than a agile purist.
This is to make you understand the problems you incur when you simplify complex realities down to a small set of buzzwords and prescriptive practices while not questioning nor understanding those realities. You may actually end up doing the precise opposite of what you claim and wanted to be doing.
I can spend more than a month just in requirements elicitation and analysis — the agile purist nightmare.
At the end of it, I produce my deliverable which is a functional specification. This is a formal, highly structured document that is meant to explain to anyone interested in the project what is to be achieved (but not how, despite some functional constraints can limit those possibilities) as well as to secure the commitment of the business towards the project. This is also called the scope for the projet, that is, the set of things that the delivery team will be working on, or equivalently what the technical deliverables will look like to the customer who will receive and use them.
Delivering a functional specification at the end of a say 6 week work timeline is in accordance with the agile principle “document late”. This principle means to delay as much as possible commitments (in this case, scope commitments), when we will be more certain and have more information about what those requirements are.
During that period, and besides getting the requirements, my focus is in securing alignement between all stakeholders throughout the process.
In the mean time I am not “building” my deliverable, I am using artifacts that help me accomplish these goals. They can be a range of artifacts, but they all have in common that they are meant to evolve with the interactions with the stakeholders and they do not provide any guarantee to any stakeholder regarding team commitments.
These are the artifacts (or the “working deliverables”) that I exchange with the stakeholders. Unlike a formal project deliverable, such as a functional specification or a minimum viable IT solution, they are not meant to be approved by anyone.
The feedback they ask for is intented to adjust those deliverables until the conditions are met for a formal commitment by the team regarding the scope.
An agile purist would in abstract do exactly the same thing as I did here (so you see how the distinction agile/traditional is in this case misleading and atcually meaningless), with one main difference: he would use formal project deliverables to elicit feedback.
The implication of this is that
- I do not incur the overhead of actually implementing a (minimally viable) solution
- I can adapt to change in requirements easier because they impact working deliverables meant to evolve just-in-time
- I am sharply focused in promoting alignment between stakeholders and commitment on their part to the project, which protects the whole team
- I defer the delivery team commitment to the very last responsible moment when it can be done with the least cost
- I clearly separate in the project timeline two very different things which are the alignment between business stakeholders (a focus during analysis) and the alignment between those and the delivery team (a focus during implementation), thus making it more easily manageable and reducing risk
Due to this, I am more agile as a traditional business analyst than an agile purist. So you see, its not the fact that I am a business analyst that prevents me from being agile and even more agile at that compared to someone whose role title or prescription is “agile”. Although I am also formally a (Disciplined Agile) Scrum Master.
This is also in accordance with a (PMI) Disciplined Agile principle, which is that our focus must be in achieving agility, not in following a specific practice or methodology.
From the point of view of the delivery team, one could argue that the priority would be to get early feedback from stakeholders regarding architecture, usability, and other characteristics of the implementation deliverables that are not in the scope of a functional elicitation, however this is always bound to the necessary precedence between models or designs (requirements) and their implementation (IT solutions). You can do it at the same time, in certain circumstances, but that adds the overhead of evolving two very different types of deliverables at the same time with the waste injected by having to make corrections twice instead of once. On the other hand it doesn’t necessarily assure you a quicker elicitation of requirements.
As an example, I had a junior analysts team with me in a project once. I gave them guidance about this subject and in particular I explained them the differences between a formal specification and the working document I was proposing them to use during elicitation.
As I expected, the project manager prompted them to deliver the specifications in the usual two week agile timeframe. They chose to deliver the formal specification while I was constantly delivering the working document in my elicitations (that is, I was not formally delivering but instead I was extending the iterations duration to adjust to my needs, which is a totally valid Lean managment approach). The overhead for them of having to constantly change the formal specification and to explain it to the customers, and the overhead to the customers of having to approve successive versions of the documents, made them extremely inneficient, made the customer weary and insecure in trusting the team’s work quality, to the point that in the end I alone managed to secure more scope than they did altogether, even considering the difference in seniority. In reality, lesser seniority in analysis should point them to work on more simple artifacts, just like I proposed to them. Following a 2-week delivery cadence just for the sake of its name should have been secondary to them, despite being paramount to a project manager with very little analysis skills.
This is a practical example. Of course, I took care to explain to them that in the future, if they will be working as analysts, they should behave as such and not as a project manager trainee with little knowledge of managing stakeholders for business analysis. Therefore, instead of blindly following a project manager’s orders, which is in itself anti-agile because it is prescriptive, they could instead follow the informed advice (which is agile) of more senior practicioners. And thus be more agile than agile purists themselves.
Compliments of the Author 