Categories: Business Analysis
While the team is collaborating on PMI’s business analysis standard, we have been very conscientious about making sure we are not favoring predictive over agile approaches, or vice versa. We are focusing on covering topics as inclusively as possible, while also offering suggestions on how to adapt activities to any approach. I promise we will have more to say on this in future posts!
For now, I wanted to share some examples to demonstrate we are being agile-friendly when developing the standard. Our work is based on community research to understand what common and best practices are. However, we also learn a lot when things do not go as smoothly as desired, so it is interesting to think about those situations also.
One particular experience in a large organization actually inspired many ideas for me. This large global organization was making a transition from a waterfall to an agile delivery approach, and like many others, ran into some issues. Here are the most critical issues with which our business analysis standard could have helped.
Issue #1: Throwing the baby out with the bathwater
This organization previously demonstrated really strong business analysis practices in waterfall approaches. They understood projects’ business objectives, they created detailed visual models to guide their requirements, and they wrote nice requirements statements. However, during the transition to agile, the business analysts were scrambling to find a role. They jumped right in to help write user stories and acceptance criteria—not a bad idea in and of itself. However, that is all they wrote—lots and lots of textual user stories. The entire team filled the backlog with user stories simply by brainstorming to see what came to mind. Then, the team prioritized the user stories based on what the business said was most important instead of looking at the business objectives. It is as if they forgot all of their good business analysis practices when they moved to an agile approach!
We hope to help: This business analysis standard will hopefully be a reminder, evidence, and explanation of how business analysis is just as important in agile approaches as in others. For example, the team could still create visual models to help identify or explain user stories and acceptance criteria. Similarly, the business value or business objectives are perfect to help prioritize the backlog against something other than intuition.
Issue #2: Being an agile purist
This organization had previously been coached that being purists was the only way to deliver with agile approaches. Their biggest and highest risk project was using agile practices, but the others were not. Not surprisingly, this generated a lot of tension between the waterfall projects wanting to only receive interface requirements up front and the agile team not wanting to commit to what they would build or need in their attempt to be purists. The solution they eventually landed on was to temporarily create agile requirements documents. Many agile purists would have cringed! However, the agile teams documented “just enough” about what they would need from the waterfall project teams so those teams could plan for the interfaces. They documented a little bit about each interface they knew about up front with the equivalent of business requirements.
We hope to help: The standard will help offer suggestions about how to adapt business analysis practices for agile approaches, but they are only suggestions and are clearly labeled that way. As Cheryl nicely explained in a recent post, there are many ways to perform the business analysis processes. This team would be the first to admit there is no one size fits all “way” for any of these practices, including the agile ones. Organizations have to determine how they wish to use (tailor) the guide to the culture and operating environment of their corporation.
Issue #3: Waterfall communication style for agile interfaces
When the organization first started using agile on the large project that interfaced to many others, they had excellent communication within the agile team. However, they neglected to plan for similar levels of communication with the non-agile teams. The reality is, they probably needed more communication with outside teams than with their own. There were so many interfacing project teams that just jotting down requirements about interfaces was not enough; it took a somewhat intimate understanding of the interfacing systems to know if the details were all understood. By the end of the project, the agile team actually had a full-time resource whose job was to talk to all the interfacing project teams on a regular basis to identify areas of risk, points of conflict, and high priority interface requirements.
We hope to help: The collaboration points from Business Analysis for Practitioners: A Practice Guide were well received in the community because they help you think through how you might collaborate with project managers. This standard will continue that spirit with even more ideas about whom you might collaborate with and on what!
PMI’s business analysis standard probably won’t be the answer to all problems that organizations face in their transition to agile. However, I can assure you there will be a substantial amount of content about what things you can do with business analysis in agile.