“We are not agile enough”, she told me. “This is not what I expected from this company”.
If you work at a large company, or in a relatively traditional industry, you probably know the feeling:
You are a big believer in Agile and Lean. You fully understand the importance of it, not as a strict process, but as a state of mind. You appreciate the insight you gain from moving fast and testing your product with real customers. You know that planning every little detail in advance will never hold, and you are eager to deliver value and make your impact.
But then, you get this email or conversation from your manager or primary stakeholder:
“I need to see the plan of the entire project first”
“Don’t give me parts of the solution, I need it all or it’s meaningless for me”
“We need to build the right infrastructure”
and even, from the more honest ones:
“I don’t believe in all this Agile thing”
Someone is stopping you.
It’s like driving a fancy sports car straight into a giant traffic jam. You know you are capable of doing great things, but you simply can’t because of things beyond your control.
It is so frustrating!
Of course, you can always decide that it’s not for you and move to another company or product. Note that it will not always help though. I’ve seen even the smallest startups that are not as lean and agile in their approach as you would think.
Some product domains are naturally less agile: enterprise software (especially on-premise but not only there), anything involving hardware, heavily regulated domains, and more traditional ones like finance, insurance, transportation, healthcare, national security, public sector, and the list goes on.
So what can you still do? How can you deliver and make an impact without going elsewhere, but also without giving up on what you believe in?
You need to accept the fact that Agile – or at least the flavor that is implemented in most companies, which is far from the essence of the agile methodology – has its downsides. These downsides are legitimate concerns for the people you work with, and to win you must address them as if they were yours.
Here is how to do it.
What Management and Stakeholders Care About
To change things with management and stakeholders, you need to help them relax. Agile can be scary for someone who is not used to it, and even more so to someone who has witnessed a poor implementation of the agile process in the past. I can tell you firsthand that it feels like an unorganized mess, an excuse to avoid proper thinking or accountability, and leaves you with a complete loss of control. This is how I felt when I first started working in Agile, and I wasn’t even that “waterfall-y” before.
Your stakeholders and managers have their concerns. They see things differently.
As a product leader, you must have empathy for your customers. Develop the same empathy here for your stakeholders. These are the three steps that I suggest:
Step 1: Listen
Listen to them just as you would listen to your customers. Ask them what is their preferred mode of work and why.
It doesn’t necessarily mean you have to do exactly what they are asking (much like the situation with your customers), but it gives you an insight into their way of thinking (and usually extra points for asking). It allows you to start an intelligent discussion about it, and to create a real partnership which is the only way to succeed.
You want them to know that you understand them. Don’t listen just to check this box, assume there is something in what they say or feel, and look for it. Don’t continue until you fully understand them and both of you know it.
Step 2: Do Some Homework
Now, when you fully understand their concerns, and they know it, you can share your side of things if they are open to it. Explain why you think an agile methodology is important. Your point of view should be why it is important for them and the company, not for you.
But this is not the important part of this step. Some of them might not be open to the discussion, at least until you address their concerns and come up with a better alternative (step 3 below).
Now it’s your time to think and do some homework.
If their concerns are legitimate, how will you address them? Why is it important to work in Agile still? Do you have good answers?
Please assume that “everyone works this way” simply isn’t good enough, so roll up your sleeves and get to work. Conduct some research. Go back to the roots of the agile methodology and understand why they thought it was better than the (then) traditional methodologies. Think about it from your stakeholders’ point of view.
Do not assume they should already know it. Take the time and effort to build a case and truly explain your point. The bottom line shouldn’t be “why agile is awesome” but rather “why it’s worth investing in building a proper agile culture despite the legitimate concerns we both now have”.
Remember that even with people who believe in agile, crafting a process that would work for both of you takes time. For example, when I was the VP of Product at Twiggle and a new VP of Engineering started, we sat together for a few hours every day, for about 3 weeks, until we agreed on a unique implementation of Agile that served all the needs of both of us. And we weren’t that apart with our approaches to begin with.
Creating good collaboration takes time, give it the proper priority.
Step 3: Suggest an Alternative That Will Work for Everyone
Now, when you understand each other, you can suggest something that would work for both sides. You must address their concerns or they will not be able to accept your suggestion. You want to give them something they can say yes to.
You need to address their concerns even if they are not natural to you. Much like the fact that you are not your customers, and you can still address their needs – you need to address your stakeholders’ concerns even if you don’t share them. Make them yours.
Remember that the basis for agile thinking is that there are no strict rules about how things should be done. Find the flavor that works best for you and your organization.
A Note About Planning
A typical concern around Agile for people who are not used to it is planning.
Here is the thing: agile doesn’t mean a lack of planning. It is an important topic that deserves a post of its own, but for now, I’ll say this:
Long-term planning is very important even for the most agile teams. It stems from the famous quote of Alice and the cat:
“Alice: Which way should I go?
Cat: That depends on where you are going.
Alice: I don’t know.
Cat: Then it doesn’t matter which way you go.”
As product leaders, you want to know where you are going, even if you are not sure about the road there yet. So do your stakeholders.
Give them the grand vision so they can make sure they are on board with it.
Give them a plan so that they can understand what’s coming.
Set expectations that the plan might change and even a proper guideline or process regarding how they can know if things on the plan are going to happen on time.
Explain the process – they want to know that you are managing it, that you thought about the bigger picture, and that what you do is not random.
Eventually, it is all about trust. Take the time and effort needed to build this trust. It is part of your job, don’t put it on them. Help them trust you.
You will succeed more in some cases than in others. It does not always depend on you. It is impacted also by the product domain, the specific people’s background, and their past experience with Agile (the worse it was the harder your job is in convincing them to give it another chance).
