Mob programming: start signal

We finally gave Mob Programming a try here at Amadeus IT Group !  If you don’t know what Mob Programming is, you can find more information on mobprogramming.org.

How did we finally get there? The first step was a one-hour presentation of the concept of Mob Programming by Woody Zuill in the Boston office of Amadeus IT Group. He graciously accepted to give this talk to us, and we thank him again for that. We are based in Nice, in the south of France, and attended the meeting via webex. One Scrum Master was very impressed by the presentation and talked about it to his team. So they asked me to give them more details about this “technique”, which I did, and at the end we decided to give it a try. The main reasons were:

  • When working individually we accumulate some specialized knowledge, that we don’t share with the others
  • When working alone, we usually give up the practices like TDD (and in fact the team had  even never started to do TDD). Perhaps when working together, there will be a sort of emulation to use more good coding practices.

We decided to schedule five initial half-day mob programming sessions, as an experiment. Because that’s what agile is: trying things and see if it works for us.  As I was a little anxious, I had a quick skype session with Woody Zuill the day before and he told me that the best way to start with mob programming is to try to find something to do out of the “business as usual” stuff. You can for instance start with some sort of coding dojo with the whole team, with a coding exercise like Fizz Buzz. There is no pressure when you do this exercise, and the team will be more able to focus on trying to develop good interactions.

Another tip that Woody gave me was to start with frequent rotations, something like every 4 minutes, so that the team members get used to those rotations (it can be counter-intuitive for a developer that is used to work alone).

Last but not least, Woody insisted that mob programming works well if you use TDD. If not, how can you be sure not to accumulate technical debt and defects when you mob?

So there we were, 4 people in the same room (unfortunately one of developer was in training this day). We decided to work on one of the bugs that the team had to solve. We started with one that was less complicated that the others (even if on this project, all bugs are complicated).

We used the Attila Buturla’s mob timer and there we went, 5mns rotations. It was interesting to see that from the very beginning, the team members noticed some simple things about how each of them configures its coding environment, and rapidly began to exchange tips and tricks. When you mob, you really share the details, not just the big picture.

The teams members quickly got used to rotating on the keyboard. Even if Woody Zuill recommends using the strong-style pairing style, we did not get to it, because sometimes the person at the keyboard was the only one knowing what to do.

As I said before,  the bug we had to solve was quite complex, but we rapidly noticed that everyone could bring its own expertise to try to find a solution. At the end of the 3 hours sessions, the team did not solve the problem, but knew what documentation they had to look at to find the solution. As we had to leave the meeting room at the end of the 3-hours sessions, we decided that one of the team members would look at the documentation, and we would work again on the problem as a mob during the next session, which was scheduled two days later.

We made a short retro at the end of this first session, and one of the things that came up was that “it was fun”. The team had some doubts about whether it made them more productive than working alone, because they told me they already have great interactions throughout the day. We also decided that it is better to plan two half-day sessions in the same day so we really have time to solve a problem, and not stop in the middle. Or we can have two half-day sessions on two consecutive days.

Anyway, what stands out is that the team found that it was fun, and I think it’s really a good reason to continue the experiment. If we can make work fun,  it will certainly increase our motivation, and hence make us work better. It’s as simple as that. I am pretty sure that we cannot scientifically measure if we are more productive with mob programming, at least not after the first sessions, but if we can notice that we work better as a team, it is a very good reason to keep on doing it. Next mob programming sessions are coming next week, I will continue to share our experiences in the next blog posts.

The blame culture can destroy a team

I had the great pleasure to be interviewed on March 2015 by Vasco Duarte for the Scrum Master Toolbox Podcast.

There were 5 episodes, on five different topics.

One of them was about how the blame culture can destroy a team.

You can listen to it on this link :

http://www.scrum-master-toolbox.com/2015/03/podcast/nicolas-umiastowski-blame-culture-can-destroy-team/

