Press "Enter" to skip to content

Feedback from France Télévisions’s Player team: “From Agile practices to Agile mindset”

September 20, 2017 at Agile en Seine

Feedback from France Télévisions’s Player team: “From Agile practices to Agile mindset”

This was the session we hold during Agile en Seine 2017!

Cet article est également disponible en français.

I had the pleasure to hold a session with Richard at Agile en Seine.

What was our session about?

Come and relive the great Agile journey of the France Télévisions’s Player team! At the beginning of this tale, we call out this team as every other team, barely trying to apply Agile practices. Bit by bit, changes will happen until the team truly comes to master and live by the Agile mindset!

What is this article about?

  1. I’m going to sell you into watching the video of the session 😋
  2. You’ll find links to the actual session footage (videos, slides) — obviously you’ll want to have a look if you hadn’t already
  3. You’ll find transcriptions of the take-away tools and tips that we introduced in this session so that you can find and re-use them more easily, plus I will link to specific articles I wrote about them in case you want to dig further

Don’t understand French at all? No problem! Go straight to the transcription part for English-only. And do not hesitate to ask for more details if anything catches your eye.

Missed the event? Why would you want to watch it?

Rather than giving a shot at explaining how awesome was this session, please have a look at the feedback we’ve got:

September 20, 2017 at Agile en Seine

The speakers made a perfect speech and displayed a great energy!

Really easy going: understandable words and a great deal of transparency with concrete examples of what have been put in place (an abridged version of Jean-Pierre’s blog).

A Real sharing moment!

Thanks Jean-Pierre Lambert and Richard Sourianarayanane.

#AgileEnSeine

(translation is mine)

September 20, 2017 at Agile en Seine

Awesome! With humour and references to the Agile Manifesto, the Scrum Master and the Product Owner invite us into their everyday life… whose beginning looks a lot like ours!

(translation is mine)

September 20, 2017 at Agile en Seine

Fantastic feedback at #Agileenseine that all “#agile” teams should listen to in order to step back and ask themselves “Are we agile”?

(translation is mine)

Want to see the full session? Here are the resources

Videos

Our session has been filmed and is publicly available on InfoQ:

A quick interview of Richard and myself is available on YouTube:

September 20, 2017 at Agile en Seine

For the record, Richard and myself also made a teaser video prior to the event. Not bad for amateurs!

September 20, 2017 at Agile en Seine

Slides

You can view the slides of the session over SlideShare or Google Sides:

September 20, 2017 at Agile en Seine

The take-away advices and tools introduced during this session

This section is not a substitute to the session itself. It is intended instead as a supplement to the actual session itself.

As such, you’ll find a recap of all the advices and tools that we introduced during this session, with a few comments and when available links to further reading.

Please note that the order here is not directly related to the order in the slides.

Product vision is mandatory

September 20, 2017 at Agile en Seine
September 20, 2017 at Agile en Seine

No product vision means that you are to do whatever you are asked. A product vision is what enables you to say ‘no’.

In absence of a product vision, you create a bloated software, always adding more features at the cost of technical debt.

You end up drowning under the technical debt. One of the symptoms is that releasing is a real pain point, and the release pace is slow.

September 20, 2017 at Agile en Seine

On the other hand, having a clear direction will make a big difference.

This can be on behalf of the Product Owner or, even better, from the organization giving a clear, big vision.

A bad product vision is better than no vision at all — you’ve got to start somewhere!

September 20, 2017 at Agile en Seine

The product vision is fundamental, but that does not mean it is easy to define — on the contrary!

So it’s really OK to try and learn at the beginning. The next visions will only be better.

A Product OWNER must be free to say “NO”

September 20, 2017 at Agile en Seine

Easier said than done, it is fundamental to the Product Owner role: being free to take decisions on the product he manages.

This is clearly expressed in the Scrum Guide.

Saying “NO” is one of the biggest defining elements of a true-to-the-word Product Owner.

Having a vision (and displaying it) has more impact than having next iterations ready

September 20, 2017 at Agile en Seine
September 20, 2017 at Agile en Seine

The team was aware for a long time that they lacked vision and that it was a problem.

However the obvious “fix” was a missed shot: ask for the Product Owner to have more and more next iterations ready so that the team knows what’s next. That demanded a tremendous effort on the PO’s side but did not make things much better.

Indeed this missed the point. The day the Product Owner provided a vision for the team, the problem was fixed. Even better, the PO took the liberty to print this vision in really really big characters, going from one side of the open-space to the other.

This article brings background on this specific event and tries to draw some conclusions:

(sorry, article in French only)

Assess how the team is going with tools like the Squad Health Check

September 20, 2017 at Agile en Seine

