Like A Girl

Pushing the conversation on gender equality.

Code Like A Girl

A rollercoaster ride in product management

Buckle up and enjoy the ride!

Do you hear the thrilling sound of the gears as they lock in the tracks? You gaze ahead and see the uphill metal lines that pave the way. Those are the tracks for the early majority of adoption in agile practices. You smile, because companies are finally seeing the value in planning short-term, iterating and prioritizing.

Wait for it… and jump!

However, something dark catches your eye. You see a great gap in adoption of lean and product mindsets.The widely mainstream project mindset is still locked firmly in place, and you wonder: shouldn’t these practices — agile development and lean product development — be adopted as a unified, agile thinking set? Why is lean product being left behind?

Project mindset and long-term engagements

A very modest, unforseen-proof engagement plan

A project mindset is based on creating a plan, breaking it in phases, establishing deliverables and then following it through. The concept of delivery is key to this structure, and both individuals and teams are focused on completing tasks and reaching the spot the plan mapping set as the finishing line. The data for analyzing sucess or failure is the delta between plan and execution, regarding time, budget and scope.

The first time I saw a waterfall, Gantt plan, I am not very proud to say I laughed. In a meeting. With directors. I tried being discreet, and being a low-level employee no-one was paying attention to, I believe I was fairly successful, as I watched a reputed consultant company showcase an 8-month plan to replace all 12 systems used in customer relationship in a major multinational for a single CRM, all processes and products included. I knew those systems intimately, and they were completely different among themselves, with processes that fit against each other like a jigsaw puzzle fits a banana split ridden by an alligator in a ballerina outfit. To make things even more picturesque, the majority of the team — including the business analysts — didn’t speak the language, let alone understand the regional and cultural aspects that caused some of the processes particularities. Some of them didn’t speak English either.

Yet, somehow, this consulting company knew they would be able to deliver the CRM, fully operational, in production, in the end of 8 months.

Last I heard, the project was completing its seventh anniversary, and the old systems are still up and running.

Scrum is not a complete answer

Y U NO COMPLETE ANSWER

I am sure if we were to use lean and agile practices in that CRM project, the results would have been very different. However, although the rollercoaster excitement of implementing agile and seeing things work is practically irresistible, putting the backlog together and ordering by importance and value is only part of the way. It would be awesome to do scrum, but we would still be far from a product mindset.

A product mindset is NOT based in a fixed scope, nor a fixed plan. Most times, there is a limited budget to test as many hypothesis as possible to determine what product should be built. A product mindset is based on getting to know your customer/client/user and their needs, and building your product to tap those needs and fill the gaps. Even if we had applied scrum to the CRM project, we would be dealing with a list of preset features based on what the systems did, and not based on what our users needed. That is the gap agilists must overcome.

A new execution with an old strategy

This is product management in 5 sprints…
… and this is “Agile” project management in 4 sprints

The reason this gap is forming is the adoption of Agile practices… but only when it comes to execution. The big boys with the big bucks are more than happy to support change in the way the operational level works, because they know it will lead to more productivity in reaching the strategy they set for the organization. But how was that strategy defined again? Oh, right! All those directors figured out a big annual plan for the whole company, that’s supposed to be executed by operations and overseen by management. What could possibly be the matter with that? It’s not like the market is something inconstant and innovation changes the rules, right? We can just design the annual plan, and roll it out, quarter by quarter, like a beautiful… waterfall.

Dilbert and company wisdom

The idea of combining an Agile execution and waterfall, static planning towards the organization strategy is in the least very destructive. Let’s see some examples of what happens as a result:

Explaining what went different from the plan and why is more important than responding to market’s needs. Change is bad, even when it’s good.

Every little decision (from error messages to backgroud colors) has to get the go-sign from everybody.

Your stakeholder sees no value in creating user stories or empathizing with your client.

Decisions are based on opinion, not data.

Your product makes the stakeholders happy. But the client doesn’t use it.

Sounds familiar, huh?

A leap of faith

In order to take the leap of faith that separates the project mindset from the product mindset, we must discard our current beliefs and look at strategy definition with new eyes. We must understand our stakeholders’ motivations and try to influence them in communicating their goals instead of a ready-made solution, so we can involve the whole organization into reaching that goal.

I am not naïve to think we’ll snap our fingers and jump. This is a big cultural change, that doesn’t happen overnight. But neither is the adoption of any agile practice. We test, fail, perfect, and the same must happen to build the needed trust to make that leap organization-wide.

So question about the needs of stakeholders. Empathize. Bring them to an understanding of strategy as a consequence of setting a goal, not a cause. Create your own goals, for you and your team. Measure results and show this works, moving bottom-up.