Don’t hesitate to leave a comment on this episode, I would be glad to hear your onw thoughts about this unfortunately common topic.

Retrospective dialogue sheet in use

I want to share with you my first experience using a retrospective dialogue sheet (the sheet was made by Allan Kelly, I just translated it in French).

Dialogue sheet at the end of the retrospective

Dialogue sheet at the end of the retrospective

 

Context : I begin 3 weeks ago coaching a web developement team in a French well known mutual health insurance company. The team (and the company) are completely new to Agile.

The manager of the service decided some month ago to “go agile”. It started with another team, who embarked an Agile coach to guide them. The team I am just starting to coach has already begun to borrow some Agile practices, but I would say that for the moment, besides the use of a Scrum board and sticky notes, they are not yet agile.

But, and that is the most important, the spirit is already there : solid team, skilled team members, eager to learn more about Agile, and already producing high quality software.

I had attended their last sprint retrospectiwe, which was quite nice, but I thought I had to show them something else.

As they had just finished the first release of a  project, I decided we could make a release retrospective.

So I translated the T1 retrospective dialogue sheet, printed it in A1 format for 8 euros at one printer in the town where I live, took the sheet with me in the train, and met with the team the next day (I coach them 2 days per week).

The crew was  : 

The 3 developers, the scrum master, me, and the would-be new product owner (the current one was not really the adequate person, we thought it was time for a change).

The whole team sat around a round table, I put the sheet on the table, explained very briefly the purpose and the rules, and there we go !

I was sitting very close to them. I decide to stay during this retrospective for several reasons :

  • I had to learn more about their context
  • I was curious to see how it would work , and what I could improve to facilitate such a retrospective
  • I thought I could guide and facilitate a little this retrospective, because they have to learn agile, and solve important impediments (find an empowered and available product owner being the most important).

What was fine : 

  • They learned very rapidly how to use the sheet, how to read the questions in turns.
  • Everybody felt concerned.
  • They took it very seriously: it looks like a game, but people are not playing, they really work.
  • Some who usually do not speak much were forced to speak because each one has to speak in turns.
  • It was interesting to see them fill the important events on the timeline, trying to remember precisely the launch date, the date of the first stress test, the first demo, the date where the first worries about performance appeared, the time when they solved those problems.

Interestingly, they turned to me at one moment to ask if the start date should be the date when the proper programming started, or the date when they first started working on the POC. That was interesting to notice that they wondered if they were doing it right,  and asked me what to do. I told them : do as you feel. So they decided collectively. Interesting how people always think about rules, what to do and what not to do….

They decided that the retrospective should last 1:15 hour. It lasted much more (2:30) but there is a very good reason for that. When we got to the point of “list the main things to do differently”, I jumped to the board, and started a root-cause analysis diagram, to find the cause of the main impediments that they had listed during this retrospective :

  • difficulty to track wat was still to be done druing the release
  • no real product owner
  • too much testing at the end

By doing the root cause analysis, we quickly decided what to do differenlty, what to improve, but we were focusing on the root cause and not just the symptoms.

  • People liked to use different colours to write on the board.
  • The discussion was calm, everybody spoke, everybody felt concerned, and they spontaneously decided when to go to the next question on the sheet.

What to improve : 

  • I should have displayed the countdown timer on a big computer screen visible by everyone. In fact one person was using her iPhone countdown timer, so he was the only one to see it, and did not check very often.
  • The team agreed that in addition to timeboxing the whole sheet, it would have been good to timebox each question. That is the case in other timesheets, we just have to do the same on this one.

What to try

Perhaps next time I will leave the room and leave the team completely alone during the retrospective, so that there is not that censor type of person. Perhaps the discussion will be more “intimate”.

Conclusion 

At the end of this retrospective the whole team agreed that they should use this dialogue sheet again!

 

Dialogue sheet at the end of the retrospective

Dialogue sheet at the end of the retrospective