Agile Methods: Stand-up Meetings

Stand-up meetings are a very important part of Agile methodologies, Scrum in particular.

This article by Martin Fowler focus on the most important aspects that should be considered in the organization of this kind of meetings. In particular, those aspects that can turn them into a good or bad experience.

We at PRIMAVERA have a short history in applying these “techniques” in our development process. In the past, we used, without classifying them as such, meetings like these in very specific tasks where results could be easily measured. We did that to follow the work of specific task-forces, for example, developing particular features or during the stabilizing phase (where the progress of tests and bug fixing is an objective easy to evaluate).

I participated in several of these meetings, a good part of which in the role of what one could call the scrum-master. Some of those were positive and achieved the main objectives; however, I’ve always felt some discomfort regarding the “participating as peers” component that is expected from this kind of meetings.

Recently, in the final phase of the development of V7, I participated a few times – as chicken – in the daily meetings that the development team (leaded by my colleague Fernanda Queirós) organized. Participating as chicken was a choice. I was interested in participating as an observer so I could see better what worked well and what didn’t.

To understand my impressions it’s important to understand how the meetings – a kind of Scrum implementation lab – were organized. The meeting took place daily, before lunch, and assembled all the development team members. Given the project’s development phase, that team was focused in fixing the bugs detected by Quality Assurance. At times, depending on his agenda, the meeting would count with the presence of Carlos Morais, given his role as program manager. It’s important to also say that, during this phase of the project, the team involved changed both in participants and in number of participants (due to the fact that the team was reduced or increased according to other project needs). The main agenda topic was, as I said, analyzing the daily bug fixing efficiency (if you want, the list of remaining bugs was the backlog for the meeting).

I feel that I didn’t participate in as much of these meetings as I should to take more accurate conclusions. Anyhow, here are my impressions:

• It is very hard for the team to discern the scrum-master from the project manager when both roles are played by the same person. That leads to indirect communication between team members. There is communication from the master to all the team and from each member to the master. It’s harder to have communication between the team members.
• Goal sharing is harder because of that. You can feel that each team member is reporting “his objectives” to the master more than sharing other team members’ objectives.
• The characteristics of the phase of the project when they took place didn’t help the meetings. Bug fixing doesn’t raise many of the challenges – in terms of removing obstacles – which stand-ups are supposed to facilitate.
• I could feel sometimes that team members saw participating as an obligation. There is an “objectives report” aspect to this approach that may have resulted in that.

So the general impression is that we didn’t manage to achieve most of the major advantages of stand-up meetings. We will have to work on that in our following projects. I'm now confident that the secret is in creating the backlogs and manage/follow them in this kind of meetings. I also see the backlog as the end for that detailed project plan that has been the horror of my project management tasks these last years.

Simplifying further this way, one can believe that stand-up meetings will fit right into the development process, easily.

And that’s all for now regarding agile methods in the V7 development. I’ll get back to this subject matter in time when the new project, I’m starting now, advances.