Agile is a Mindset, not a Process

Confident female designer sitting at her desk for a brainstorming in red creative office space.jpeg

It’s easy for analytical people to think of various organizational dynamics in terms of process. When we at NorwalkAberdeen start to work with a new enterprise client, for example, we start building a business-architectural view of the client focusing largely on their processes.

Think about some processes that are involved in running a projectized organization: reporting processes, project management processes, hiring processes, communications processes, development processes… and the list goes on.

But here is the thing: although waterfall is a set of processes, Agile is not. So what is Agile then?

I usually define it as “an approach to developing products involving short iterations and intense collaboration with customers”. Most of the words change from conversation to conversation, except for one – approach.

Indeed, Agile is an approach, a mindset, a set of values. And from that mindset follow all the innovations of Agile.

Let’s imagine two Business Analysts.

The first BA is Alice. She understands what Agile is and seeks to embody its philosophy. She reminds herself of the values and principles daily and even has them posted on her cubicle wall. She loves to make her clients happy. Most of her day is spent helping customers to understand their real needs and to make sure that the user stories they write will help them accomplish their goals. And she also strives to make sure that her development team is never held up by uncertainties, and that her team can have quick access to the customers whenever needed.

The second BA is Bob. Bob is a great Business Analyst and has experience working mostly in a waterfall environment. He is eager to learn Agile and make a solid contribution to his project. Having worked in a waterfall environment, Bob focuses on learning the process of Scrum, the methodology used by his company, and he strives to get everyone to follow Scrum to the letter. He spends most of his day meeting with the PO and writing user stories and acceptance criteria. And he answers developers’ questions whenever they come up.

My question to you is which BA will thrive in an Agile environment?

I vote Alice. Here’s why.

Alice understands the values and principles of Agile. Processes come and go, but the foundation remains. When her company decides to change processes, or even to deviate from typical Scrum practice, she will do fine. Bob, on the other hand, will feel somewhat at a loss. He has focused so much on the process that he will be challenged to move to the new one.

Alice also appreciates that the interactions we have with each other are more important than the documentation we write. This frees her up to make sure that the team is well-served. Bob, on the other hand, will try to write all the user stories and acceptance criteria himself and will become a bottleneck.

My tip to you is to imitate Alice. Integrate the agile values and principles into your practice daily. By doing this, you will be a more productive, flexible, and agile Business Analyst.

I'll encourage you to check out the free preview lectures for our Agile Business Analysis course, via the red button below. There is an in-depth discussion of Agile values there.