“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. You appreciate the insight you gain from moving fast and testing your product with real customers. You know that planning of 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”
“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!
Before You Decide to Move On
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 who 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 work simultaneously on two fronts: the first one is outwards (stakeholders and management), and the second one is inwards (with your development team).
Working with Management and Stakeholders
To change things in the outward-facing front, you need to help them relax. Agile can be scary for someone who is not used to it. It feels like an unorganized mess and a complete loss of control. I know 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 product leaders, you must have empathy for your customers. Develop the same empathy here for your stakeholders.
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 on it.
Step 2: share your point of view
Then, explain your point of view and why you think an agile methodology is important. Think about why it is important for them and for the company, not for you.
If you don’t have good answers for the above (assume “everyone works this way” doesn’t do the trick), go do your homework. 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 truly explain. Even with people who believe in agile, crafting a process that would work for both of you takes time. At Twiggle, when a new VP R&D started, we sat together for a few hours every day, for about 3 weeks, until we got to a process which served all the needs for both of us. And we weren’t that apart with our approaches from the get-go.
Creating good collaboration takes time, give it the proper priority.
Step 3: suggest an alternative which will work for everyone
Now, when you understand each other, you can suggest something that would work for both sides. You need to address their concerns, even if they are not natural to you. Much like 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.
Remember that the basis for agile thinking is that there are no strict rules about how things should be done. Find the flavor which 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 which 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 a plan.
Set expectations that the plan might change.
Explain the process — they want to know that you are managing it, that you thought about the bigger picture, 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, their past experience with agile (the worse it was the harder your job is in convincing them to give it another chance).
So let’s get to the part which is 100% up to you: the inward front and how you manage your process with the development team.
Working with the Development Team
Assuming with the development team you have less resistance and everyone wants to be agile, you need to be careful to not throw away the baby with the bathwater.
In other words, even if your stakeholders are not convinced and you cannot work in full agility outwards, don’t give up on your agility inwards.
Agile brings a lot of value even as an internal, execution-only methodology.
Benefit #1: working product
Even if you can’t release a new version to your users every other week and get their feedback (directly or through analytics), there is still a lot of value for you in having a new version ready every other week.
It allows you to see things for yourself, which is always better than seeing them in wireframes and on paper. Note that the agile manifesto values “ working software over comprehensive documentation”, not “released software”.
Before you go to users to get feedback, look at the product yourself and see what works and what doesn’t. Make sure the product actually delivers the value you planned for it at the beginning of the iteration.
Of course, user feedback is important, but don’t worry if you can’t get it for every little piece you deliver. You are a smart person. Don’t be afraid to think for yourself.
Benefit #2: flexible prioritization
Agile as a methodology also gives you an opportunity to assess priorities regularly and update them as needed. This can be done at the micro-level (for example reprioritizing features within a release) or at the macro-level (putting things aside in favor of others which needed immediate attention).
Make the discussion about the priorities, not about the fact that they change. A proper agile process will support you in making sure the change is as painless as possible for everyone involved.
Sometimes, you will understand your goal was incorrect, or maybe a closer goal seems good enough now that you are almost there.
Benefit #3: concrete alternatives instead of overarching principles
This is where everything connects together — the inward front and the outward one.
Because here is the thing: it is much easier to have a concrete discussion about whether a specific piece of working software should be released or not when this software already exists. The discussion about the agile principles you had at the beginning doesn’t matter as much now, even if you were unable to convince the other side that agile is the best thing for them.
If your product delivers value now, most likely people will want you to release it. But even if not — don’t make it about the principle. Discuss the actual value that it brings and ask what is the benefit in releasing it as part of a larger, later release.
You see, to be truly agile you too need to be willing to start walking in a path where things are not defined all the way. One of those things can be whether you are working in agile or not.