Tuesday, March 22, 2011

Lessons learned from an agile scrum shop - Why Agile Business Analysts, con't.

An interesting statement came the other day from an agilest with the Mile High Denver conference.  They discounted the use of BA’s in an agile shop as something that only a bureaucratic company would do and not many mainstream agile shops.  I found that compelling and would love to hear from other development shops as to their experience on this.

My thoughts are that every development shop has someone that is filling the role of the business analyst in their scrum.  The agile process allows for scrum team members to rise to the occasion and fill the void that is presented which is the beauty of agile.   My challenge to this concept comes not from a bureaucratic company but one that has an ever increasing volume of products to support.    It is easy to say that those experienced can rise to the role of BA when necessary until you have spread those key resources (lead engineers, lead QA Engineers,  Product Owners, etc.) too thin for all the active products going simultaneous.  Not all junior team members have mastered the concept of Business Analysis and are often trained through pairing with lead team members.

Having a dedicated BA that serves as part of the scrum team can greatly facilitate an increase in overall scrum team velocity.  This came as a result of developers having very well vetted and designed requirements at the start of a sprint.  We found that tasking these BA resources as part of the scrum team can also facilitate the knowledge transfer amongst the entire team.  Similar to the scrum master or product owner roles, we find that we can task BA’s at only part capacity (depending on the product) so that they can take on more than one product.

Before we added BA’s to our agile role definitions, we had struggling velocity with some sprints actually accomplishing nothing but requirement vetting by sprints end.  After BA’s came into play, we found sprint velocity and overall customer satisfaction increasing.  I’m not saying we couldn’t have done this in a multiple of ways.  Some shops hire more senior QA engineers that often fill this role or hire only experienced developers.  For a smaller company (we are less than 25 developers), hiring a couple of BA’s to facilitate the agile process was a very cost effective way for us to operate with almost immediate results (within 1 – 2 months ramp up).

Anyone else out there have any similar experience?

No comments:

Post a Comment