The Agile Business Analyst Mindset vs. a Waterfall Mindset
How can a Business Analyst be successful in an Agile environment? We can use a lot of the same tools, techniques, and approaches that we would use in a traditional environment. By adopting a different mindset, we apply those tools in a different way.
Using lean and Agile approaches, we’re able to iterate by delivering smaller chunks and get feedback along the way so that we can adapt to changing customer needs.
Agile isn’t quite a methodology, although when the signatories of the Agile Manifesto got together to create it, they called that meeting the Lightweight Methodology Conference. At its root, Agile is a way if working. It’s a set of four values that guide why we act the way we do and 12 principles to guide what we should be doing. Those principles and values are supported by a series of practices and frameworks such as Scrum and Kanban to help us understand how will achieve some of those outcomes.
Underlying it all is the mindset. Without the right mindset, we follow the rules but don’t understand why you’re doing it. It’s like learning to dance versus learning martial arts. When you learn dance, you learn the movements but you don’t understand why. In martial arts, every movement has reason. Every movement is to achieve a singular outcome.
What is the Agile Business Analyst mindset? First, let’s take a look at the mindset of a traditional waterfall Business Analyst. If we look inside the mind of a traditional Business Analyst, we see that they have a drive towards documentation. They want to make sure everything is very clearly documented to create a common understanding with our customers. We need those documents to help our customers understand what will build for them and ensure that we’ve accurately captured their needs.
Traditional BAs also need those documents to share with the software engineers so that they can build an appropriate solution. Good documentation may be made up of models, use cases, and various other forms to convey a shared understanding.
Traditional Business Analysts also need to manage change. They want to be able to control change so that the change still remains within the scope of the project and doesn’t get out of control. As a result, we create a lot of processes around managing that change such as change review boards and change requests.
Customer needs are always top of mind for traditional Business Analysts. We need to sort out the needs from the wants and make sure that we’re delivering a solution that meets those needs.
Because we focus on the needs and manage change, we create a full design up front. We don’t move forward until we have all the information to go to the next stage. We need all the details so that we’re able to see the big picture and to move forward.
As a traditional Business Analyst, I do my job and I do well. My job is to discover the user requirements, document them, and ensure an appropriate solution is delivered.
In order to deliver that solution, I need to analyze everything. We analyze the current conditions, organizational capabilities, and information that we’ve gleaned from user interviews and other organizational assets. From that analysis, I’m able to synthesize a set of requirements which I deliver to our software engineers to create a solution.
That mindset and approach works in a traditional waterfall environment. People can be very successful doing that type of work. The problem is something that I call the Success Paradox.
Let’s make a shift and look at the mindset of an Agile Business Analyst.
