Sounds like you’re trying to do agile but not really – 1/2 way there but not. A typical situation

Oh, and this is what a colleague of yours said about BA/agile a while ago on a posting I made: “Agile + Business Analysts, A Marriage Made In Heaven Or Head Straight To The Divorce Courts?”

In all these discussions, we should also be careful of appearing to belittle the role of developer too.

Developers are ideally IT professionals who can do more than just churn out code; originally referred to as analyst/programmers to help make that distinction; trained in all the good requirements elicitation techniques, structured analysis, process and data modelling, etc.

Apart from exceptional cases, however, even when developers are multi-disciplined, the analytical muscles tend to get flexed primarily around deciding how to solve the problem, not selecting which problem to solve, or reaching behind the problem to understand the root cause. Sometimes developing a software product is not the answer. Sometimes the answer lies outside of the product owner’s purvue, so while their solution is to work around a problem, the best result for the organisation is often to get all stakeholders working together for a common solution.

This is where the role of business analyst particularly adds value to an enterprise.

BAs can ‘boldly go’; we can challenge an understanding of the status quo; we can help organisations to break out of silo working; and to implement business processes rather than run business functions. That’s our job.

The best work by business analysts is done even before a project manager has been appointed; to work with senior stakeholders and product owners, to build business cases, and help prioritise and select the right projects to be done. In effective organisations, this is an ongoing activity, establishing an evolving roadmap, and helping ensure that the impact of the backlog is understood before a sprint starts.

And of course, when a product owner is a busy manager, who has so much ‘business as usual’ that they cannot commit themselves full-time, it is the business analyst that steps in to fulfil the role as a delegated product owner.

Indeed, many writers have gone on record, saying that a business analyst, with a reasonable understanding of the business, is a good fit for the role of product owner – Scot Ambler (Agile Modeling), Mike Cottmeyer (Agile Chronicles), and Laura Brandau (Bridging the Gap), Dean Leffingwell (Scaling Software Agility), etc.

Great discussion, I’m definitely a “BA’s are pigs” in terms of the agile phrase that relates to this – in the nicest possible way of course!
My thoughts are below. These are in the context of a project delivering business capability with some level of discovery still required – i.e. it’s not a rewrite of an existing system. Also I am an architect – I see things as models and constraints and stuff – forgive me.

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.

OK, I’ll confess – I was the analyst advocating for the work of analysts to be considered of value to an agile project in Mike’s blog. I made the mistake of mentioning requirements elicitation and validation as valid pieces of work, when this isn’t JUST what BA’s do.

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.