Agile for Business Analysts
This past week I was fortunate enough to be a speaker at the Agile Development Practices show in Orlando, Florida. I had a great time while I was there. I was even asked to be part of a 3-member panel sponsored by Borland to speak about agile transitions. I was honored by the invitation to the panel, and had a great time interacting with the others that were there.
But my primary reason for being in Orlando was to give a talk titled “Agile for Business Analyts.”It was a 90 minute session primarily aimed at helping business analysts understand that the Business Analysis Body of Knowledge (BABOK) from the International Institute of Business Analysis (www.iiba.org) could be interpreted in an agile way. I must have done something right during the presentation because the 25 people in attendance gave it an average score of 9 out of 10 on their evaluations! While doing the presentation I felt ratified in my opinion that the agile community is ignoring several important roles when teaching organizations how to use agile effectively. I’ve said many times the agile community is addressing project managers, some developers, some product managers, some testers, but not enough business analysts, line managers, and others. In fact, I’m pretty sure most people would say that every position except project managers are basically being ignored. I still believe Agile For All has the right meaning in today’s agile world. OK, soapbox mode off now 🙂
The business analysts in attendance clearly felt confused by how to function in an agile environment. The thrust of my presentation was how easy it should be to convert from waterfall to agile for people responsible for requirements definition and management. The phrase “Just enough, just in time” is a big help. The pressure to get it absolutely right the first time is no longer present. Huge requirements documents are a thing of the past. Elimination of wasteful work (ie, analyzing requirements too far in advance) and deferring of commitment (admitting the detail is unknown until some other events occur) are also important items to keep in mind.
If you are a business analyst, or you know of business analysts that are confused by how the BABOK supports agile, tell them to put on their “agile glasses.” They need to think iterate, retrospect, and just enough, just in time. While at the conference I spoke to Ellen Gottesdiener about agile business analysis and we both agreed there is not enough information out there. Hopefully version 2.0 of the BABOK will take an approach that is more in sync with agile. I guess I’m not terribly hopeful of that, but who knows.
Have questions about agile and business analysis? Feel free to contact me and discuss it, or comment here so others can discuss it as well.
Hi, I have questions.
When we are doing backlog grooming, some user stories are lack of clarity and needs more analysis; the BC analyst didn’t agree we should allocate time to do analysis task; we should implement and along side we should know what and how to do it.
Q: can we include analysis task into sprint planning? if yes how effectively we can do that; as the BC’s concern is we will invest too much effort into it; and not contributing to the actual development work.
Thanks in advance.