You might have already read Shane Hastie’s article on analysts and agile project approaches. He commented that it might be a good idea to have a BA on an agile project.
Some of the responses he got were supportive and some suggested that actually agile projects can go faster when the developers take over the work of the BA and remove “the middleman”.
I had a couple of related conversations this week though that suggested that sometimes the developers are, while coding faster, not actually doing a good job of focussing on the real solution.
One organisation has recognised an issue that some of their (evil?) agile projects are rolling out software that is not ready to be supported and does not include user manuals. This is apparently due to an extremist view of the Agile Maniftesto that concludes that documentation is evil and thus support documentation is not needed when we are Agile.
Talking to people at that organisation we uncovered a radical theory that some agile projects should be rolling our complete business solutions rather than just “software code that works”. Our new interpretation of the Agile Manifesto is that it actually supports working software – ie software that works well when implemented in the real world.
Fresh with this new information I went to see some people at another organisation and they mentioned that their BAs are a bit worried about their careers if they don’t get to produce quality documents. I rattled off my standard answer that BAs deal in communication rather than documents and that they will still be popular on Agile projects. But then I remembered some of the comments in response to Shane’s article … and I asked myself what a BA should really do on an Agile project.
The answer seemed so obvious it was worth writing a long article about it 🙂
In agile projects (whether established for good or evil) we often have a project manager (or scum master, or iteration manager) to organise things. And we have a product owner (or customer, or business guy) to keep us focussed on what the customer actually wants. We then have a squad of developers to build cool stuff and a tester or two to make sure we remember some quality and risk management along the way.
But our solutions are often so complicated that we find it worth appointing a solution architect (or tech lead, or lead engineer) to help with our technical direction. He/she then helps to
– Ensure the application integrates into the existing organisational application and infrastructure ecosystem;
– Help and guide the technical design and approach; and
– Help the project develop a good technical solution through models, understanding, collaboration and guru-ness.
But some Agile projects only build code when they should have built a bigger solution. And some Agile projects exist in a world where the busines integration and design actually gets more complicated than the technical design and itegration.
So it follows that it is sometimes worth building more than software. And it follows that we might benefit from having a “business architect” to
– Ensure the application integrates into the existing business ecosystem;
– Help and guide the link between the cool application stuff and the business solution design and approach; and
– Help the project develop a good business solution thought models, understanding, collaboration and guru-ness.
But then, of course, this is what business analysts do. So maybe we should retire our Agile business analysts and replace them with more highly paid Business Architects. These new beasts will be like BAs, but will be paid more and will be able to coordinate between process groups, trainers, business users and other “technical” groups.