Press "Enter" to skip to content

Are we doing good now?

First question first: are we doing good?

Yes!

The teams are doing fine and have found their ways.

Even better, we had the chance to recount our whole journey at Agile en Seine. If you take a look at the video, at the slides or at my article about it, you’ll see that we are now very happy with how we work and with what we deliver.

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!

jp-lambert.me

About the practices we introduced one year ago…

Completely split teams

Yes, the teams are still fully independent in their members, backlogs, meetings. Some smaller teams share the same Product Owner, but that’s all.

We previously recommended or even enforced that team members have to switch teams on a regular basis. Then we stopped switching team members, unless when specific members wanted to switch for a good reason. This has not happened a lot and basically since then the teams just stayed together and kept bonding.

While the teams are holding independent meetings, they sometimes do a joint Retrospective together. This is especially true of the JavaScript teams who happen to share a lot on a daily basis as they use the same tools, develop on the same code base, and use the same production environment.

Finally, the team structure itself has changed over time. We happened to have some really small teams (2 developers) which made sense given that we were expected to fulfill several missions at the same time. Indeed, as I liked to say during Agile en Seine:

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.

However, later on the project, the missions changed. One of the initial missions was fulfilled (or, we could say, sufficiently fulfilled for now) while another mission was still going strong if not stronger. So the two teams merged and shared the same mission and focus. This was also the moment when Kanban was introduced for the first time — more on this later.

No Scrum Master

Another element worth noting, at some point the Scrum Master — myself — left the teams.

When I joined the team — there was only one team at the time — I was fully engaged in the Scrum Master role.

Later on, the team got bigger and even became several teams. They hired a second Product Owner, yet I was still the only Scrum Master aboard.

In all logic, I couldn’t do the Scrum Master duties anymore, at least not as fully as before. Without even knowing it, I became an Agile Coach for all these teams instead of a Scrum Master: still there and ready to help, but not part of the teams anymore.

That’s one hell of a good question. This helped me realize I was not a Scrum Master anymore — thanks team!

In this specific case, it worked out really well. Actually I realized that I was the one holding the team back from becoming really, fully, completely self-organized.

And even later, I was asked to help another project instead. This request happened at the right moment as I kept creating even more and more distance between me and the teams. It was time to leave and help other teams.

When I announced that I was completely leaving the project, they ran a Retro specifically on the subject “how to keep going without Scrum Master”. The result is heartwarming.

While it played really well in this case, I don’t know if that’s how it should be in all teams: the Scrum Master leaving the team after a while. Yet it seems like in this specific context, with these specific people, it was in the end a good thing for them. Not sure how it would have played out in another context or with other people.

Move to Kanban

As I told you before, two teams merged into a bigger one.

Many people — me included — raised concerns about the ability of this newly formed, bigger team to manage itself.

Relying on my past experience of working with them — it really depends on the personalities of the team members — , I believed that they would have a hard time organizing themselves and keeping the efficiency high by doing Scrum without any Scrum Master.

My two suggestions:

  • Nominate a Scrum Master among them. He would have to make sure they always keep focused, working together towards a common goal.
  • Try out Kanban. The rules of Kanban — especially limiting the number of work-in-progress items — reduces significantly the need for such a facilitator. Kanban is the ultimate focus builder.

No-one on the team wanted to play the “process police” role. They decided to give Kanban a go.

All new “Hourglass” board, juste before it starts being populated and used.

And what a good move that was! Kanban is pure awesomeness.

In our case, not because the continuous flow allow for quicker reaction to change — even through the PO is definitely happy about it. Not either because the pull mindset is saner than the the push mindset — even through that’s a better way to drive the team rhythm. But because there is a strong link between the rules, how they are visualized and how they are enforced. That’s what this team, this collection of specific personalities in this specific context, definitely needed to work it out.

Even more awesome, and proof that it works for this team, the team fully took ownership of the board and of its rules, constantly making it evolve.

The Kanban board lives! The team keeps challenging how they work, and updates the Kanban board accordingly.

Later on, the success of Kanban with this team convinced the other JavaScript team to switch to Kanban too. That made totally sense given the dynamic nature of their product (they push to production on a daily basis) and also because all the JavaScript teams shared the same production environment. Using Kanban for all these teams made it easy to integrate the releasing board as the last part of all these teams’ Kanban boards.