Tools like Spotify’s Squad Health Check will give you interesting insights on the team, on several levels:

  • Doing the assessment on a regular basis, it is interesting to look at the trends and how previous changes impact the team
  • Having several teams perform the assessment and putting side by side the results of all teams gives an interesting view about the global system, how different their contexts are and which problems they are sharing

In this article I describe how we use Spotify’s Squad Health Check as part of our Retrospectives:

(sorry, article in French only)

The Retrospective is about deep process improvements, not to simply fix problems

September 20, 2017 at Agile en Seine

Do not stick at the first why and dig deeper until you reach the true root cause.

Only then, fix it and improve the actual process, making sure the problem won’t happen again.

What was that workshop? Cocktail Factory

September 20, 2017 at Agile en Seine

I have written an article about this water-based serious game:

JIRA is no silver bullet

September 20, 2017 at Agile en Seine
September 20, 2017 at Agile en Seine
September 20, 2017 at Agile en Seine

You’re not Agile just because you’re using JIRA… Actually, you must be careful on how you use JIRA.

JIRA can be a great tool, but beware of the “only one person is on the computer” syndrom, leading to a meeting full of passive participants.

Without any Scrum Master, the team will struggle to experiment with the JIRA workflow

September 20, 2017 at Agile en Seine

As much as it is fundamental for the team to experiment with the workflow of its Technical Tasks, User Stories, Epics, Bugs and Releases, using JIRA makes it more difficult than needed.

The team will end up using the default workflow instead of challenging how they work.

One possible role of the Scrum Master is to smooth this workflow experiment.

Having a dedicated, skilled Scrum Master is really helpful

September 20, 2017 at Agile en Seine

A dedicated Scrum Master in the team will be very helpful as he will give useful insights to the team.

He will also help introducing visual management and get the team to respect the rules they set for themselves.

Here is a previous article I wrote making the case for the need of Scrum Masters in teams:

(sorry, article in French only)

This other article reviews Jimmy Janlén’s wonderful book about visual management:

(article in French but the book is in English — you can have a look at the samples from the book)

Traumatic events can be of real help

September 20, 2017 at Agile en Seine
September 20, 2017 at Agile en Seine

A big trauma (several months-long in our case), with the proper introspection, can lead to building rock-hard foundations.

September 20, 2017 at Agile en Seine

Later on the project, we smelled that we were facing a similar situation on another product line but this time we made sure to avoid the whole tunnel.

The big lesson here would be: how do we create a sense of urgency instead of waiting for the trauma to happen? The following article is about this idea:

Perform smart risk analysis and avoid full non-regression

September 20, 2017 at Agile en Seine

In the following article I go through all the sections of this sample risk mitigation report, and explain how we use it:

Write down your processes, and make sure they take into account the realities on the ground

September 20, 2017 at Agile en Seine

Writing down the push-to-production process was an important step for the team.

We made sure that it took into account all the recurring problems we encountered.

This is explained in detail in the following article:

Have the process to help and not to constrain the team; visual management is your best friend

September 20, 2017 at Agile en Seine

Your ultimate goal is not to be the cop of the team and to make sure that the processes are followed. You’d rather have the processes spontaneously followed by the team.

This happens when the team finds the process helpful. I have explained this whole philosophy in the following article:

(sorry, article in French only)

In this other article, I explain how we put in place this push-to-production process with the help of visual management:

Physical boards are awesome!

September 20, 2017 at Agile en Seine

So many information can be put on a single physical board… It makes it hard to go back to an electronic board once you’ve really tasted to the physical flavor.

This board shows several elements that I have explained in detail in other articles:

(sorry, article in French only)

The Definition of Done is an interesting measure of team maturity

September 20, 2017 at Agile en Seine

What is the team’s Definition of Done like? More like an exhaustive checklist or more like a set of holistic criteria that must be met?

The team’s maturity can be assessed from this simple observation. A mature team will put more emphasis on making sure that the problem is fixed rather than on ticking all the boxes of the solution. Moving away from the framework and sticking to what really matters.

I developed this train of thought in the following article:

(sorry, article in French only)

Visual management is very helpful to synchronize several teams

September 20, 2017 at Agile en Seine

Visual management is also a great tool to keep several teams sync’ed. In our case, we used it with great success to organize the releases of three teams working at the same time on the same product and same code base— up to the point of continuous release.

The following article explains how we put it in practice:

Scrum is great, but Kanban is awesome (if your org is compatible)

September 20, 2017 at Agile en Seine
September 20, 2017 at Agile en Seine

I love Scrum but switching over to Kanban was our best move ever. It is all about the mindset, moving from push to pull. I’d say that getting the organization to work with the pull mindset is usually the next level in Agile implementation.

If the subject interests you, please have a look at this article:

Engineering excellence is at hand

September 20, 2017 at Agile en Seine

Continuous Delivery is hard!

