This year, it was already the 6th edition of eXperienceAgile, organised in Portugal, Lisbon by Radtac and Hugo Lourenço - a DevOps and Enterprise Agility Advisor. This global conference focuses on gathering wisdom and best practices on business agility as well as technical agility, and therefor it was the perfect conference for JWorks Agile & DevOps practitioners and enthusiasts.

The first day contained fourteen talks on team and business agility with speakers from Europe and America, whereas the second day contained DevOps talks and deep-dive workshops with some of the speakers.

@experienceagile / #xa19 / experienceagile.org

Table of contents

• Half-Agile: 5 Leadership Mistakes Diluting Your Transformation, by Jesse Fewell
• The Toyota Flow System, by Nigel Thurlow
• The Agile Futurist, by Mario Moreira
• Escape Velocity, by Doc Norton

Half-Agile: 5 Leadership Mistakes Diluting Your Transformation, by Jesse Fewell

Jesse shares with us five patterns on our journey to an Agile organisation. He explains why this journey can be so hard, especially for leaders (team leads, scrum masters, technical leads, managers or executives).

You start with a good decision, then for some reason you get frustrated and agitated. Once you discover the mistake made, you can take action to correct it.

Buy-in, Engagement

Very often you have a good idea and just tell the people around you to execute it. But along the way you forget to explain the reasoning behind this idea, which leads to misunderstanding and frustration. As leaders it’s your job to create context for the change and communicate methodically and excessively. This is hard, because it takes time, repetition and requires patience.

Impact

The first good step, as a leader, is to take initiative. Other departments may not want to be Agile, so you will start alone. You’ll be the role model to set the tone for the organisation.

However, this leads to a team trying to be Agile in an environment that is not Agile. And you end up doing Water-SCRUM-fall or Modern Waterfall.

So you need to take the next action: invite others to the table. If you want the Agile journey to move forward it has to be about Agile, not just YOUR Agile. Allow the journey to evolve instead of following a fixed methodology.

Practices

You often tell colleagues to follow standard techniques, including daily stand-ups, spring planning, retrospectives, etc… These are practices that everyone uses. So, if you want to be like everyone else, you should definitely apply these techniques.

Let me tell you a little secret: if you try to be like everyone else, you’ll never be ahead of everyone else!

You need to experiment, try things out. Not just do things because others do them or because you read them in a book. You need to find YOUR Agile. Don’t just copy-paste your Agile.

Workload

Everybody is struggling with more complexity, more change and more requirements, but there are loads of good opportunities and you want to do all of them.

People get overwhelmed by this, because there is so much work and now we want to do an Agile change or transformation.

You should try not to over-commit. Find your One Thing that you can focus on, so that you can make more progress with the same effort. Learn to say NO, with diplomacy.

Talent

When you want to go on an Agile journey, you want everyone else to get better. As a leader, you take the role of a mentor. You show and teach that you are Agile and they need to follow you.

But you get frustrated, because they are not changing fast enough. You feel like you are Agile, but they are not. Because you forgot about yourself as the leader. If you want to transform your organisation, you need to first transform yourself as a leader in the organisation.

You need to challenge your own assumptions. Take a leadership training or workshop and get inspired. Maybe you need to think about:

• delegating more instead of doing;
• shifting from explaining methods to articulating goals; or
• instead of telling people what to do, give them the ability to do it themselves

This personal growth requires that you go on a long-term journey of transforming yourself as a leader.

The Toyota Flow System, by Nigel Thurlow

We all know that Toyota has always been a frontrunner with regard to Lean thinking, bringing the customer in the center point of attention and establishing flow in the value creation pipeline. The Toyota Production System (TPS) - with its two pillars: continuous improvement & respect for people - as developed by Taiichi Ohno and Eiji Toyoda, is globally recognised as a strategic and human centered foundation to become a Lean and thriving enterprise. On this foundation ‘the Toyota Way’ has been developed as a philosophy with a set of principles and behaviors that can guide companies through their change and towards the right mindset.

Recently, with the Toyota Flow System (TFS) the Toyota thinkers take this strategy yet a few steps further with the purpose of being an inspiration for companies with human centricity, continuous improvement in their strategic roadmap. Together with co-facilitator Dirk van Goubergen, Nigel Thurlow - Chief of Agile, Toyota Connected - has given us a hands-on introduction to the extra dimension that this evolution entails.

Building on lessons learnt and extensive research

Nigel Thurlow puts it this way:

There are fantastic lessons to be learned all around, from Systems Thinking to Scrum. The body of knowledge at our disposal is immense, and there are countless ways to apply it. But to truly leverage this wealth of information, we must change the narrative and realize that context is everything: different environments call for different approaches and tools, and with something as complex as a business transformation, sticking to a one-size-fits-all methodology is dangerous. Instead, we need to be able to mix and match the techniques that best suit our situation, while ensuring that key aspects of a transformation are considered.”

