Ángel Medinilla: A Business Is Agile When It Adapts To Customer Needs Fast. Period.

Ángel’s company Proyectalis is now one of the leading Agile consulting and coaching company in Spain, and one of the most well-known in Europe, offering Agile training, consulting and implementation services. But in 2007, when he started the company, the trends were different, as well as his approach to the companies:

I try to walk my own talk, and one of the things I stress when it comes to continuous improvement is “improvement implies change”. You cannot be doing things exactly as you did five or eight years ago and claim that you have improved.

For instance, my first consulting gigs were more focused on “adoption”, whereas now I focus on “transformation”.  I’ve come to realize that just layering Scrum and some Agile practices on top of the existing culture does not work well in the long term. In order to sustain a long term Agile transformation, culture needs to change, and this implies a different set of tools, methods, practices and skills than the ones you’ll find in Scrum, XP or Kanban. Change management is now a central discipline in my work with companies. A couple of other things I’ve improved over time are technical practices (code level) and human interactions (coaching, teamwork, conflict resolution, motivation…).

Why do companies want to implement Agile?

The first thing on the agenda, after Ángel starts to work with a company that wants to implement Agile, is to find out – why. As he said, almost hundred percent of the time companies are not clear about “why” they want to “implement Agile” – they just want Agile for the sake of Agile.

But when companies are looking for Agile it’s always a symptom of a deeper dysfunction or problem they need to solve. Sometimes is about market success, sometimes about time to market, sometimes about customer satisfaction… Again, when companies think on “cost reduction” or “maximizing profits” they are leaving customer value out of the equation, and this is a big mistake if you want to approach a Lean / Agile transformation. At the core, Lean and Agile are about maximizing customer value delivery, nothing else.

Crafting a vision statement for the transformation and keeping its customer focused helps us sustain the effort on the transformation and keep everyone clear on what the reason for all the struggle that comes from change.

Don’t use the ‘shock therapy Scrum’… Unless you have to

But what about the team members? How do they accept the new business approach? You can be sure that it’s an emotional process, especially if you use the ’shock therapy Scrum’:

It’s always about change. Nobody rejects testing, daily stand-ups or retrospectives because they have a better way of doing things: they just have “their” way of doing things, and when a stranger comes and decides to change them because some Jeff Sutherland says so, that’s usually perceived as an aggression. It’s not something rational, but emotional.

If I have enough time and resources, I prefer now to make the change more gradual and focus on the things that are impacting the team the most – hence, they are the ones deciding what to change or improve next, one thing at a time. Unfortunately, when we need change fast, we have to go for “shock therapy Scrum” as described by Sutherland, i.e., making everyone go Scrum on a Monday morning no matter if they like it or not, which is usually more painful.

Lean Startup approach

Well established companies can learn a lot from Lean Startups. They can be very flexible – we have seen them pivot, change their whole business model, their product… But can the bigger companies do the same thing? Ángel’s response is – yes!

I’ve been implanting Lean Startup approaches on well-established, big and medium multi-national companies. The companies’ fear of this is usually “I already have a user base, I already have a product, I can’t just experiment with those”, but in fact, Lean Startup strategies start way before the product, the market or even the business model have been defined. For instance, I’m introducing early stage experiments (pre-MVP) at a portfolio level, so in order to approve a project some assumptions need to be defined and validated by real customers. We are also enhancing feedback loops and the role of a Product Management Team with several perspectives (financial, market, technology, user experience…)

Is your business agile?

One of the goals is to achieve Business Agility. Medinilla defines it at a system level – end to end, concept to cash.

A business is Agile when it adapts to customer needs fast. Period. You can’t claim that you are Agile because you “do Scrum”, “test first” or even “are very productive” if you are not closely collaborating with your customers and adapting to change in order to maximize value delivery.

At the core of the manifesto, Agile is about four things: delivery, collaboration, change and improvement. Try it by yourself: read the manifesto and you’ll see that every principle or value falls into one of these four categories. Hence, Agile businesses are those who can collaborate closely with their customers in order to deliver value frequently and adapt these deliveries according to the market feedback, while constantly looking for new ways to improve their value stream.

On April the 13th Ángel will give insights on the Customer Development cycle and how it interacts with the Agile Product Development Cycle, creating a double loop of learning. The Scrum / XP feedback cycle (“Is this what you asked for?”) is not enough for successful products, he says. Scrum ensures a good execution of the Product Backlog, but there’s little information on how to build Backlog that describes a successful product.

Even worse: Kanban focuses on maximizing flow – it doesn’t even explicitly describe a feedback loop.

Hence, I think that there’s a bigger feedback loop that starts when we decide what to build (creating a Backlog) and it’s closed when, after Product Owner’s approval, the product is released and we observe the real effects on the market by looking at the appropriate product success metrics. These metrics need to be built into the product description itself (like, for instance, in user stories) and ideally will give us ideas on how to steer our product and project portfolio towards more successful results.

All of this and even more will be talked about at Terme Tuhelj, April 13-15. More info can be found at the official website.