Falling from Mount Olympus: The difficult lessons I’ve learned on the way to agility

At the Agile Brazil event in 2017, I presented a session called Falling from Mount Olympus: The difficult lessons I learned as I tried to take the Agile Journey. This article summarizes a few of the challenges I faced in making my team agile. The idea was to expose the mistakes I made to help people doing Agile Transformation to avoid the same traps.

Mount Olympus

Before getting into the lessons as such, I’d like to explain the Fall from Mount Olympus metaphor.

According to some texts about Greek Mythology, after Zeus freed his siblings from Cronos, they began inhabiting the earth (Gaia). However, because they were extremely powerful, capable of influencing directly or indirectly all aspects of human life, they asked Hephaestus (god of artisans) to build a palace for the gods on the highest mountain in Greece. From there, the twelve Olympian gods sat in judgment on the earth.

Over time, these gods became more and more arrogant and important, and less and less accessible to humans. But humans were the reason for their existence, so as time went by and with the gods’ indifference, mankind forgot about the Olympians and adopted other divinities.

Mount Olympus is empty, because having no reason to exist, the ancient gods “fell down”.

Experiences

During my professional life, I’ve used various work organization formats in order to develop software. When I began, we used the traditional Waterfall Mode described in the 1970 article by Royce. Analysts, coders, and testers worked in separate rooms and everything as very slow and bureaucratic.

On two occasions, I took part in the RUP (Rational Unified Process) implantation teams. In one of them, we also went on to get CMMI (Capability Maturity Model Integration) certification, which was later changed to MPS-BR (Brazilian Software Process Improvement) because of the costs of certification.

Much later, I changed jobs and joined a small development team, with 12 developers. We had no specific model at the time. Each had their own way of working. We used to joke that it was the Nike: Just do it! model.

It didn’t work. We used to start a lot of things and delivered little or no value to the organization. We decided to change to a PMBOK approach, with all its suggested and adapted documents and processes. Unfortunately, we didn’t have much success with that enterprise either, because we produced a lot of documents and agreements, but not much software. The projects had a long duration, the list of demands ran to over 20 products, and there were constant interruptions.

Ascent

In 2009, we started to adopt Scrum. But since only two of us had been trained, our Scrum was rather “Scrumbled”. At the end of that year, all the team’s developers and managers did a course with Rodrigo de Toledo (old guard, before Knowledge21 existed :-).

Over time, things started working better. We started delivering products every two weeks and our clients were very pleased with the results. They liked it so much that they started coming to us not only to develop new ideas but also for us to introduce and help adopt Scrum as their working method. We were called upon for all sorts of projects, whether they involved software or not.

We felt so strong that we decided to present our cases at events, lectures and articles in Brazil and even in the USA. We won a few awards doing that. We’d arrived at the summit of Mount Olympus.

Falling

We felt invincible and because of that we stopped paying attention to a few important signs:

• Our clients started “importing” and buying solutions which were related to the organization’s main business, while we developed support products.
• The implantation of Agile Methods we promoted in other units didn’t take and would die soon after our departure.
• Meetings characterized by “That’s not what I asked for” and “from now on, minutes need to be signed” began to be the rule.

 

After a while, we saw that we weren’t as great as we thought. People were suspicious of us, an “us against them” mood reigned, and we started to be the object of our clients’ jokes. We’d fallen from Mount Olympus, down into Tartarus, in the Kingdom of Hades. Also known as the Underworld.

Root cause

It was time to take a deep breath and look around for someone to blame. Don’t do that! Although it’s easy enough, it’s not a good idea and won’t help at all. It’s time to find the root cause of the problems.

We used the Root Cause exercise (to understand how it works, see the article available at this link). We concluded that the origins of our problems were as follows:

Cold Communication

When we work with Agile Development, we deliver product (working software) all the time. We had a product for which we had dozens of users in the first week of delivery. These were our main clients because they supplied requirements and feedback, which was essential to the product’s evolution.

However, the following week we already had hundreds of users. We tried listening to everyone and it became impossible to hear and understand the difficulties of our core clients (from the first week). The solution we found was to communicate via E-mail, and Bug Tracker.

Bad choice. Written communication doesn’t transmit some highly relevant information, such as facial expression, mood, and irony. It doesn’t allow for the rapid exchange of information and makes debate very difficult. Information becomes garbled. Some of our clients were very concise and we didn’t understand what they wanted. Others went into fine detail. We felt like answering e-mails with “TL” or “DR” (Too Long; Didn’t read).

“Cover My Ass” Documentation

Remember your childhood? Remember when you gave a wrong answer at school and got no marks from the teacher, without much explanation, and a rough time back home? In college or graduate did anything change? Not usually. We learned that mistakes are bad things. Therefore we should try to predict and avoid all.

