Our first blogpost about the eXperienceAgile conference covered four interesting talks.
However, those were not the only talks so this post will dive deeper into some of the other ones.

Table of contents

• Leadership in a scaling agile environment, by Leonoor Koomen
• Building a Customer Value Engine for a more Successful Company, by Mario Moreira
• Agile Fluency Project - Why focusing team rock, by Diana Larsen

Leadership in a scaling agile environment, by Leonoor Koomen - written by Wouter Nivelle

Another great talk from the eXperience Agile conference came from Leonoor Koomen.
She talked about how leadership works in an agile environment.

Why do companies want to start working in an agile manner?
It could be these 3 very important reasons:

• It reduces the time to market / volume. A product can be released much faster.
• It breaks down silos. People need to work together and share knowledge.
• It increases engagement from the people working in the company.

But very often, it’s more because agile is in fashion and because of the myth that agile will bring twice as much in half the time.

When you read the above, it’s no surprise that agile projects often fail, as shown below.

See the third reason, with 38%? Those projects fail because management doesn’t support them.
So leadership is very important in an agile environment!

Leaders should:

• Bring a compelling why! Why do we do this project? What do we hope to achieve? Why does the company exist?

• Bring focus, give clarity on what needs to be done, a certain direction, with measurable goals.

• Break silos, make teams work together.

• Be accessible, be open for questions, criticism.

So leadership is very important and needs to inspire the various teams. Spotify is a big name and is used as an example for many companies. But Leonoor said:

I hate to break it to you, but you are NOT Spotify!

While Spotify can be used for ideas, you probably have different dependencies, stakeholders, situational problems and so on.
It’s thus very important to come up with a plan to scale.
How are you going to grow and handle problems?
Transparency is essential, but gets more difficult when you scale.

While growing, how are you going to handle the measurement of progress?
The most important measurement of progress is… a working product.

So stop asking for progress reports! Rather, create an environment for autonomy and alignment.
Give the teams autonomy to create the solution, while still providing the vision and alignment. Tell them what to do, but let them figure out the solution.

The image below describes it perfectly.

The agile transformation is a challenge, but there’s hopeful news.
It’s a long journey, but it is possible to achieve.

Every change, no matter how big or small, starts with the same word… YOU!

Building a Customer Value Engine for a more Successful Company, by Mario Moreira - written by Astrid Legrand

Intro

Building a Customer Value Engine for a more Successful Company aims to give enterprise leaders tools and advice to maximize customer value with a high level of agility in their companies.

Some methods explained during this workshop can also be easily used at a project level like, for instance, the five Rs model that helps to visualize the enterprise idea pipeline.

This tool allows to visualize ideas and treat them from the moment the idea is evoked until the moment it is realized.
The process consists of five stages, Record – Reveal – Refine – Realize and Release, which corresponds to a break down of the idea into a piece of work.

Recording an idea

At this stage of the process, when a new idea arises, it is documented. No decision has been taken on it so far, we do not know yet if this idea will be useful, if it will be accepted, developed, if it is a priority or if there are sufficient resources to work on it.

During this first stage, the idea is simply recorded and documented. In an agile environment, not much time should be invested in this stage and particularly in the documentation because we don’t know if this idea will go further through the process.
This stage should then allow to understand the idea, to determine who the users and beneficiaries are and to quickly estimate the costs linked to this idea.

Revealing the idea

During this stage of the process, the idea is added to the pool of ideas based on its value and priority. This is the moment when it is discussed and challenged among the stakeholders.

The idea is refined in order to decide if the team will continue to work on it. Even if the idea is great, it doesn’t mean that it will be developed as constraints and dependencies may exist.

It is at this stage of the process that those constraints are highlighted by the stakeholders or product owners. Following the discussions, the idea can be adapted in order to be realized and a team is selected to work on it.

Refining the idea

During the third stage, the idea is going to be more and more understood by the dedicated team. It is broken down into smaller and more precise increments in order to have a clear and detailed view of the idea.

It is challenged and cut into new pieces of increments that are challenged as well and refined in order to create a backlog of clear functionalities the team will work on.

Realizing the idea

This refined idea is then decomposed into user stories.
Those user stories are documented and prepared by the team with the purpose to be developed.
The user stories are then added to a sprint, developed and tested in a team effort.

Releasing the idea

The idea has now been transformed into a product that will be presented to end users. At this stage, the plan drafted by marketing and sales is executed and the new increment that is now on the market, ready to be used is communicated to the potential customers.

Use of the five Rs in my daily work

As an analyst within a Scrum team, my work can be structured around the 5 Rs model as explained below.

Recording the idea

