Are you bouncing back and forth between agile and waterfall? It’s quite common these days for Business Analysts to grapple with both agile and traditional approaches to requirements and development work.
This can be frustrating, and Business Analysts may feel like a ping pong ball, getting smacked back and forth between two different worlds.
Assuming this scenario is not going to change, Business Analysts need to find a way to reduce their frustration level and think about their work a little differently. It’s time to change up the game!
Have you ever heard a coach tell an athlete, “Be the ball.” I never understood this advice, but it doesn’t work for Business Analysts in our Agile/Waterfall ping-pong scenario. So, let’s change perspectives. Instead of getting smacked around by multiple methodologies, Business Analysts can take charge of their methodologies. It just takes a shift in thinking, like this:
Now the Business Analysts are in the power position, taking charge of how to approach each incoming ping pong ball. Some might require finesse, some might require backspin, some might require a long volley, and we might even duck and let some fly right past us.
It’s the same for Business Analysts moving between agile and traditional projects—they modify their approach to match the work that is flying at them. The best way to survive and do consistently excellent requirements work is to consider what stays the same and what’s different.
To explore the similarities and differences, let’s see what happens when an agile ping pong ball and a waterfall ping pong ball collide. Hello, ping pong Venn diagram!
Let’s start with what’s different—team structures and team operations/procedures. In most cases, the structure of a traditional team looks a lot different than an agile team. A traditional team might have a defined hierarchy, where an agile structure might be flat, with several self-organized teams with loosely defined roles. The way the teams operate could be quite different too including the way the team collaborates, the timing and sequence of tasks, the process for reporting and measuring progress, etc.
BAs need to learn to roll with these differences, but luckily these differences don’t impact core Business Analysis work. It turns out the things that remain the same, in the center of our ping pong Venn, are the most important components of good requirements regardless of methodology. If Business Analysts focus their energy on these three areas, it will reduce the frustration of bouncing between Agile and traditional approaches.
Focus On The Customer
Both approaches demand we look at requirements from a customer point of view. The customer point of view carries most requirements and rarely fails us as a place to start requirements conversations. In both agile and traditional approaches, BAs are called to expand the definition of customer to include everyone who uses the solution internally and externally. BAs are also called to find innovative ways to identify and meet each customer’s rapidly changing needs.
Successful BAs in both agile and traditional environments use powerful conversations as the focus of their requirements process. Even in traditional/waterfall approaches, conversations are critical to getting to well-written requirements.
Powerful conversations take place with individuals or in groups and require a variety of elicitation techniques including brainstorming, games, models and visuals. Powerful conversations should be layered with whitespace—this means giving stakeholders time to process their thoughts internally before large group discussions.
Whether you are using an agile or traditional approach, cultivating conversations means dialog comes before requirements documentation. BAs let go of the temptation to hold a meeting to “review” a document or items in a tool before the team has a powerful and meaningful dialog. BAs who focus on conversations know that dialog before documentation speeds up the requirements process for both agile and traditional projects.
Avoid The HOW
Digging into the technical details, before the team understands customer needs, damages agile and traditional projects. So, let go of technical details. The BA role helps the technical team understand the needs and even collaborates on possible designs to meet the needs, but BAs should avoid the urge to tell the technical team exactly how to develop the solution.
Many BAs have knowledge of the technical details but realize this knowledge becomes outdated quickly. It can be tough to let go of knowledge, but remember, technical knowledge is not what makes BAs successful. Instead, focus on the user, goals, data, rules, and business process all with an eye on the future state. Don’t let your knowledge of the current or past keep you stuck there.
The truth is that BAs need to be versatile to survive! They need to be able to handle a wide variety of ping pong balls. This is not a new expectation. Successful BAs have always been able to operate in diverse environments. No teams or organizations work the same. Global teams, virtual teams, agile teams, hybrid teams, vendor teams and even internal teams choose different approaches to project work. Successful BAs stay focused on customers and conversations regardless of the methodology their team uses to deliver solutions.