Left part is another team’s Kanban board. Right part is the releasing board, another Kanban board shared by all JavaScript teams.

And since Kanban was a way that actually helped them keeping organized and getting things done, they also used Kanban to manager their Retrospective actions.

The board dedicated to the Retrospective actions of the team. We see on the upper left the Kanban way: WIP limit and visualization physically helps enforcing the rules. Still in the Kanban spirit, the time spent in noted on the post-it, as can be seen in the lower right legend.

The “Forum Hors du Guidon” — The Step-Back Forum

The “Forum Hors du Guidon” — which could be translated as The Step-Back Forum — was introduced primarily as a way to ensure the teams are aligned technically, but also as a way to minimize interruptions and to boost meetings efficiency.

To that end, it was a success. Retrospective sessions dedicated to improving this one-day meeting were held: at first for each sessions, and later only once in a while. And this continuous improvement worked: the format was tweaked in many ways, always trying to get more value out of it.

While at first the planning of the day was focused on meeting rooms, later it focused on teams instead.

At some point I was deeply frustrated with how things worked out. Basically everybody was convinced of how important this meeting was, especially in regard to the need for technical alignment. Yet most did not put the required energy ahead of the meeting, necessary to get it running smoothly.

It was interesting to see why it was that way; again the different personalities of the various team members was playing a role here, as well as the teams’ individual context.

For instance, when teams switched to Kanban, then they required much less backlog item preparation. They just prepared them on-the-fly, at the last possible moment and as part of their Kanban workflow. Thus they were not expecting the same outcome out of the Forum Hors du Guidon than their colleagues working in Scrum.

In the end they changed the meeting even more, they changed how the meeting goes but also when the meeting happens, and they found how to get it work for them smoothly and efficiently.

The specialties

I also talked about the specialties one year ago. The main idea was that team members take ownership of various aspects of the product and that it happens in all teams. As a result, the architect role is distributed across all team members and across all teams.

Or at least, that was the idea. I explained in the end of the article that we hadn’t really seen the mechanism in action yet but it had already proven useful as it helped everyone change his mindset and thinking towards architecture as everyone’s job and that they are to self-organize.

And, one year later… Well, I don’t really have any news to bring to the table.

No, specialties haven’t been really used by the teams. Sometimes people thought about it when they had to devise who should go to another team’s meeting to share his expertise and to learn what the other team will do. But, honestly, they already knew who on the team could do what. They did not need the specialities to do that. They knew each other, which is not surprising given that they work together, next to each other and on a daily basis.

And yes, specialties have certainly played a role into changing the team members’ mindset. That there is no dedicated architect or tech lead. That they all own the full product and the complete codebase. That they can and should ask to each other to foresee impacts. That even through each team has his very specific focus, however they must not forget that they are other people growing the product and that they should work together — just enough.

In the end, I would recommend doing such an exercise, especially with newly-formed teams, as it is a way to bond the team and to help the teammates get to know each other. But since the real goal of the exercise would be to trigger a specific mindset rather than to be an actual tool that will be used later, I would facilitate it differently, trying to spend less time on it.

Emergent design + exploratory testing

I attempted to formulate some kind of magic formula to handle Agile architecture in multiple Feature Teams:

  • Do emergent design to avoid costly, useless up-front design
  • And perform exploratory testing to make sure emergent design is going right

Does it work? Well, I don’t know. That’s something which is more easily said than done. The teams aren’t really doing emergent design, and they are not doing that much exploratory testing, at least not that kind of testing that would challenge the design as early as possible.

Is that a problem? Well, it seems not. I guess we could always do better, but right now they found how to work it out and it’s going smoothly.

I guess it’s mostly a matter of teammates knowing each other, not taking things too personally, and not over-complicating it.

So while I still strongly believe in this approach, it’s not an easy one to put in practice . True emergent design as well as true exploratory testing focused on challenging the newly growing design are actually two really difficult practices to live by.

Learnings

  • Dont’t overcomplicate it
  • One mission = one team
  • FOCUS!
  • Self-organization
  • A good team is a bonded team, where people know each other
  • Keep technical alignment in mind
  • Find the way to organize things that fits best the personalities of the team members

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Top