Get the basics right

With the Red Bead experiment, we experienced that we need to verify that companies apply the right kind of Lean, and not the evil version, when trying to eliminate waste. Waste is not caused by the workers most of the time, but by the system. Failing to recognise this can bring leadership to take the wrong decisions and apply counterproductive measures - like hiring or firing employees, or introducing contradictory KPIs among workers, thus creating steady erosion of psychological safety within teams - and in the meantime not tackling the actual process issues in the pipeline.

Three questions can help us define waste, explained by Dirk:

• What is value for the customer?
• What products are we making?
• Which activities contribute to this result?

Listing activities and highlighting the ones that are simply uselessly getting tired is a very important exercise for every contributor in the process, whether it be workers in a factory, developers, testers, consultants, or third parties or managers. Show respect for people by allowing them to focus on value adding activities. Since the management and people with leadership roles often organise the system, it is key they recognise this responsibility.

Once the activities are inspected and the process of value creation is established, the next step is to enable flow, by designing your value stream like a river, allowing the value to grow without interruption, without waiting time or blockages. Here again, managers have a task to focus on not being a flow stopper. It is important for them to acknowledge that resource efficiency can kill flow efficiency. Just like a train company should focus on timely arrival and departure and not on getting as much travelers in one train by waiting until it’s completely full before taking off again. For Toyota, as well as for any development team, the key is to ensure a flexible workforce, with engaged cross-trained employees that have a thorough understanding of the value adding processes throughout the company. This enables them to flexibly partake in flow efficiency whenever and wherever needed.

Toyota Flow System, the DNA for organisations

The TFS model aims to sustain the flow of value to the customer. And Toyota offers a body of knowledge that helps companies to understand the different aspects of customer first value delivery with a systemic approach to optimize for the whole, and not the subparts, or silos.

These aspects - visualised as three pillars - are supporting this motto and form the DNA of the Toyota Flow System. But let it be clear that these three cannot exist without each other. The helix structure of the pillars points to their intertwined importance, making the structure trustworthier and stronger.

1. Complexity thinking: understanding uncertainty and complex adaptive systems
2. Distributed Leadership: the behavior patterns of those who lead people and teams
3. Team Science: the science of teams, their interdependencies and interactions

For every pillar, Toyota has listed a number of possible theories and practices that need to be considered when trying to achieve the motto. For every context, the combination of selected theories, practices and models can be different. By giving this list of researched and tested material, they offer a good starting point for companies on a transformation journey, allowing them make the founded decisions within their own particular business context.

Take a good look at what Toyota suggests for every pillar. There sure is a lot to discover!

Key takeaways were:

• Teams need to learn how to do team work and be more than the sum of the team members. Teams do not have the set of skills and behaviors automatically, and so they need coaching to focus on team communication and collaboration aspects as well as team personality dynamics.
• Intent based leadership - as coined by D. Marquet - helps you to move authority where the information is available. It is about designing an environment where people give intent to each other and they feel valued and proud of their work. It is about actively giving control to people who maintain the information so they can make informed decisions.
• Scrum is disciplined PDCA - the Plan/Do/Check/Act (or Adjust) approach from William Edwards Deming
• Beware of failure demand, which is waste disguised as value for the customer and service excellence.
• People are spending the best years of their lives in companies.. take up the responsibility to make it as enjoyable as possible.

More reading: https://planet-lean.com/introducing-the-toyota-flow-system/.

The author of the mentioned article wraps it up saying:

This is the first time someone has brought all these elements together and made sense of them, explaining how they fit within a company like Toyota. Complexity thinking is a change in mental models and management practices. The Toyota Flow System is the first to externalize it with tools and in a contextual setting. The next step will be testing it in the field in different contextual settings, to see what works and what doesn’t. It will be exciting to see how it evolves, which we are sure it will. That’s the beauty of it.

The Agile Futurist, by Mario Moreira

This was an energizing talk, giving us a view on the trends in the Agile movement for the coming ten years. Mario Moreira is an enthusing and influential Agile transformation Leader, Agile enterprise coach and change agent who has written four books a.o. Being Agile: Your Roadmap to Successful Adoption of Agile, and The Agile enterprise: Building and Running Agile organizations.

What is Agile?… is what he asked the eager crowd.

• It’s a set of Values and Principles
• focused on the delivery of value to the customer

What is Agile not?… on the other hand.

• a certification
• a tool
• a silver bullet
• a process
• it’s also not merely redefining roles
• and… it is definitely not undisciplined

Agile trends for 2029

Bring Back the Basics

We will all go back to the core, to rediscover and be inspired by the central purpose and initial intent of the Agile movement. Returning to the core implies that we need to make sure we understand the heart of the Agile manifesto, that we try and urge to live the principles and lead with the items on the left in mind.

Stop doing Agile for Agile’s sake

