Thinking for a Change

XP user group event 05/05/2010

iLean will host the next XP user group event on May 5th 2010, in Kontich.

What can Business Analysis and Agile mean for each other?

The International Institute of Business Analysis (IIBA) has created the Business Analysis Body of Knowledge (BABoK) to capture the experience of business analysts worldwide on a wide set of projects. According to the BABoK, “Business analysis is the set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals.”

Meanwhile, Agile methods, with their own methods of understanding needs and proposing solutions, have been sweeping through many companies.

Is there room for business analysis on Agile projects? Can agile teams learn from business analysts? What happens when business analysts work in Agile teams?

The IIBA has started up a workgroup to create an “Agile extension” to the BABoK. This extension will provide practical guidance to do business analysis in Agile projects, based on experience. We’ll present this effort so that both communities can review and contribute to this project.

If you want to participate in the discussion, join the Agile BA Yahoo group.

Register for this free event on the Belgian XP Group wiki.

Why Agile + Business Analysis?

Why am I interested in seeing the Agile and Business Analysis communities collaborate?

Business Analysts could learn something:

• You don’t have to specify everything upfront. You can deliver your analysis incrementally and iteratively, at the pace it’s consumed by the implementation team(s), prioritized by value and risk.
• You don’t have to specify everything in consistently excruciating detail. You can ask your team mates what information they need and only provide just enough detail, depending on how risky the topics are.
• You don’t have to do everything alone. You can coach other team members to apply business analysis techniques.
• You don’t have to specify things before the project starts and move on to the next project before you see the results. You can be a full member of the team that delivers value and participate in the release parties.
• You don’t have to be an intermediary (or worse, a “Shuttle Diplomat“) between “The Business” and “IT”. You can be a facilitator who brings out the best in the whole team.

Agile teams could learn something:

• You don’t have to invent “Business Value”. Business Analysis can help you link the benefits the organisation expects to the capabilities it needs.
• You don’t have to create a “Vomit of User Stories” and spend an inordinate amount of time “grooming” that backlog. Business Analysis can help you to focus on the value-adding capabilities.
• You don’t have to make the giant leap from organisational goals to detailed user stories in one go. Business Analysis provides many techniques to gradually break down large problems.
• You don’t have to limit yourself to User Stories. Business Analysis provides may other ways of modeling what users and stakeholders need.
• You don’t have to go it alone as Product Owner or Onsite Customer. Business Analysts and business analysis techniques can help you get the job done, identify more value and work at a sustainable pace.

I’ve been applying business analysis techniques since my first agile project in 1999 (although we didn’t call it business analysis then). The results:

• Our projects were smaller, cheaper and delivered faster than those of the competitors.
• By focusing on the few high value delivering features, we were able to release incrementally, thereby generating real value quickly for the customer.
• By focusing on what was really needed, not what was wanted, our systems were smaller, easier to understand and easier to maintain.
• By using simple but effective business analysis techniques the cycle time from request to proposal was dramatically shorter than our competitors’.
• By having everyone in the team working on the business analysis we often came up with innovative solutions and delighted our customers. How often do your customers tell you “Wow! I didn’t know you could do that!” ?

It’s not enough to appoint someone to be the “Product Owner” and expect to become a productive team. More likely, you’ll end up with a burnt out Product Owner. First of all, you should give effective tools to your Product Owner. Secondly, you shouldn’t build such a bottleneck into your team; provide your whole team with those tools. I know in which community you can find many such effective tools…