Search This Blog

Loading...

12 April 2012

The role of the analyst on an agile team

Left to right: Me, Annie, Trent, Paul, Kaye, Erik,
With Kevin standing, possibly about to throw something at us.

On Tuesday night the local business analyst community met up to hear a debate facilitated by Kevin Broughton.  The topic was "Business Analyst: Role or Competency?"

We had 5 great panellists, and me as a ring-in.

On the pro-role side there was Paul Velonis and Erik Van Eekelen from Elabor8, Kaye Knight, contracting analyst gun for hire, and Trent Barnes, a recruitment consultant who specialises in BA, PM and QA roles from CicuitIT.  On the pro-competency side we had Annie McGlade, a BA Competency Lead at a large bank and myself, a natural contrarian.

Given the audience was a bunch of business analyst (peppered with a few analyst programmers) the debate pretty squarely landed on the side of "There is a clear need for business analysts, s don't be quitting your day job just yet."

Let me see if I can summarise the arguments in the order they were presented.  I'll make a few mistakes because (as a ring-in) I was trying to work out what I was going to say while they were taking.  I'll editorialise as well. Maybe the guys will drop in some comments below.

Paul started with the disclaimer than analysts are probably not required on small development initiatives where there are 2-3 people on the team and a single customer.  Things are straightforward and the communication lines are simple. Assuming your developers are competent and your customers knows their business and has some sense of the market they are working in you should be okay.  But, as soon as you start to scale - either in team size or project complexity a business analyst becomes a highly valuable asset for the team.  Systems thinking, asking 'why' a lot, and helping people deal with complexity were just a few of the issues he said business analysts were useful for.

An interesting note Paul made when speaking was that Elabor8 analysts were all trained and coached in consulting skills, and the 'business analyst as consultant' very much flavours the way he sees an agile BA working.  [Craig editorial: Me too, by the way.  Facilitation rather than system analysis and modelling skills are clearly the more important skill for an agile BA.)

Erik followed up (or was it Kaye next?) with examples of how analysts add value.  Essentially he amplified what Paul was saying, and expressed a caveat on Paul's idea of small teams not needing analysts, saying that while they may not need one, an analyst can usually help a lot even in these situation.  A key part of Erik's argument was that he believes that the members of a multi-disciplinary team should help each other out to get their stories done, but that that every discipline (BA, test, dev) demand its own, very specific, skills to do the job properly. That's why he said that any Agile team - no matter how small- should have a BA, a Tester and a Developer: it takes skill to play each specific role.

Kaye introduced the Swing picture below and talked about the need to continually ask 'why' and to seek out answers to questions and to challenge assumptions. She also highlighted the analysts ability to think about the situation independent of technology, and thus help with customer centric thinking on the team.


Next up was the other side of the argument; The analyst role is not needed on agile teams, and all that is required is the competencies.

Annie went first and talked about how any person with sufficient motivation can be trained and coached to perform the role well. And conversely that many people in the industry operating with the BA job title were not actually adding a lot of value to the teams they were on.  She also made the point  that job titles come and go, but it is the tasks, activities and thinking tools that are required for teams. Who has them doesn't matter so much.

Lastly I went and my argument was that hand-offs degrade flow and that applies just as much to project teams as it does to organisational silos.  As a bunch of analysts, I sad, we are all familiar with the boundaries on swim lanes being obvious pain points. (Erik and Kaye countered me with the surgical team metaphor. A bunch of specialists working as a team are still specialists.)

I tapped into the emotions with two stories:  Firstly, when doing some BA competency assessments I didn't see strong correlations between effectiveness and competency. What was much more important for team effectiveness was playing as a team.   And secondly I saw an example of a team where a BA became a single point dependency, and when they were away the team crashed. But that crash and absence was a catalyst for further improvements from team outputs. (Of course I was playing a devil's advocate and Erik once again called me on the anecdotes != statistics rule.)

The debate was interesting and fun. We explored a few ideas, and had a good Q&A session afterwards.

A few closing notes because I wanted to say this but forgot on the night;

  • The only Agile model that is dogmatic about roles is Scrum. Everything else pretty much accepts whatever your current staffing model is, with the caveat that the team should work together as collaboratively as possible.
  • It strikes me that the emergence of the BA role was in response to a need for a generalist to act as a boundary spanner across the organisation. With the IIBA doing a very good job of defining the role, with it's boundaries (i.e. a BA is not a change manager or trainer) they are going to create a vacuum for  that generalist role and something else is possibly going to have to take it's place.
So, I'll leave it at that.  If you were there I'd be keen to hear your thoughts on the night.