More than XP. More than one day.

The session will cover how a BA has learned what works well and what is not so useful in the environment she works in. The aim is to show how the agile approach can be adapted for different sizes and types of projects and how team dynamics change based on the team size and what the team are trying to deliver.

I’ve been working at Sky/easynet for 18 months on an agile project that started with 6 developers and now has 30. Before this I had never worked as an agile analyst. During the last 18 months the way that Sky/easynet approaches analysis and development has changed often and there are many challenges we’ve faced specifically because of the type of project we’re working on and the other teams/systems (outside of our team) that we have to work with.

Session brief: Initally I’ll describe what the project at Sky/easynet has built and how our team works now (briefly). Then I’ll mention issues that we had along the way and discuss each of them in a little more detail. The idea will be that people can ask questions as we go along. Some of the areas I’d like to talk about are:

1. What’s in a name? How important is the story name?

   • what the consequences of misleading story names have been, but also where the name is not so important

2. Story size; How big is too big? And how small is too small?

   • lots of examples; starting with our very small stories in release plans a year ago and the problems this caused; covering where we’ve had arguements about very large stories and giving the BA/business point of view as to why they needed to stay large

3. Upfront analysis - how much do we need to do?

   • In our environment, more than you think! Giving examples of BT system work and why it’s better to do that in detail as early as possible. Then contrast this with interface work which has been better left as late as possible.

4. Planning, planning, planning

   • lots of examples of horrible sessions, then describing our current process which works very well for us

5. Documentation - can we really do without it?

   • No, explain what we have discovered we really need (and say why)

Ultimately I hope that describing my learning curve provides a view into the analyst role to people outside the analyst world as well as helping other BAs in problems they might face. In addition I’d like to provoke debate about some of these issues and show that agile can embrace a wide range of working envirnments.