Agile approaches call all involved to be on their best game – after all we are trying to compress the time of development – and strive for “enoughness” in all that is performed. Just enough is the key. In that environment, we need to get the most of every effort. This is definitely NOT an environment for rookie business analysts – in fact, I have seen many Agile projects fail because there WAS NOT a person (whether called a BA or not) who performed the ANALYST tasks that are part and parcel in the toolbag of the best BAs.

Utimately from recent experience, I have found that regardless of the advice and guidance provided regarding the choice of client representative and how important it is that they be in a position of authority or are formally impowered to make concise decisions about their business needs. This ideal world can rarely be relied upon. Yet where not available or consistant it WILL negatively impact a scrum no matter how advanced the tech lead is or indeed, the lead analyst.

My experiences with agile to date are mixed. What is clear is that if you have a weak participant in client, BA or Dev teams, it can result in a world of pain. BAs are the most effecient business advocates but there is no pure agile approach. (I know I will upset some people here The right teams are those that know the streams (COTS or code and solution components) required for the Project, business or technical, very thoroughly. Most importantly, they must take the client up the learning path and for that they also most fundamently know each other’s strengths and weakness, listen and learn from each other’s expertise and bring these together for the best result. Might sound a bit touchy feely, but ultimately it gets the strongest results. ~ Ingrid

The point I was trying to make was in the first paragraph he quoted: “A lot of the time we are the ones trying to make sure that everyone is on the same page with regards to meeting the needs of the project – do we understand what the client wants, does the client understand what they want, are the requirements clearly articulated, what is the cost benefit, are the developers developing just what is required (not too much/not too little), what is the actual problem that we are attempting to resolve, etc.”

I’ll try to explain what I was trying to say in another way.

In any project, the business owner/sponsor may have the vision but doesn’t always know what is possible. Maybe they have some wild crazy idea about implementing the latest i-Widget that they read about or saw on the telly – it’s the latest thang, we gotta have it. Maybe they are under pressure to fix a perceived problem in their area, push a product out to beat the market, or need to implement a change. Maybe they are an entrepreneur with a fantastic idea they want realised.

Business analysis is about (funnily enough) analysing a business. We attempt to understand why a client is asking for something to be done, what value it adds to their business, and how it fits in the context of their business. We investigate such things as what impacts the client’s business internally/externally (e.g. policy, legislation, market trends), it’s strategic direction, and how it handles change. From there we look at what is the most appropriate solution, whether it’s an IT solution or not.

If it is decided that an IT solution is appropriate, business analysts provide the development team with a holistic view of how their work will impact the business, and analysis around the appropriateness of the proposed solution within that context. Equally we act as advisers to the business owner where different solutions are being proposed and decisions on direction are needed, especially where decisions may impact delivery. We can do that because we’ve done all that other work first. In agile projects, this needs to happen in a timely manner. In sprint-driven development, this has to happen prior to the next sprint so that we all know what is happening next.

I don’t care what type of project you are running; this perspective of the enterprise is needed regardless. The business owner isn’t always in a position to do this because they sometimes have a narrow perspective of their world – hey, they’ve got a business to run. Development teams don’t have time where their attention is focused tightly on designing and delivering working code (like on Agile projects).

For example: I was a BA on a large product development project, of which a small but critical component was a new software application. The project overall was run as a waterfall, with definitive scope, gateways/milestones to assess progress, etc. As this was meeting a “time-to-market” strategic imperative, project deadlines were the most important factor. And we couldn’t avoid a lot of the project processes because that was the way the company ran their projects. To mitigate the risk of processes holding up development the Project Board agreed to let the development team use RAD to get working code out quickly. A preliminary functional specification document was written by the BA’s in conjunction with the Product Owner. This satisfied the need of the business for a solid requirements artefact, and the need to provide the development team with enough information for the development team to get moving. The product was demonstrated to the business when specific functions had been finished, and the functional spec became a living document which was amended as necessary to reflect changes to requirements.

When the business stakeholders determined that the application needed to rolled-out on 5 versions of Windows, the BA’s were able to point out the risks associated with that in terms of meeting the project’s deadlines. And when one of the developers wrote and checked in some “rogue” code that they thought would enhance the application, based on some direct discussions with the business, again we very quickly pointed out the risk of doing that!

I don’t think I’ve added anything new to what’s already been said. But to me the value of the BA to an agile project – on any project – is this: because of our depth of understanding we help to identify risks to success earlier, whether from a business perspective or a development perspective.

Let’s face it – in an ideal Agile World, all teams would be co-located and would be made up of most senior personnel; the projects would be nice, discrete pieces of work; we’d have a 1 or 2 enthusiastic stakeholders who understand agile practices; collaboration would be king; and we’d all be talking the same lingo. And then, we’d probably have world peace sorted out too.

@Tim Wright: Nice response; I think what you’re getting at here is that there is a role within Scrum delivery for someone with analytical skills, whoever that person is. Yes, it might be a developer or the Product Owner, but I maintain that these skills can be honed and that an analyst will make a better fist of it in the majority of occasions.

@Shane: Thanks for the link to your excellent and detailed article lending your support to BAs in the agile environemnt.

@David Morris: I particularly liked the way you drew a distinction bewteen developers, who are better equipped at ‘how to solve the problem’ versus the analyst, who establishes ‘which problem to solve’. It credits the analyst with sorting through, processing and adding value to the business inputs, as opposed to merely ‘gathering requirements’.

@Andrew Bennett: I never thought I’d hear someone say ‘I think BAs are pigs’ and agree with it!:) I consider that a good BA will be not only right across the breadth of a project an all its nuances and issues, but they will also understand the full depth of these issues, business, logical and technical angles. It is the broad yet detailed understanding which means that the BA has a high degreee of involvement and therefore a lot at stake (steak? sorry, just had to), hence making them more of a pig than a chicken.

