In my previous article, How I Became an Agile Business Analyst, I talked about my passage from the world of good old fashioned ‘write it all up and get it signed off’ business analysis into the uncharted territories of agile.
In this article I’m going to describe my first experience on an agile project. I should explain that I joined this project not as a BA but as a developer, in particular to bolster the team’s Java skills. So whilst I taught them a little Java, they taught me a little agile.
Actually, these guys taught more than a little agile. They were fanatical about agile. They had recently been ‘transformed’ by the agile consultancy ThoughtWorks. The ThoughtWorks model is very effective – they drop in a SWAT team of agile experts, mix them in with a small team of the client’s regular staff, and then run an agile project using the mixed team. Once the regular staff are fully ‘converted’, the ThoughWorks guys move on to a new client, and the enabled and empowered staffers set about running agile projects on their own.
So although ThoughtWorks had galloped off into the distance by the time I arrived, their spirit was very much alive in the project team!
Details, Details
The project was run pretty much to the Scrum methodology, with a bit of Extreme Programming (XP) thrown in for good measure. So, we delivered working code in short (2 week) increments, we programmed in pairs, we wrote automated tests and we integrated continuously. We played ‘planning poker’ to scope out each increment, and we reflected at the end of each increment.
All of this is standard agile, and is now well-understood in the agile community. What’s more interesting (especially to readers of this website) is how we did the analysis piece, so let’s delve into that in some more detail.
Not So Agile
The first important point is that we did have a BA on the project. There’s a lot of debate about the BA role on an agile project. XP doesn’t recognise the role at all – the developers work directly with the business stakeholders to do the analysis. Scrum does not have a named BA role but does have the Product Owner role which, when you get down to it, looks a lot like a BA in disguise (disguised as a pig, perhaps – that’s a Scrum joke :)). Debating aside, we had a BA, and we called him the BA.
Secondly, and perhaps more surprisingly, we had a Functional Specification (FS). The FS was written up-front by the BA and was used as an input to the development process. The main reason for its existence was that the agile approach was kind of a trial, initiated by the IT department, and therefore not fully embraced across the organisation. So there were various people still insisting on having a document to sign off.
Now, if you know your agile, alarm bells will be ringing at this point. A comprehensive, signed-off Functional Specification acting as a contract between business and IT pretty much flies in the face of two, if not three, of the four key values in the Agile Manifesto.
However, in our case, it wasn’t as bad as all that. The FS was there, and it did act as the starting point for development, but it wasn’t fixed in stone, and it didn’t act as a replacement for an ongoing dialogue (via the BA) with the business. Mostly, it just meant that the BA had an ongoing background task to keep the FS in line with the changes that occurred during the project. As far as I could tell, change control was fairly free and easy, so this wasn’t an onerous task.
In terms of its contents, the FS consisted largely of web page mock-ups and various lists of individual “requirements”. It was good up to a point, but it didn’t include detailed use cases with rigorous alternative flow analysis, so you kind of knew up front that there was probably another 50% of content missing from the document.
Getting More Agile
The next relevant analysis event was the planning session at the start of each 2-week increment. As a team, including the BA and tester, we identified the features (in the FS) that were the highest priority. We created user stories for each one, with the bigger features being broken down into manageable chunks. In true agile style, we wrote each user story in the format “As a…I want…so that…” And, of course, we wrote it on an index card and stuck it on the wall. We discussed each story, with reference to the FS, and played planning poker to get an effort estimate for each one. Once we had enough work for the increment, we stopped, leaving the remainder of the features for a later increment.
The next job was to determine the acceptance criteria for the stories. There’s no rocket science here – just statements like “when I do… then the system does …” i.e. a set of business rules or (my preferred metaphor) use case fragments. The important thing is that all acceptance criteria must be testable.
The acceptance criteria for a given story were determined by the developers working on that story (remember, we were pair programming), in conjunction with the BA and tester, and with reference to the FS. Some developers would define lots of acceptance criteria and others just a few. The latter tended to discover other criteria later that they had missed. In other words, they weren’t very good analysts :). Either way, sooner or later we ended up unearthing the extra 50% of the requirements that were missing from the FS.
So off we went, developing the stories. We used the acceptance criteria to write automated acceptance tests (using a tool called Selenium), and then we wrote code which passed the tests. Typically, we delivered about half as much in each increment as we had planned, and the remainder dropped into later increments.
A Retrospective
The system we eventually delivered worked well and the business loved it. It didn’t deliver quite to the original timescales but it also wasn’t hugely late. The project was, overall, successful.
But there were definitely some lessons to be learned. So let’s reflect for a minute.
Firstly, we consistently under-estimated the size of each story, and thus delivered less than planned in each increment. The reason for this, I think, is very well put in Alistair Cockburn’s article Why I Still Use Use Cases. A user story summarises the happy-day scenario for a given function (i.e. the main flow of a use case). But it doesn’t give you any idea of how many alternative flows there will be, and this is where 80% of the work lies. This detail only comes out when you derive the acceptance criteria, which is after you have already estimated the story and scoped out the increment.
Another problem we had was that at the start of each increment, we were all busy defining acceptance criteria at the same time. We all wanted a bit of the BA and the tester and the same time, and so there was contention for these resources. What if there hadn’t been a BA on the project (XP style)? I guess we would all have been in contention for the stakeholders instead.
And a final problem we had was that in some cases, we needed answers from the business in order to complete our acceptance criteria. Sometimes the answers were not immediately forthcoming, and so we were not so much pair programming as pair thumb-twiddling.
All of the above issues seem to point to the same root cause. It would probably have been better if the acceptance criteria had been defined before the increment started. That would have led to (a) better estimates, (b) less contention for resources, and (c) less thumb-twiddling waiting for answers.
But doesn’t that start to sound a bit un-agile? Aren’t we back to doing all the analysis up-front and then suffering all the usual problems associated with that? Well actually, no, I don’t think so. There is a happy medium which still sails close to the agile wind and yet cuts a swift arc around the jagged rocks of the above problems.
In my next article I’ll describe my first ever agile project as a Business Analyst and explain how I steered my good ship through these unstill waters. Now how’s that for a metaphor? 🙂
Pingback: Tweets that mention My first ever agile project -- Topsy.com
Good explanation, thanks for sharing.
I’m curious to find out how you transition between the developer mindset (technical) and the BA mindset (analytical).
Hi Bennett,
I don’t have too much trouble transitioning between the two roles. In fact I find that my experience in one role informs the other (and vice versa).
For example, I can do a better job of the analysis piece because (a) I know what is technically possible, (b) I can easily knock up working prototypes and (c) I know what level of detail a developer will need in order to do their job.
Likewise, I can do a better job as a developer because I know what to expect of the functional design and when (and how) to challenge it.
The tecchie mindset does cause me problems as a BA sometimes. Every now and then I produce a spec which is functionally correct but difficult for a business stakeholder to read. For example, I wrote some business logic today in pseudo-code with IFs, ANDs and ORs, because I can see immediately how it will translate into code. But I know that my stakeholders would probably prefer a graphical representation e.g. decision tree/flow diagram.
One thing I have discovered is that I am an awful tester! On my last project I tried being both the BA and the tester – the idea being that I would be able to spot defects easily because I designed the system myself. I was able to test the happy-day flows OK, and also the specified alternative flows. But I was hopeless at exploratory testing- I just don’t have that perverse desire to break things that good testers have!
Thanks Tony
I was brought up as a Developer with many years of experience and have basically mastered this role with nothing more to achieve.
As a QA, this was part of Development (during my days anyways) and have mastered this as well. Nothing gets by me to Production. I suppose working with mission-critical systems have inculcated in myself the sense of ownership and responsibility. Imagine the fall-out, for example, if someone was paid incorrectly on payroll or incorrectly billed on their credit card.
I have done BA work, albeit not exclusively, as part of the gamut of my collective IT exposure.
Now, somewhere in the sacrosanct vestiges of my buried brain cells, something tells me that the best BA’s are those who don’t like development work. They may have tried it, found out they didn’t like it and plunged purely into the BA pool with nary a look back. I can’t put a finger to it, it’s just a theory, I may be wrong…but that’s what my brain cells are telling me.
Does that then follow that good developers make bad BA’s ? Hmmm….brain cells, what do you think ?
Thanks again Tony for sharing; very informative.
Hi Bennett,
At the risk of upsetting a few people…
My own experience is that *in general* BAs from a technical background actually do a better job. Being on the receiving end of a BA’s output puts you in a good position to know what good output looks like. Also, a big part of analysis is (functional) design, and programmers are generally good designers. Most non-technical BAs I have met tend to capture requirements but not design a solution.
But that doesn’t mean that *all* good developers make good BAs. On the contrary – most of the developers I know would make lousy BAs – not because they don’t have analytical skills but because they don’t have the people skills.
I think that to be a really good BA you need to be a really good logical thinker as well as a really good communicator. Most of the people I know are either one or the other, but very few are both.
So maybe the best BAs are developers who *do* like development work but like BA work *even more* because it allows them to make use of their logical/analytical skills *and* their people skills.
That’s certainly what attracts me to the job anyway 🙂
Pingback: Black Box BDD with Watin « martinsharp
Pingback: Tech Talk – Blush Packages » Blog Archive » Configuring Black Box BDD with Watin , CassiniDev, NUnit , StoryQ, ASPMVCContrib, Reshaper
Pingback: Configuring Black Box BDD with Watin , CassiniDev, NUnit , StoryQ, ASPMVCContrib, Reshaper | Thoughts of the CloudCoder Team
That’s exactly what atracts me too.