10/02/2014
By now Agile has lost its hype. Books have been sold, blogs have been written, "experts" have earned lots and lots of money. So by now, there are two kinds of companies: the ones that use some king of agile methodology, and those that are too big to change.
While having some drinks with a friend, a project manager at one of those telcos that are too big to change, I was really interested in learning their story.
By 2014 upper management seemed to be convinced that the company needed to be more agile. Whatever that means. I’m not sure whether I should congratulate the upper management for realizing their development process was not flexible enough, or if they should be ashamed for failing to change so far.
I’m sure they have lots and lots of smart people working for them. So I wonder why they weren’t able to change their culture and processes so far. Maybe internal politics got in the way.
The company hired some experts in agile methodologies, to go around and deliver training and seminars. I call this part evangelization. At the beginning everyone is excited, but it doesn't really change anything.
Since the training covers the theory and benefits of agile methodologies, everyone leaves the room thinking:
"This sure looks great. It just won't work for us."
After some time, people get back to their comfort zone and continue working the same way. Processes don't get changed, and the initiative is deemed a failure.
So just like everyone else, by the end of these training sessions my friend was not convinced that agile methodologies would work for his company.
I was amazed since in his senior year, he had taken a course on project management. So he already knew some of the benefits, long before joining this company.
What was interesting to see, was that he was able to enumerate lots of benefits. He felt that agile methodologies could have a positive impact on the way software gets delivered. But he felt that this would just not work for his company. It was as if his company had problems that no other software company ever had.
And his reasoning was clear. He could not understand how, as a project manager, he could plan the testing phase of whatever product he was developing.
"If we use agile methodologies, then customers could change their minds about the features being developed at any time. How can you estimate and outsource the tests for something that is constantly changing?"
At first his argument was compelling, but then I realized he was still fixed in a waterfall mindset.
Let's make one thing clear. Customers are just one of many stakeholders that should be involved in the development process. You should strive not to only listen to customers, those who pay for the project. Most of the times they’ll not be using the product themselves.
Even if you are able to please them it will not matter. If you don't address the major pain points of end-users, your system will not get traction, and will left unused.
So instead of only focusing on the customers, you should get consensus from: - End-users; - Project sponsors; - Marketing; - Whomever might directly or indirectly be affected by the product or process your are changing.
If you can gather feedback from all these stakeholders you'll find their real needs and concerns. Sometimes you will need to gather them in the same room and mediate their discussions.
Another misconception is that if you are using an agile methodology, stakeholders have the right to be bipolar. One day they want a feature, the next it should be killed.
What agile methodologies try to tackle is the fact that software development is just like writing, composing, or designing. You need to translate intangible ideas into tangible products. Books, music, bridges, or in our case, running programs.
The problems start to happen when you are commissioned to translate someone else ideas into tangible products.
Since most of the times we rely on verbal communication to exchange ideas, and verbal communication is subject to interpretation, ideas get lost in translation.
It's the same problem you face when you are commissioned to write a book for someone else. You first need to understand what your customer wants to give to the audience, and translate that into tangible things - words.
And while doing this, you are doing it with your own bias. This implies that you’ll not be able to please your customer with your first attempt.
And so agile methodologies embrace that this happens instead of denying it. They acknowledge that your first implementation will suck. And in order to get closer to your customer's idea, you really need to ship that first product, get feedback, and iterate on it.
That why the word iterative is so important. Because you're not going to nail it at the first try. So you just need to make small changes to converge into the customer vision of the product.
Of course iterating has a cost. If you are redesigning something, you are not building that second feature that is also critical to the project success.
Agile methodologies also acknowledge this. They have processes to ensure you help your customer understand the pros and cons of improving, or adding a new feature.
My friend understood the two major misconceptions I've explained above. What really troubled him as a project manager, was how was he supposed to plan a project, and how to outsource the testing stage.
After all, he needed to know exactly how many men/days it would take to test a feature. Otherwise he would not be able to outsource it. And it was not just him. All other project managers were confronted with this dilemma.
And that’s why his company was part of the too big to change category. Lots of smart people, and none of them could solve this dilemma.
Instead of diving into the solution, let me re-frame the problem to something more tangible and not software related. Imagine McDonald’s engineers are given one task: create the perfect hamburger for a target audience.
They start the project by gathering the relevant stakeholders. But since McDonald’s engineers are payed at the price of unicorn ivory, the project manager decides that the quality assurance should be outsourced. This will save some money and ensure the precious engineering team is focused on crunching out hamburgers.
So the dilemma for the project manager is to estimate how many men/hours will it take to test if the hamburgers are built according to their specification.
By now you should be asking:
“But what sense does this make? How will the McDonald’s engineers know if they are closer to the stakeholders vision of the perfect hamburger?”
And the answer is simple. You can't separate product development from product testing. If you make an hamburger, you need to taste it.
You’ll also need to make sure the hamburger engineers are present in the room when the stakeholders tell why the hamburger is not how they like it, or how they imagine it.
This will be the only way for them to understand how they can iterate on the hamburger and build the perfect hamburger. Or at least the perfect hamburger for those stakeholders. And yes, they’ll have to negotiate if during the next iteration the team should focus on improving the sauce, or developing the bun.
All stakeholders will give you lots of feedback, but you'll need to make them understand the pros and cons of each decision. You need to help them help you decide where to invest your time
Just because you hire experts on agile, nothing will change if you don’t have the right incentive and flexibility to change. This change was doomed from the start, since no one really saw that to be agile, providing training was the easiest part of this undertaking. The difficult part is changing the culture, the processes and being open to learn with the mistakes.
The sad part is that by the end of our drinks, my friend had understood this, but felt he couldn't change anything. And that’s how you can spend thousands to train your teams and not change anything at all.