Let’s use a concrete example of my work. The ‘UnIt’ application we are building automates as much as possible the management and payments of the indemnities to insured members when they are unable to work.

However, this automation has limitations. For instance, not all claim amounts can be calculated automatically in some complex cases. The idea of allowing users to make certain calculations manually has therefore been evoked and added to the pool of ideas. The idea has been discussed and challenged.

Revealing the idea

The idea is now in the pool of ideas, the backlog, according to its value and priority. Discussions over the idea are ongoing and questions are raised.

• Should users be allowed to make (all) calculations manually?
• What are the risks? Are there limitations to this idea?
• Are there legal constraints?
• Should the idea be developed in priority, or should it wait in the pool of ideas?

Those discussions are conducted among product owners, analysts and developers. A sub-team is then created (with one analyst and developers) and is dedicated to the topic.
The needs are refined and the amount of work needed to develop the whole concept of manual calculations is estimated.

Refining the idea

The functionality needed to implement the manual calculations is now better understood by the sub-team responsible for this idea.
The functionality is discussed, refined and cut into smaller increments to obtain workable user stories. All user stories together make the manual calculations possible, but can be developed separately.

The user stories are described in detail with preconditions, post-conditions, use cases for testing and dependencies, if any. The user stories are also technically discussed at this stage.

Realizing the idea

User stories about the manual calculations have been presented to the entire team during a backlog refinement. They have been estimated with story points and because they were ready according to our Definition of Ready, they have been developed through several sprints.

Releasing the idea

In my example, this stage happens in the demo of the new functionality for the manual calculations at the end of the sprints.
The manual calculations can be tested in the acceptance environment by the product owners and the final users.

An enterprise idea pipeline provides transparency of your options and allows you to quickly be aware of and respond to high-value work
M. Moreira

Agile Fluency Project - Why focusing teams rock, by Diana Larsen - written by Michaela Broeckx

Diana Larsen, or @DianaOfPortland, was an honourable guest at eXperience Agile conference. Browsing her website FutureWorks Consulting, and googling her name, it becomes clear she had an amazing journey leading up to this Agile Fluency Project, throughout which you can move the Agile Fluency Model from idea to implementation, a model she co-created with James Shore.

The concept of fluency is omnipresent in most of her talks and articles, and related to that team collaboration has been one of her primary topics throughout her career.

What is fluency?

Fluency is routine practice mastery that persists under stress. In Lean, we would call this kata. You could say it is the skillful ease that comes from investing in learning.

That investment comes down to taking the time and making the effort for deliberate practice. By regularly and consistently practicing a skill with increasing levels of challenge and with the intention of mastering that skill, a state of fluency can be reached. The key is to not give up easily, and with that intent, to keep up your practice until it becomes a second nature… a bit like practicing your cycling skills as a kid, because you long to get rid of those silly training wheels.

From team to organisation

The Agile Fluency Model fist focuses on team fluency, a form of fluency that transcends the individual practice, and just like a team is more than the sum of its parts, team fluency also depends on management structures, relationships, and organizational culture, as well as the tools, technologies, and practices the teams use. Team fluency is what you get when highly performant teams become unconsciously competent at collaborating and co-creating. Fluency is the outcome of investment in learning and deliberate practice, and for team fluency this means learning together as a team.

There are a few stages before your team gets to fluency. You need to invest in mastering the agile fundamentals to help focus as a team and you need a shift in team skills to be able to build sustainability while delivering value. The Fluency model helps you discover the topics you can explore and practice to improve these aspects and make these shifts.

From there onwards, the picture becomes broader and from teams we move to the organisational structure and culture. In the model, Diana and James offer the tools to help you dig deeper into these topics, and make it more clear for organisations what could be worth investing in to optimise organisational Agility, on a systemic level. To embed fluency in the organisations, they point out the need to invest in a cross-organisation focus and generate a shift in organisational culture.

What is the aim of this model?

There are no recipes for the perfect agile transformation. And so the creators of this model wanted to move beyond the agile methodology ‘wars’ on what is the best way to implement agile. They wanted it to be a positive, inclusive model that promotes improvement, so that it can be used to continuously grow towards more agility, as an individual, as a team, as an organisation. In that sense it is a model that can guide your team to help create alignment with management, and chart your own agile pathway. But it doesn’t have to be a path to perfection. The way James Shore puts it, the idea is that you get off at the right bus stop, the one that fits your needs, and offers the benefit you want for your company. No need to go all the way to the terminal bus stop if that is not required in your story or context. Therefore it is not a maturity model per se, but more of a map for a hop-on-hop-off bus.

Discover more about this topic on the Agile Fluency Project website.

Or buy a ticket to ride at Ordina. Our colleagues of AgileWorks can help you to get on that bus!