When I started working on my first Agile project in 2008, I remember hearing a lot about “developers” and little-to-no mention of project managers, testers or business analysts (BAs). With years of experience in the waterfall method, I started to wonder how I could fit into an Agile team. Did BA’s fit into the Agile […]
When I started working on my first Agile project in 2008, I remember hearing a lot about “developers” and little-to-no mention of project managers, testers or business analysts (BAs). With years of experience in the waterfall method, I started to wonder how I could fit into an Agile team. Did BA’s fit into the Agile method? If so, where?
I soon learned that the Agile Manifesto was written from a developer’s perspective and while it could be interpreted literally, most Agile teams saw the value that the other roles brought to the table and continued to include them on their teams. Developers still wanted to write code, testers still wanted to validate, and managers still wanted a successful delivery of the solution. So I got my CSM, and jumped into the world of Agile Software Development. A world that I think we can all agree helps reduce waste and uncertainty on complex or novel projects.
Since then, I have been a part of many successful Agile delivery teams. As Agile becomes the “new normal” for software delivery, I often think back to my early concerns. I drafted this post with my top 5 lessons learned in becoming an Agile BA. Read on to see if this helps you!
Lesson #1: Adapting to the new model takes time.
Agile is less about individual contribution and more about team commitment and ownership. As an Agile business analyst, I no longer worked with the customer during a long, protracted phase of requirements elicitation to arrive at the full concept of the solution. Instead, I had to be deliberate about eliciting requirements based on priorities and dependencies that aligned with the overall vision. I, along with the team, had to patiently let the solution emerge through multiple cycles of incremental changes vetted by regular stakeholder involvement. Change was not something that had to be managed but expected.
At first, this pattern of engagement may be unsettling, but over time, you’ll realize the benefits. After all, how many of us have ever spent months writing requirements for developers who then produced a solution the customer didn’t accept because their needs had changed? With Agile, everyone is always in the loop.
When you switch to Agile, you may be overwhelmed by the sheer number of items in your product backlog. How are you going to get everything done? By progressively discovering and delivering requirements, I found that identifying the tangible and intangible benefits of a requirement helped manage a growing backlog.
Shifting the conversation from “What” to “Why” often surfaced the true, underlying need. I’m surprised by how often business users would specify the “What” without explaining the “Why”, an approach that usually resulted in overly precise requirements that stifled the team’s creativity and innovation. Having a clear understanding of the “Why” made it easier to build the compelling story for new features or technical debt while determining what had to be done now and what could be done later.
|Alone we can do so little; together we can do so much. — Helen Keller|
Despite years of working independently, I soon understood that the best ideas are created through collaboration, not in a vacuum. I considered the perspectives of others – domain experts, technologists, testers, end-users, and executives – to ensure requirements factored in constraints and capitalized on opportunities. I realized it is better not to risk sacrificing the quality of the solution by assuming that I had all the answers. In Agile, the team is the arbiter of the solution, not solely the business analyst.
Have you ever wished you knew some feature your customer wanted wasn’t feasible with your technology stack sooner? With Agile, project mindshare is distributed across the team, not resting solely on your shoulders. So take a much-deserved deep breath!
With shortened cycle times between releases, there is little time for intensive manual testing. So teams need to incorporate automated tests at the unit, integration, and acceptance levels as the solution is developed to safeguard against functional regression. Business analysts play an important role in the creation of automated acceptance tests. Using the Given-When-Then syntax structure and realistic examples allow business analysts to communicate to the team how requirements will be validated before development begins in clear, unambiguous language. This approach to requirements increases the likelihood that the team will deliver the right solution.
Becoming an Agile Business Analyst is more of a mindset shift than a change in actual behaviors; it’s about being comfortable with a solution that evolves rather than prescribing a static solution at the outset. The basics still apply, but they are altered for an Agile context: facilitation techniques are executed in a more targeted fashion to focus on the discovery of high-value, high-impact business needs, requirement modeling is more for building a shared understanding of the team’s goal as opposed to being a standalone deliverable, and requirements and the techniques used to elicit and model them are a means to an end with the end being the right solution.
What lessons have you learned as an Agile BA?
“Between stimulus and response, there is a space. In that space is our power to...
Getting started with Agile is straightforward; succeeding with it is challenging. You can’t just introduce...