@Ben Coop: Thanks for adding the weight of practical experience to the discussion. I think the point that BA’s undertake the role more efficiently than others is valid; after all, we might as well acknowledge the benefits that are gained specialisation.

Comments from @Adriana and @Carolyn also very valid, thanks for your contributions.

And @Mike, I hope that this discussion might soften your views of the value analysts bring to the Scrum table.

The Product Owner, a senior business representative who understood “business” things and the BA immediately paired up to discuss and coordinate workshops that drilled down on the requirements per Product Backlog item.
In some cases a face to face explanation of what was required of the development team sufficed, and in others short 2-3 page functional specifications were written e.g. complex business rules to implement field validations on the GUI. The Product Owner was involved in creation and review of these. They were light and cleverly interpreted from “business-speak” to “developer-speak” by our skilled BA. So not much difference here to a traditional approach.

In addition (this is where I agree with Adriana about the need for parallel streams) in the application of Scrum we are always by definition time constrained. In the design/prototype sprint (Sprint 0) it is the developers who are under the most pressure to deliver. In a ground-up build, they would typically be performing the following activities all within a period of 2-3 weeks:

• Building and configuring project environments
• Establishing source control procedures
• Configuring and testing the build server for frequent deployments
• Configuring and testing the automated unit test framework
• Trialing different architectures and technologies
• Building the foundations of the code base that typically can’t be demonstrated
• Writing some functional code for the prototype demonstration at the Sprint 0 review meeting
• Proving the concept and ironing out defects

The point is, that the developers are BUSY and if there is an expectation that the Sprint 1 build cycle will commence immediately following the Sprint 0 review and Sprint 1 planning meetings, then the requirements will need to be in a “ready-to-go” state. This can only be achieved if the BA and Product Owner (preferably with Test Analysts in observation) have done their work in parallel with the developers’ work bulleted above, during Sprint 0.

As Scrum Master, I would be very reluctant to dispense with the BA role in any of my Scrum projects. When the pressure is on to deliver, expectations are high and time is tight, my BA continues to perform the traditional role as listener, communicator, interpreter, mentor, facilitator and documenter. It’s just that they are doing it all more efficiently, more collaboratively and more iteratively.

1) Business analysts that only capture requirements and document them provide little value. Requirements are generally not there to be ‘gathered’. Project objectives can (almost) be gathered, but not requirements. The statements, pictures, etc. from all those with input can be gathered, but the requirements (user stories and their acceptance criteria) that will be developed are the result of a good analyst abstracting and developing a mental model of the business that would best deliver that mess of stuff they have heard.

2) This mental model is a deliverable that makes the final solution effective and efficient. This model is hard to document, which is not a bad thing, but it does mean you must ‘listen to the BA’ (people over process). It is not captured anywhere else, but working code and UI mock ups and user stories do infer it. And without it developers will still deliver a solution, and due to agile it will be a working solution that meets what the business asked for. But I will unreservedly guarantee that if you get a good BA to review that solution they will often identify a more effective solution or a solution that had a longer life span or was more amenable to expected change in the business.

