I’ve seen so many CEOs, CIOs, CoE leaders, and technology directors come and go with their unique methodologies and approaches. Do you know what doesn’t change?—the way BAs do work to be successful; The BA mindset, the key tasks and core set of techniques, remain constant.
We may need to use a new tool, try a new technique, a different template or learn a new set of acronyms, but the mindset, tasks, toolbox still work regardless of methodology.
Success and failure do not discriminate by methodology either. I’ve worked with teams that consider themselves Waterfall, Agile, hybrid or generic. I’ve seen huge success and mind-numbing struggle in all types.
I find myself in the midst of the following questions and thoughts often: Does methodology really matter? Does the BA role change based on the project approach? Are Agile and Waterfall really opposites? Can we apply Agile principles to traditional environments? Is innovation really dependent on a particular methodology? How can we boost collaboration regardless of methodology?
Here is what I’ve learned about Agile and Waterfall approaches:
1. We need more collaboration in EVERY project.
What happens after your morning SCRUM or status meeting? Does everyone wander back to their cubes and belly up to their keyboards for the rest of the day, and meander into boring meetings?
Collaboration should be an all-day event! The occasional prairie-dog-pop-up to ask your neighbor a question is not enough. That’s not collaboration!
Lightening does not strike at your desk—you need to get up and get moving. Good collaboration is physically and mentally engaging. It’s not sitting at your desk or lounging around a conference room table. It’s a group of active people standing at a whiteboard with lots of dialog and movement. It’s a small group taking a walk and sharing ideas.
What about conference calls? Meaningful collaboration is harder over the phone, but it’s possible. Virtual collaboration does not involve one person reading a document and asking for feedback. It’s a group of people—not multitasking but—adding, moving, deleting from a virtual whiteboard. It’s a lively discussion where everyone contributes.
Even after years of Agile, many organizations still don’t collaborate enough. Too many teams still delegate work to individual desks and then throw it over the cube wall to their sequestered neighbors.
Teams should use collaboration techniques to see the big picture, to fully engage all stakeholders, and to generate more conversation and dialog.
2. Agile projects have BA tasks.
"Agile" roles, like Product Owner and SCRUM Master, are not all encompassing, neither are any of the Agile methodologies. They are not meant to accomplish everything needed to deliver a solution. Traditional BA tasks are still needed in Agile. You may or may not need the title of “BA” to do those tasks, but the tasks remain relevant.
Planning, monitoring, business need definition, communication, elicitation, requirements validation, traceability, etc. still happen in all projects. The factors that change might include timing, duration, emphasis and documentation. Rigor and adaptability might vary as well, but the basic BA tasks apply in all projects.
In an Agile project environment, you might replace the 400-page requirements document or the exhaustive, step-by-step process models with an evolving prototype or a sticky note-filled whiteboard with dry erase arrows. Either way, the fundamental tasks remain the same despite methodology. The BA uses many of the same techniques to get to the differing outputs. They may use the same technique more or less collaboratively. I hope it’s more collaboratively no matter what approach is being used.
3. Techniques don’t change.
Just like BA tasks, BA techniques don’t change based on the project methodology either. You may try new techniques in new ways at different times, but, all in all, good techniques can be used in Agile and waterfall environments.
Traditional methodologies require techniques for requirements elicitation, analysis, prioritization, change management, issue resolution and more. Projects using an agile approach require techniques for the same functions. It’s really just the external stuff that changes—the timing, structure, format and process. Certain Agile methodologies use a specific set of techniques (SCRUM User Stories), but they are not all encompassing for requirements activities, they are a minimum to start with, a placeholder for conversation and more collaboration to follow.
We need to elicit requirements from stakeholders for every project. BAs on traditional projects might elicit all requirements at the beginning of the project. BAs on Agile projects might elicit requirements in one small chunk at a time, but the techniques are similar.
4. Stop Polarizing Agile and Waterfall
Agile and waterfall are not opposites—they are not mutually exclusive. Agile is not meant to be a polarizing force that pushes teams away from Waterfall.
Agile is a mindset born from the Agile Manifesto written by 17 men, probably on a napkin, at a Utah resort in 2001. Have you read it? It’s remarkably simple and packed with common sense:
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over Processes and tools
Working software over Comprehensive documentation
Customer collaboration over Contract negotiation
Responding to change over Following a plan
That is, while there is value in the items on the right, we value the items on the left more.”
The intention of the Manifesto was not to replace a particular methodology—instead, the authors wanted to bring visibility to what works to build better software by:
- Balancing the scales and slide away from the slow, document-heavy, procedural methods of the time
- Bringing flexibility and fluidity back into the world of software development
- Creating an efficient and effective process that would bring meaning and purpose into every task
Take note: The manifesto offers values, not demands, process, or requirements. They are meant to guide or refine, not constrain. These values can be applied to all projects.
I don’t think the authors of the Agile Manifesto meant to create such polarization in the industry or organizations and their practices.
5. Don’t freak out your stakeholders.
So given the simple foundation of the Agile approach, the transition to Agile does not need to be an historic event full of pomp and circumstance. Yes, Agile looks and feels a bit different than waterfall, but that doesn’t mean you need warn your stakeholders about major changes. Many of the agile principles can be implemented well on Waterfall projects without alarm or need for major change management. It takes relationship skills, facilitation skills, and confidence.
It is important to help all stakeholders understand the agile mindset, but we don't need to overemphasize differences. Think about it this way: Why and how will it look and feel different? Is Agile driving the differences or is it just a better way of working?
It really doesn’t matter what it’s called, you just need to help stakeholders understand the value and move them forward gently. Any methodology done well will provide stakeholder value. Keep them focused on the output and how the process gets them to the value. As long as you are efficient, organized, effective, you will keep stakeholders engaged.
It may be the comfort of governance and process they are missing the most when transitioning to Agile. Help them through this, but don’t let it get in the way of being more collaborative and value minded working through requirements.
So, now that I’ve had my say, do you agree?
Don't forget to leave your comments below.