Agile is not the goal or outcome. So let’s stop talking about it as if it were.

Rather we should look at the purpose for applying Agile.

• Better interactions
• Better working software (or services and products for that matter)
• Better customer collaboration
• Ability to respond to change

And people will gradually focus on better business outcomes:

• Deliver increased Customer Value
• Optimize the Flow for faster delivery
• Increase Quality with Feedback Loops

Leading with uncertainty

Because leading with uncertainty is the smarter thing to do, in a world where we - as customers - don’t always know what we want, we - as product creators - don’t always know exactly how to build the product, and where things and people tend to change along the way.

Uncertainty requires the right behavior and mindset to tackle it: e.g. cultivate and kindle a discovery mindset, experimental and incremental thinking, and implementing feedback loops. We all need to practice and keep on practicing, to walk the talk, and eventually lead by example.

Agile throughout the enterprise

The way organisations are structured today is a remnant of what was required in the industrial age. But focusing on the customer and tracking the value stream has led to insights on how work and collaboration should be organised in a smarter, more valuable way, for all parties involved. Working together cross-departmental with an empowered team, focusing on a common customer inspired goal, helps to limit handovers, approval flows and delayed communication. To make this happen, every person who’s directly involved in this end-to-end value stream, from any silo throughout the company, needs to be allowed and be able to work dedicatedly, and transparently as well as make local decisions on matters that require her/his expertise.

This way of working depends upon efficient alignment and trust… in people and their abilities, to make the magic happen. Trust is not given, it should be a given that people perceive and recognise, from the moment they first enter the company building. When trust is present, people take decisions, and cultivate ownership.

Solve Holistic Problems

The sky is the limit. And it always has been for the intrepid. No business domain or sector is simple and predictable enough to allow it to acquiesce in the industrial way of working. With IT and AI permeating every nook and cranny of this global society, and with companies being ushered by market disruptions to the verge of survival, we need to realise that focusing on value creation and optimizing the whole (the team, the company, the system) to service the customer is the smartest way forward.

Seeing and understanding the bigger picture of what we - as a team, as a company, as a sector - deliver to society is the next step. From then on we will be solving holistic problems, in a holistic way. With our thriving society as the customer.

Escape Velocity, by Doc Norton

A recurring problem with agile projects is reporting. When you search for information online, everyone seems to encounter the same problems.

• What metrics should I use?
• How can I make the team’s performance visible?
• How can I identify possible bottlenecks?
• How do I forecast?

The most common metric that everyone uses is velocity. And, as the title of this section already indicates, that’s not always a good idea. Doc Norton had a good talk at this conference as well as the accompanying workshop the day after.

In short, velocity is a lagging indicator and thus not good for predictions. Now, what does this mean, a lagging indicator? It indicates data from the past, it lags behind.

Another problem when using only velocity as a metric is that it tries to explain a complex system. A dip or peak in velocity doesn’t explain anything, it’s just an indication that something might be wrong. To find the real cause, more metrics are needed.

So as Doc said:

Velocity is a lagging indicator of a complex system.

And as a result:

Velocity is not good for predictions and not good for diagnostics.

Predictions

Everyone has already experienced the typical management question during the lifecycle of a project:

How long will it take to deliver feature X?

The usual solution is to take the velocity of the past sprints, estimate the feature and then simply divide the feature by the velocity. That gives you the amount of sprints needed to complete the feature. Now, think about this:

• Are these forecasts accurate? They might be, we don’t know for sure.
• Are these forecasts definite? Possibly.
• Are these forecasts probable? Again, they might be.

An example given by Doc was the following:

Velocity (11, 10, 9), backlog size of 130 and start date is today.

Now, the velocity in this case is 10: 130 / 10 = 13.
So the estimation would be that the backlog is finished in 13 sprints. My experience is that these estimations are usually incorrect since 13 weeks is too far in the future.
A great tool that he showed was the Throughput Forecaster, an Excel file in which you can enter a lot of data and in return it shows the probability of achieving the goal.

More details about the tool above will follow in a future blogpost.

Diagnostics

As we have already said above, a dip or peak in velocity can indicate that there might be a problem with the team.

But when looking at this chart, how you do know what’s going on? Exactly, you don’t. You just know something’s probably not okay.

A metric that helps is the cumulative flow diagram.

It shows the different stages of sprint items during the lifecycle of the sprint. You could see that it takes too long to validate an item or to deploy it.
For example, the image above shows that the items stay too long in Ready for Approval. The team can use this to address the problem.

This picture was taken during the workshop from Doc about this subject where he went into more detail.

Conclusion

Velocity is a metric for Agile teams, but only velocity doesn’t indicate much. It needs to be combined with other metrics in order to resolve problems. And use the metrics together with the team so they can detect themselves when there are problems, so they can be resolved as soon as possible.

Metrics are not just for managers, metrics are for teams.