In this Lightning Cast, we explore the mindset shift needed to be successful as a Business Analyst in an Agile environment.
A Lightning Cast is a shorter form episode modeled after lightning talks. You’ll get valuable content in 8 minutes or less.
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.
What is Agile?
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.
The Traditional BA Mindset
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.
Is being successful at something holding you back from being really exceptional something else?
The Agile BA Mindset
Let’s make a shift and look at the mindset of an Agile Business Analyst.
Instead of focusing on documentation, Agile Business Analysis realize that conversations matter. Written documentation is one of the worst forms for conveying information. It opens to door for different interpretations and misunderstandings. Realizing that conversations are more important than documentation is a key mindset and it’s one of the reasons why we apply user stories.
User stories and very small and don’t contain all the information. The details are in the conversation. Remember that user stories are just a placeholder . . . a reminder to have a conversation in the future or a reminder of a conversation that has already occurred.
In a traditional environment, you want to manage change. In an Agile environment, you expect change. You know that changes can happen and in Agile we harness change for the customers benefit. We want to be able to adapt based on customer feedback and deliver the right solutions that are meaningful to the customers, not create shelfware.
Because we expect change to happen, we develop solutions in small increments and iterate as we go based on that feedback.
At top of mind is always customer value, not just the needs and wants. We understand the true value that customers get out of the solution. This implies that we understand what the customer wants and needs, but it goes beyond that. It involves exploring various options, discovering needs that customers weren’t able to articulate, and being able to prioritize work based on that value.
Because of that customer focus and expectation of change, we do just enough just in time. Instead of getting a big design up front before we move along, we work in small increments doing just enough just in time.
Getting into the details too soon is actually waste because we seek feedback and adapt along the way. If we work too far ahead, that information may change as we go and we will learn new things. As a result, some of the detailed analysis and planning we did is wasted effort.
Of course, we need to understand the big picture at a high level. But for the details, do just enough just in time.
In a traditional environment, I do my job and I do it well. In an Agile environment, we adopt a team focus. That means I need to stretch my skills, step outside my role, and see what kind of support the team needs. That may be helping a product owner with some customer discovery or helping the testers. I likely won’t be as good as a tester in testing the software, but I can provide support where the team needs.
We develop fungibility. In the context of an Agile team, fungibility means that I develop my skills so that I can help other team members. On an Agile team, we succeed or we fail as a team. We all need to step outside our role and help each other.
Finally while analysis is needed, we have a bias towards action. We do just enough analysis just in time and then take action. Similar to the Plan Do Check Act loop from W Edwards Deming, we do a little bit of planning and then build something. You then check the impact of what you built through customer feedback and adapt yourapproach based on that feedback.
We need to take action! Small, incremental action and then get feedback and adapt along the way.
Make the Shift
The real challenge is making that mindset shift. One way to do that is to consider the six concepts of an Agile BA mindset:
- understanding that conversations matter
- expect change
- focus on customer value
- do just enough just in time
- have a team focus
- have a bias towards action
Think about what the six components mean to you in your role and put them into practice.
Listen to this lightning cast to hear more about the mindset shift for success in an Agile environment.
Thank you for listening to the program
To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.
Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.