Of course, my answer is “it depends”.
Irrespective of the job titles of the roles involved, I agree with Scott Ambler that analysis is so important that we do it all the time. This means we have to constantly think about the big picture, and the short-range view, explore the meaning behind our user stories and be ready to delve deeper and explain the intent and design of the product we are working on.
So what are some of the important things that I have to understand and possibly do differently if I am working in an agile development team?
1. Don’t throw the baby out with the bathwater
Just because I’m working in an agile team it doesn’t mean that my existing skills and knowledge are now invalidated. Yes – there will be some things I do differently and some of the documents I used to produce are no longer needed, but a lot of my skills and techniques will still be useful and applicable.
2. Let go of ownership and be comfortable with sharing
In the “old world” I had a lot of hidden power as the “owner” of the requirements documents. Whatever I chose to write down would be in the document and would probably find its way into the product. In an agile team, I will be responsible for bringing the right people into the workshops and collaborative story identification and elaboration sessions – building stories and elaborating them as part of the development is a team activity, I need to learn to let go and be comfortable in the facilitator rather than arbiter role.
3. Value comes before everything else
I have to find and express the value in the user stories, standing up for value over technical expediency and “gee it would be great if…” urges. Value must be traceable back to the goals, objectives and outcomes of the initiative and aligned with organisation strategy. This means I need to deeply understand these goals and objectives at every level and advocate for them constantly.
4. Relationships are more important than requirements
I know that most of the requirements identified early in the initiative will change as our understanding evolves I need to be comfortable letting go of a feature or user story, instead focusing on building strong collaborative relationships with the people who have the needs and the people who will work to fulfil those needs.
5. Flow matters
Rather than the large batches of work we used to do (build the full requirements document and hand it over to the designers, etc) agile analysis requires us to take a continuous flow perspective – having the big picture in mind and slicing off the small pieces of value as we build the product, slicing and dicing the epics and stories to identify the right pieces of value just in time.
6. Governance matters
Just because we’re in an agile project doesn’t mean we can disregard organisational governance – there is (normally) a valid reason behind those governance rules which we sometimes rail against. Compliance and audit are not our enemies, they represent a part of the business that has legitimate needs we need to meet and protect. Find out what the underlying reason for that compliance report is, then figure out how to meet it with the least cost in time and effort, cultivate allies and get them involved in defining DONE so everyone understands what must be part of the working solution.
There’s lots more to this topic and I’d love to talk to you about it – come along to the Agile Business Analyst class and we will delve deeply into the topics together.
Post by Shane Hastie