BAs on Agile projects

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.


About James King

I coach organisations in how to better make use of the untapped talent they have in their people and to explore new ways of understanding and solving new and old problems I live in Sydney with my wife and daughter and have no real hobbies beyond the usual boring ones of reading, writing and watching tv.
This entry was posted in Uncategorized. Bookmark the permalink.

2 Responses to BAs on Agile projects

  1. John Watson says:

    James: an interesting Blog. It seems to me that what you describe as a Business Architect is what I have always understood to be the role of a Systems Analyst (stick the word “Business” in front if you like}.

    “Agile”, “agile”, “traditional”, “planned”; whatever word we use to describe the chosen approach doesn’t significantly the objective of the Systems Analyst and that is to ensure that the customer gets the complete appropriate solution to their problem. The solution might or might not have an ICT component.

  2. James King says:

    You are right John, its not a new idea. But building IT solutions instead of complete ones has been happening since we invented IT and continues to occur all too often.

    I have been in a couple of conversations recently about BAs not having a role anymore on the one hand, and business customers expressing concern about the lack of supportability and appropriateness of the solutions rolled out by some “agile” teams.

    So whatever we call the role, it seems like we are starting to forget about its importance again.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s