The move to Agile – The impact on Business Analysts
The current move towards agile appears inexorable. IT executives are finally paying attention to the benefits that agile brings. However, doing agile well is a non-trivial matter especially for business analysts used to SDLC / waterfall processes. Indeed many projects are more suited to waterfall than agile, notably those in highly regulated sectors.
A couple of weeks ago, I was in NY and chatting with some Business Analysts from two entirely different financial institutions. In both cases, it appears that these folks are, somewhat up against a wall trying to understand what ‘agile’ means for them. They are not being given much of an option in terms of controlled adoption, rather, executive level mandates appear to be handed down to ‘go agile’.
In the trenches, the story goes like this:
- Analyst Lead: We have been doing pretty rigorous process with large BRDs and Func specs, mostly in a waterfall SDLC style.We are pretty controlled and hand over those specs to the technology team to implement.
- Tech Lead: Well, in agile we have sprints (assuming SCRUM terminology here!), there’s no need for up front docs. We just release every 2 weeks and validate the system iteratively. We have a backlog of demand and prioritize at start of each sprint. We assume change…
- Analyst Lead: Ah OK. So, how do we articulate to the business expected delivery timeframe and cost?
- Tech Lead: Don’t worry, we will talk directly to the business and the customer can become a part of the process.
Now, it’s just about here that there is confused silence.
The Business Analyst team lead is starting to feel somewhat on the back foot and uneasy. Many elements of what has been ‘bread and butter’ practice up to that point appear to be thrown out the window. It’s extremely hard for people who have been following certain behaviour patterns to switch overnight, without introducing severe risk, yet this is in many instances, what is being asked for.
BA teams then start to hear of SCRUM or whatever flavour of agile is being espoused. 3 day courses are attended. Terminology such as ‘burn-down charts’, ‘backlog’, ‘pair programming’ ‘stand-up meetings’ whiz by…
After reflecting a little, the BA lead starts to ask some bigger questions:
- Analyst Lead: So how will we do ‘standup meetings’ and include the business stakeholders in London and Tokyo? given the time zones and the fact that we never actually meet face to face?
- Analyst Lead: How will we treat cross cutting considerations such as NFRs (non-functional requirements) affecting scalability, throughput, legal aspects? where can we record these? are they part of a sprint?, what about legal requirements and audit trails?
- Analyst Lead: How can we be expected to work directly with business stakeholders in the sprints since we have great difficulty getting even a half hour of their time currently?
- Analyst Lead: If we’re just doing sprints, how will we know we’re done? and how can we provide any cost estimates to the business?
The list goes on.
Many of our technical colleagues, especially those who are less seasoned, treat agile as a global panacea to world ills. In some very unfortunate cases, they are hell-bent on throwing out the entire rule book, in effect the ‘baby with the bath water’.
It truly reminds me of another silver bullet; ‘client-server’, close to 20 years ago in the early 1990s. Here, just like ‘agile’, well-intentioned execs saw the benefits of moving off expensive mainframes and deploying rich UIs and client-server based systems. The business driver then was cost and usability to an extent. I recall several projects I was directly involved with that were canned as a result mostly of poor performance in terms of scalability. Ironically, the cost of rework or cancellation to the business was quite material.
With agile, executives are embracing it because the business driver is speed to market and alignment with the business. I have talked to IT executives who say ‘we need to be more agile’ or ‘my primary goal is to respond faster to the business’ but with nothing more than a cursory sense that ‘agile’ will achieve this. They may have read an analyst report but are likely unaware of the pitfalls on the ground.
So, Business Analysts and Project Managers need to be very careful. Like all new religions/silver bullets, after the euphoria wares off, come some pretty tough questions, as well as some realisations. The most important thing is that: ‘Agile is not a silver bullet’ and it is not ‘one size fits all’ approach. Agile needs to be handled with care, otherwise you’ll find yourself embroiled in out of control projects where there simply is no rule book and ‘hushed up’ failures will be common.
Indeed, like all movements (COBOL, client-server, OO, RAD, Use Cases), there is a backlash developing against agile. Check out these links for some war stories:
In my view, what Gartner refers to as the ‘trough of disillusionment’ is beginning to occur with agile, no bad thing to have healthy debate. I am confident that we will find the right balance, but in the meantime BAs need to equip themselves with knowledge of how to work traditional waterfall projects AND agile projects to achieve delivery success. There are superb concepts in agile but it needs to adopted with care.