If this doesn’t work in simple environments, like an individual review, just imagine the complexity of projects involving numerous groups of people. The best solution is: blame someone for the mistake, as long as it’s not one of us (of course not).

We knew the excessive and unnecessary documentation was making everyone unproductive, but we still decided to have minutes for every meeting. The paranoia was so great that we used to joke that minutes were necessary even if you just ran into a client in a café or elevator. The question remained: Why did we go back to excessive documentation?

A metaphor by Marcos Garrido might help here. He says that Agile is like a block of ice in your hand. If you don’t cool it from time to time, it’ll return to its liquid state (the way you were taught to think all your life).

Excessive Positive Feedback

Getting positive feedback is good. However, it doesn’t generate reflection on how to improve your work (see more about this in the article Good Feedback). One time, when I was playing the role of Product Owner, I asked one of our internal clients about any issues he saw in our product. This client was special since he’d been the one supplying most of the information and feedback during the building phase. His answer was: “None! This is one of the best systems I’ve seen. We’re even going to export it…”

I asked if we could put a quiz on the external site with a single question: What problems did you have in doing XYZ (the system’s main feature)?

Based on the response, we had to redo the system’s entire interface, change flows, and business rules, remove pet features, change text, a whole series of changes. Feedback should be capable of leading you to a situation which is an improvement on the current one.

First World War Team

Peter Senge, in the book The Fifth Discipline, says that in the new economy we should invest in and value people for what they have from the neck up, not neck down.

At some point, our development team had become a task-based team (implementing what the clients want, without questioning the purpose). We’d deliver everything they asked for, but the request wasn’t always right. As one team member said during the Root Cause exercise: “Our product was a fiasco. We sunk to the bottom of the ocean, although in great style” (a reference to Titanic).

A First World War team has no strategy, it just executes. It gets a mission and runs off screaming into battle with the goal of holding the next trench. With luck, someone will survive the hail of bullets.

Divided Product Owner

The job of the Product Owner is vast. He talks to stakeholders, gets feedback, follows metrics, suggests new features, reviews the product’s context, corrects the course for solutions, etc.

We tried to have a Product Owner (P.O.) for two or three products, with two results. In the first, the P.O. adopted one of the products and the other died of starvation (there were no user stories for the development team to implement). In the second, the P.O. tried working on all the products and they all died of starvation.

We also tried giving people multiple roles: Product Owner and Manager; Product Owner and Developer. In both cases, people chose their favorite roles (or the ones with greater external pressure) and the product got relegated to second place.

Solutions

In order to find a solution, we went back to basics. The Agile Manifesto.

Cold Communication
“The most efficient and effective method for transmitting information to and among a development team is through face-to-face conversations.”

“Business people and developers should work together daily throughout the project.”

For the main clients, the phone became the minimum means of communication. It is always better to talk to them face-to-face.

“Cover My Ass” Documentation
“More collaboration with the client than negotiating contracts”

Ask yourself whether you really have the firepower to use the dreaded meeting minutes or project scope documentation, or whatever crutch was signed which you’re using to support yourself. If it’s against a director or someone near him or her (professionally or personally), your power might be non-existent, or even in the negative.

The solution was to remove all unnecessary documentation, keeping only that which helped a certain matter or was obligatory according to company rules.

Excessive Positive Feedback
“Our greatest priority is client satisfaction through continuous delivery and the advancement of software with increased value.”

Seeking new stakeholders and changing the way we asked questions. Find out what value needs to be increased and for whom.

First World War Team
“Business people and developers should work together daily, throughout the project.”

“Build projects around motivated individuals. Give them the support and environment they need and trust them to do the work”.

Make the purpose of the products very clear and include the team in decision-making.

Divided PO
“Agile processes promote sustainable development. Sponsors, developers and users should be capable of maintaining a constant rhythm, indefinitely.”

The PO has a lot of work to do: Talk to clients, take part in meetings, review business metrics, do benchmarking, talk to the development team, align expectations among stakeholders, slice, prioritize and discard items in the backlog. It’s a full plate for one person. That’s why it’s important the PO only plays the role of PO and reduces the number of products he takes care of. Down to one single product, if possible.

Conclusion

With these actions, we managed to get out of the Kingdom of Hades and return to the earth’s surface. It wasn’t easy, but we learned from our mistakes and took a few more steps to become a truly agile team.

Actions are taken by the development team to return to the agile development of products.

Enjoy this article? Learn more about the themes discussed here in our Product Owner and Scrum Master training.

And there are other articles related to this topic in our blog:
Root Cause retrospectives
Good Feedback