I won’t say it is easy, but if our team managed to do it in less than one year with a desperately too low automated test code coverage, then why your team couldn’t?

This world is at hand, you can grab it if you want to.

If you want to dig deeper the question, here is my article summing it all:

You know it’s your culture when the team laughs at the joke and keeps the joke displayed

September 20, 2017 at Agile en Seine

This poster is about a very important matter: code coverage by automatic tests.

And the team is joking about it.

And the team laughs about it.

And the team is not feeling ashamed to display it.

Because besides this poster, there is a real message. Yes, we’ve got to increase our code coverage by automated tests.

In this team, increasing the code coverage by automated tests is part of the team’s culture.

Make sure you’re able to deliver the feature to the customer before writing the code

September 20, 2017 at Agile en Seine

Smoothing out your delivery process is essential. To be able to deliver often and quickly unlocks many doors.

Spend less time making sure nothing is broken and instead grab extra opportunities.

What if you were mistaken and broke something anyway? Well you fix it so quickly that customers barely notice it.

We never used the word in the team but when we think about it, the whole mindset “make sure you’re able to deliver the feature to the customer before writing the code” is actually the DevOps mindset.

A single team must have only one, single mission

September 20, 2017 at Agile en Seine

Focus is one of the values of Scrum and is paramount for any team to be successful.

Our experience taught us that if it is not possible to have only one mission for the team, then it may make sense to split the team so that each (smaller) team only have one mission.

Even if you end up with really small teams — the focus will be a greater enabler.

On a related note, this article is about Sprint and daily goals and how not to set two goals in one — having only one vision for the team is the same thing:

Don’t share Scrum meetings between teams

September 20, 2017 at Agile en Seine

How do you organize a previously big team now split as several smaller teams?

Don’t keep meeting together!

Have all the teams artefacts and meetings split and help each team define their own identity and processes.

That did not happen overnight. I described this specific journey in this article:

(sorry, article in French only)

Multiple teams means you need a specific organization do keep a technical alignment between the teams

September 20, 2017 at Agile en Seine
September 20, 2017 at Agile en Seine

It is hard to split teams. The reasons are not only because they love to be together; it is also because being together makes it easy for them to be technically aligned on the processes, good practices, shared code base, and so on.

Once you have several teams, you need a solution at the organizational level to foster and keep this technical alignment.

This article digs deeper into what we tried to answer:

(sorry, article in French only)

One forum per iteration to keep teams aligned and to reduce the meeting overhead

September 20, 2017 at Agile en Seine

The “Forum Hors du Guidon” (“Step Back Forum”) is a once-per-iteration, whole-day event where all the teams meet together to prepare the up-coming iterations.

Having all the teams together allow them to stay aligned and to make sure that cross-team needs are properly taken into account.

We are also happy that this practices practically removes the need for any other meeting during the rest of the iteration (excepted of course for Scrum meetings: daily stand-up, Sprint Review, Sprint Retrospective, Sprint Planning). This is great because meetings interrupt the team, leading to reduced productivity, poor meetings and frustration.

The following article describes in further detail this practice:

(sorry, article in French only)

Having self-organizing teams starts by making clear that it is expected

September 20, 2017 at Agile en Seine

Self-organizing teams.

It’s a fundamental pre-requisite of Scrum.

Yet it’s very hard for teams to practice it.

Maybe the first step would be to make it clear to the teams that it is what we expect from them?

That’s the whole point of this “Declaration of Autonomy”:

  • How the team should work — you’re given freedom, make good use of it
  • What we expect from team members — you are the one who will make it work

You’ll find the complete content of the document as well as some background about it in the following article:

(sorry, article in French only)

More often than not, the limits of the team are the limits that the team forces on itself

September 20, 2017 at Agile en Seine

We stopped JIRA.

We organized as we see fit.

We have been free to do so.

Nobody stopped us!

Our definition of Agile: Technical Excellence + True Product Vision + Efficient Organization

September 20, 2017 at Agile en Seine

I give this definition of Agile on our own responsibility.

  • Technical excellence: it is very hard to be Agile in the absence of technical excellence.
  • True product vision: you must take hard decisions, which you can only do when you have a clear vision for the product.
  • Efficient organization: Scrum, Kanban or whatever… Just do what makes sense in your context — and don’t what do not bring any value! Favor as much as possible lightweight processes.

And thanks again for you all who voted for our session, attended it, or gave us feedback! 😘

Last bonus, a drawn sum-up of our session, courtesy of Julien Carreaud:

September 20, 2017 at Agile en Seine

Did you like this article?

Follow me to be notified when I publish new articles!

And don’t forget to clap 👏 and share the article! Don’t forget that it is your love 💗 that makes me putting my heart and soul into writing.

Thank you 😄

Top