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!
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.
Agile en Seine
Organisée par l'association French Kanban User Group, Agile en Seine se veut une conférence multi-pratiques, ouverte …www.agileenseine.com
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?
I’m going to sell you into watching the video of the session 😋
You’ll find links to the actual session footage (videos, slides) — obviously you’ll want to have a look if you hadn’t already
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:
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)
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)
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:
Player @France Télévisions : passer de faire de l'Agile à être Agile
Revivez avec nous la grande aventure Agile de l'équipe Player à France Télévisions ! Au début de notre histoire, on…www.infoq.com
A quick interview of Richard and myself is available on YouTube:
For the record, Richard and myself also made a teaser video prior to the event. Not bad for amateurs!
Slides
You can view the slides of the session over SlideShare or Google Sides:
Agile en Seine
JP + Richard : bonjour ! Talk Format 50 minutes, Q/R incluses Jean-Pierre Lambert @jpierrelambert https://medium.com…docs.google.com
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
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.
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!
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”
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
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)
L’importance d’une vision pour l’équipe Scrum
Le fondement de la cross-functional teammedium.com
Assess how the team is going with tools like the Squad Health Check
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)
Rétro : Squad Health Check
Construire la Rétrospective autour d’un modèle de maturitémedium.com
The Retrospective is about deep process improvements, not to simply fix problems
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
I have written an article about this water-based serious game:
Cocktail Factory: balance specialists and generalists in a team
A water serious game about the organization of cross-functional teamsmedium.com
JIRA is no silver bullet
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
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
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)
Est-ce que j’ai besoin d’un Scrum Master ?
Probablement ! Voici les critères pour décider.medium.com
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)
Lecture : “96 Visualization Examples” par Jimmy Janlén
Un petit livret plein de fantastiques conseils sur le management visuel d’une équipe Scrum ou Kanban !medium.com
Traumatic events can be of real help
A big trauma (several months-long in our case), with the proper introspection, can lead to building rock-hard foundations.
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:
That f*%king gray zone…
Put a name on what’s wrong in our teams and organizationsmedium.com
Perform smart risk analysis and avoid full non-regression
In the following article I go through all the sections of this sample risk mitigation report, and explain how we use it:
Risk mitigation: formalization and communication
If you lose information along the way, the whole process will jammedium.com
Write down your processes, and make sure they take into account the realities on the ground
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:
Our release process in detail
Made to mitigate known problemsmedium.com
Have the process to help and not to constrain the team; visual management is your best friend
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)
Un process est un outil, pas une contrainte
Comment faire pour que vos process soient plus qu’une doc !medium.com
In this other article, I explain how we put in place this push-to-production process with the help of visual management:
From 1 release per quarter to 2+ releases per week
How we used visual management and gamification for our releasing processmedium.com
Physical boards are awesome!
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:
Daily Stand-Up: getting in sync about releases
The moment when all this visual management come to lifemedium.com
(sorry, article in French only)
S’assurer que la Definition of Done est bien respectée
Utilisation de fiches pense-bêtemedium.com
The Definition of Done is an interesting measure of team maturity
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)
Être Agile : avoir un DoD qui se focalise sur les problèmes à résoudre
Plutôt que Faire de l’Agile et respecter une checklist décrivant la solution !medium.com
Visual management is very helpful to synchronize several teams
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:
Boosting the release pace
Obviously with even more visual management!medium.com
Scrum is great, but Kanban is awesome (if your org is compatible)
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:
Scrum is good, Scrum is bad: planning
Both biggest strength and weakness of Scrummedium.com
Engineering excellence is at hand
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:
Our recipe for Daily Releases
It was upon a time a team that struggled to release…medium.com
You know it’s your culture when the team laughs at the joke and keeps the joke displayed
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
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
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:
Making use of goals
Especially in Scrummedium.com
Don’t share Scrum meetings between teams
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)
L’équipe s’agrandit : comment s’organiser ?
Comment mettre en place des feature teams quand le projet gagne en ampleur et nécessite plus de collaborateursmedium.com
Multiple teams means you need a specific organization do keep a technical alignment between the teams
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)
Distribuer le rôle d’architecte au sein des Feature Teams
Notre expérience similaire aux Chapters de Spotifymedium.com
One forum per iteration to keep teams aligned and to reduce the meeting overhead
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)
L’équipe ne trouve pas le temps de préparer les sujets à venir
Test avec un forum d’une journée dédiéemedium.com
Having self-organizing teams starts by making clear that it is expected
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)
Déclaration d’Autonomie : expliciter la vision des équipes auto-organisées
Poser le contrat de fonctionnement de l’équipemedium.com
More often than not, the limits of the team are the limits that the team forces on itself
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
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:
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 😄