The Fourth Day – Establishing the BA Role

Note: This is part of a new and continuing series which is collected under the Agile Journey category.

Prelude
In the last post The Third Day – Expanding Agile I described how we encountered many challenges as we worked to apply agile to traditional IT efforts and projects. We discussed two challenges in particular (team structure & unanticipated emergencies). We pick up in this post our challenges in approaching our customers & their needs from their perspective and not from a technical or development mindset.

Establishing the BA Role
Initially my team was solely focused on coding software. I had a team of .NET developers who supported, enhanced and built business applications for our various customers. We did not have QA resources nor did we have business analysts. When customers had new requests, they would come directly to me. I would serve as the liaison between the business and developers facilitating requirements gathering and ensuring what was ultimately delivered met the business’s needs. Yet serving in this role became unfeasible as my team’s responsibilities and applications under management expanded. There were just too many moving parts for one person to coordinate. As a result, I established the business analyst (BA) role within the IT process.

Establishing the BA role was tough as many business users didn’t understand what a business analyst was and thus they wondered why we needed the role. Instead they argued that we should be hiring developers as it was more code written that was needed. Another challenge we faced was that the business viewed the BA as a project manager. Thus many of the initiatives we were working on became an ‘IT’ project and not owned by the business. We were unsuccessful, for a time, in changing this mindset and as a result, our BAs were not able to focus their attention on legitimate BA activities (enterprise analysis, requirements planning, requirements gathering & etc.)

Recently, with the help of the business, we have been able to evolve the BA role. The BAs now fulfill the role of product owner on the scrum team. The BAs are now officially titled as either application analysts or product managers (depending upon focus). We have gotten away from the term ‘Business Analyst’ as our initial experiences necessitated a change (superficial or not).

We are now focused on further refinement of the ‘BA’ role within the development team. One vital step in this effort was to acquire a highly talented and experienced product manager. We got fortunate at the end of 2009 and were able to acquire this talent and now this individual is leading the charge in transitioning the BAs into the product owner role on the scrum teams.

In addition to hiring an experienced leader, we have also developed a BA competency model that outlines a skills inventory for the role as well as proficiency definitions. This competency model enables us to establish targets, assess proficiency, measure and prioritize gaps, leverage team strengths, create individual development plans, and help standardize tools and processes.

Conclusion
Establishing the BA role has definitely been a challenge. Many organizations have this role defined and integrated within the business (via a PMO) as well as within IT. We did not. Thus we created the role within the IT development group out of sheer desperation to better address the demands our customers were placing upon us. We have a long way to go to truly execute the role appropriately and as outlined in our competency model. However as we learned with Agile, change isn’t a short process and must be looked at in terms of months and years.