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!
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.
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?