Well hullo there! It has been quite some time since my last post. A lot has happened recently, some of which prevented me from posting regularly. Let’s just blame the current economic conditions for that.
Since my last post, we have pretty much finished our JavaFX project. I was at the NLJUG’s JFall where I hosted a JavaFX workshop all afternoon and I have been to Devoxx in Antwerp where I met Richard Bair and Jasper Potts from the Oracle JavaFX team.
I have also joined Stephen Chin in the maintenance of the Visage language. This is the continuation of the JavaFX Script language as an open source project (see Google Code).
Now shut it, you mentioned something about agile…
Yes I did. We have recently moved into a new engineering phase of a large project at work. We had previously used some agile concepts here, but never really moved into full blown Scrum or anything. This time we have, or rather, we are migrating to a real Scrum project setting.
So I thought it would be nice to share how we are currently moving to a more agile project. Although I think we are pretty late to actually fully embrace it, I’m sure there are still plenty of others out there struggling to go agile. I intend to chronicle the steps we took and discuss the ups and downs we perceived.
Today, the first step: standup meetings. The first thing we picked up (again) were the standup meetings every morning. This is probably the easiest piece of Agile/Scrum to incorporate into an existing team. It can however be hard for people to adjust to these meetings.
The first thing you need for a good standup is a leader. This should be a Scrum Master if you have one, or one of the team members who can maintain order. This is due to the first pitfall with taking up a standup meeting: taking too long.
The key to a good standup and a good feeling among your team is to really keep it short. Make it clear to everyone that they should only briefly answer these three questions:
- What have you achieved since the last meeting?
- What are you planning to do today?
- Is anything hindering you in those plans?
People initially tend to take a while explaining their answer to the first question. They may actually feel like they have to defend what they are doing. This is not true and such feelings should be countered as soon as possible. Make sure everyone understands that the goal is just to increase team communication and team spirit. If someone hears a colleague struggle with a problem that he is familiar with, he may be triggered to help. If someone hears a colleague work on something in which he is also interested, a nice discussion might come up. Just make sure the discussion takes place after the standup. This is where the leader should stop any deviations in their tracks and keep the standup going.
The second question also does not require long answers. If you can say it in one sentence, that will do, as long as everyone has an idea of what you will be working on. This is mostly just meant to make sure the whole team knows what is happening and to potentially spot conflicts. Although the answer to this question is somewhat a commitment to the team about what you will do, it should never be used against anyone. Heck, if something goes terribly wrong, or someone interrupts you, you can name those interruptions during the next standup. If required you can name those interruptions as your ‘problems’.
The third question is hardly ever answered with anything else than ‘no problems’. It is however a very important question. From time to time, something might actually be holding you back. It can be silly things like ‘we ran out of sugar’, to really serious issues like trouble at the homefront. If at all possible, the leader / scrum master should try to take these problems away. The power of the scrum master is obviously limited here, but offloading certain things can help you be more productive.
That’s it for now, next time I’ll write about taking up a rhythm by adopting sprints. If you have any questions or other experiences about standups, feel free to leave me a comment.