3) I am assuming really good developers here – people who are effective at turning concrete criteria into effective working code. They will focus their discussion on what they need to build right now. They will make sure you are happy with it, and they will turn it round so quickly that before you leave their desk they are asking you if this is what you wanted and you turn to gaze at a screen that has brought your statements to life. That’s what good developers are great at. If they also perform mental model abstraction across a wider scope they become less effective – I myself have experienced that. I’m sure there are those who can perform multiple roles but they will be context switching as they do it which means some loss of efficiency.

4) Technical solutions are an abstraction of the ‘real’ and physical business with a whole bunch of technical constraints. They are complex. And not only that but the ‘real’ and physical business is, as noted before, not there to be ‘gathered’ – it’s in so many different unrelated repositories it’s not funny – documents, white boards, the minds of people some of whom are determined, others resigned, others structured, others emotive, some who tell a good story and others who are quiet but who really understand. So, take that mess and try to turn it into a complex constrained abstraction without going through an intermediate process involving business analysis and you will not produce an effective solution. Agile provides immense benefit – it makes sure the solution works and is what was asked for. That is more than half the battle. In cases where the solution is readily derivable from the source business then yes, dispense with the BA. For the other 90% of our projects….

5) And it will get worse for us non-BA’s. As advances in technology and platform improve correspondingly the technical constraints reduce. Cloud computing means various things but one example is that the constraint of scalability is now more a business decision than a technical one. As these technical constraints drop off we will need less technical input (a long way off I agree!) and the role of the BA will become more evident. I don’t believe the BA role will ever disappear either – in terms of a business there will always be a need for people who can take a step back and model a new solution that encapsulates the innovative ideas, the resolutions to problems, etc, that other people come up with. And the reason for this is described in my world as things like ‘separation of concerns’ – an effective process is one that removes redundant dependencies between components so that each component can become more effective and efficient, and more adaptive to change. Business analysis is a separate component – hard to quantify but then so are many of the important things in life.

6) So Rochelle – as long as you keep adding the ‘business analysis’ magic that is beyond merely gathering requirements, and as long as you adjust to agile (for one, only solidify the section of the model you need now and hold onto the rest lightly allowing regular modification to take place) like I am trying to do as an architect, then I think the case is really ‘will you be the only one left!’.

7) My evidence:
a) Just come off an agile project as the architect. This is unreservedly agile – 2 week sprints with review, demo and planning, user stories, story points, acceptance criteria, evolving framework and functionality with regular refactoring, unit tests (including UI), build and test on every check in, daily scrum, no wastage – don’t create a document unless we really have to, etc. etc. And the BA is good and the BA is regularly tweaking the developers’ input and the solution has remained effective and robust. The BA has this evolving picture of the whole thing that the rest of us don’t (well I try to). We have good developers, and testers, but I can see regular examples of our BA adjusting a discussion and avoiding wasted time or going ahead of the developers into unclear areas (which are also unclear to the client) and describing a business solution that is delivered just in time for the developers to start working on it with most of the ‘business logic and process’ nailed down. The developer still needs client input but it is far more effective when done with a business framework that both the developer and client can work to.

b) I have been on traditional projects with ‘other’ BA’s. They also had very experienced developers. And yes, the lack of agile meant that a good solution was always going to be hard to achieve – but there are areas of those applications where some great developer solutions to a poorly analysed and modeled solution has meant we now have a pigs breakfast. There is no doubt in my mind that a good BA plus a weaker developer would have produced a much better solution. No argument. Heck, the business still argued that the solution they got was what they needed, but it is so dysfunctional it brings tears to my eyes. They complain when we go to cost the process of resolving it because the resolution really needs them and a good BA in the room (plus some architectural input, but no other technical input) – i.e. starting from scratch and that makes it expensive.

c) BA’s who described the business issue and in the same breath stated what the technical solution should be. And analyst-developers who did the reverse – said here is the solution because the business issue was really xyz. The results have been poor in my experience. Separate the concerns, then discuss each bit – and if the developer wants to explore business options that’s great, and if the BA has some great technical input then bring it on. The discussion will evolve to a combined problem / solution discussion which is very powerful – but only if the initial issue has been well described first.