Agile Coaching

Human-powered methodology

I like the subtitle of Alistair Cockburn's book on Crystal Clear - a "human-powered methodology for small teams". Of course, all methodologies are human constructions but the majority do not focus on the humans who will be running inside the development process. Instead, methodologies have focussed on extracting knowledge from humans into artifacts and mapping out the optimal journey of these artifacts through the organization. The power of agile software development is that it recognizes the value of direct human to human communication over indirect communication (via artifacts or technology). The Agile Manifesto values "Individuals and interactions over processes and tools". I would argue that agile software development is a more humane way to develop software because it values humans and their uniqueness over the standardization of artifacts. The quality of human communication is important because this will be reflected back into the software developed by the team ( see Conway's Law). In a team that is trying too hard to follow rules, the resulting code is unnecessarily tight and formal. Unresolved design disputes will play out in the code too. When working in a team that implemented XP practices in a rule-based way, I have to admit that working in an extreme collective sometimes left me feeling like I was participating in some weird social experiment - this was fascinating and fun but constant pair programming sometimes became a daily grind that left team members feeling vulnerable and drained. My take on the Crystal methods is that Alistair encourages us to hang loose and trust our own judgement on what will work for us rather than religiously following a set of rules. XP used to take a more prescriptive line on implementing all the practices. In the second edition of XP Explained, Kent Beck has added Respect to the four existing values - Communication, Feedback, Simplicity and Courage. The new XP takes a softer line on implementation that places more respect on the individuals involved. In a discussion list today, Kent talked about the possibility of changing the name of XP someday to Test Driven Development. I think it would be a sad day to lose the Extreme part of the name but I have learned that being extreme all the time is tough and that it is important to recognize and make space for our individuality when developing software.

Planning Workspace

If you are organizing a meeting then don't just book any old room. First, consider whether the space that you plan to use is appropriate and has the facilities you will need. In an XP Planning Game, you will be writing stories and tasks on index cards and should provide an appropriate surface for spreading them out on, such as a table. One of my clients, Egg, provided each team with a 'project space'. These spaces were bounded by temporary walls made of translucent poly-carbonate sheeting and equipped with bean-bags, flip-charts, white-boards. These rooms were owned by the project team and did not need to be electronically booked. These spaces were great for daily stand-ups and retrospectives. However, many teams tried to use these spaces for planning games which often resulted in the team scrabbling around on all fours around index cards spread out on the floor or mounting them up on the wall with sticky-tack thus losing the mobility offered by cards on a table (and occasionally toppling the temporary wall). Other clients have gone to the other extreme and booked rooms with a massive table (15ft or 5m long). Again this makes it hard for the majority of the team to see the index cards! My recommendation is to use the smallest table that the whole team can comfortably sit around when estimating stories and to move chairs back and stand when prioritizing stories for the next iteration cycle. For large teams, consider scaling-up by writing the story in block capitals on a printing white-board and using the A4 printouts as ultra-large index cards. An alternative is to create a sticky wall that makes it easy to rearrange cards on the wall. If you use the wall in this way then you may get rid of the table (which now becomes an obstacle) and arrange chairs in a U-shape around the wall.

Variations on the Daily Stand-up

Daily Stand-up meetings are used by eXtreme Programming (XP) teams as a simple way to support communication and feedback. These daily meetings synchronize development activity with the current plan and can also help team building. Although daily stand-up meetings were held on the C3 project, the Daily Stand-up was not listed as one of the twelve XP practices, stand-ups only gets a passing mention in "XP Explained", with no information on how to run one until "Planning XP". Other agile software development methods have similar meetings: Daily Scrum in Scrum, Morning Roll-call in FDD and Daily Wash-up in DSDM. In the PLoP4 book, SCRUM is presented as a pattern language and emphasis is placed on the role of the SCRUM meeting as a ritual that socializes of status, issues and plans across the team. In "XP Applied" Ken Auer and Roy Miller make the following comment "the need for stand-up meetings is not as explicit as it should be in the XP literature". I have to agree - they are simple to implement and provide a real reflection of how well the team is progressing. I have no personal experience of DSDM or FDD but I thought it might be interesting to describe how I have seen the practice of holding a daily stand-up meeting evolve as this shows some inter-play between two agile methods, XP and Scrum. In 2000, I joined my first XP team at Connextra as a Java developer. At Connextra, we held a company stand up meeting every Monday morning - attended by all employees - from support staff to company founders. The meeting was lead by one of the directors with an update on company news followed by a status report from Sales, Dev, Support, etc. If anyone had been on holiday they were obliged to present a "Tacky Gift" at the end of this company meeting. When I joined the company, there were two development teams and they each held their own daily stand-up meeting at 9:30am. These stand-up meetings were held around a Planning Board where the stories written on index cards for the current iteration were pinned. The structure of the Dev stand-ups was pretty informal, we talked about any stories in progress, checked off any stories that were complete and allocated pairs for the day. Whilst at Connextra I read "Agile Software Development with Scrum" by Ken Schwaber and Mike Beedle. The tips for running Daily Scrum meetings sounded like they would give our XP stand-up meetings more focus. Also, there is no mention of referring to sprint backlog or burndown chart in the meeting. During the couple of years I worked at Connextra, the way that we ran the stand-up evolved. Every month we held a retrospective and used this as a mechanism to fine-tune our development process. Problems that cropped up were time wasted in gaining enough critical mass to start the stand-up, late-comers, poorly presented information radiators, silent lurkers, too much information and central control. Since then, in my work as an independent agile coach, I have seen the same problems and others occur in other teams. Jason Yip's paper lists some smells. If you want to see just how out of hand things can get then try out Bill Wake's simulation Second Agenda! When you think about it there are several variables. What gets talked about? In Scrum, each person is asked three questions: "What have you done since last meeting?" "What blocks got in the way since last meeting?" "What will you do between now and next meeting?" This format resonated with me because it was similar to the way I had run weekly team meetings on non-XP projects. I found it more productive to ask each person these question in turn and for the whole team to hear the answers rather than collate the answers myself in one to one chats and produce a status report. This three question format works well for XP stand-ups, the only adjustment required is that developers, who were pair programming together, do not repeat items that have already been covered by their pair. In large teams, exceeding twelve developers it may give the meeting more focus to talk about each story in turn rather than run round-robin around the circle. If you do this then be on the look out for individuals who have not worked on any story. It can be tough to get the bandwidth right. Some developers have the habit of being too brief and their report says nothing "I was working on story X".; whereas others give too much detail. The team needs to talk about the significant details of their work but sometimes a detail can have significance without the speaker realizing. I think it is important for people around the circle to be allowed to ask clarifying questions during the stand-up rather than postponing all discussion to after the meeting. Who should attend? At the Daily Scrum meeting, tasks are scheduled for everyone on the team working towards the Sprint Goal not just developers. Scrum categorizes attendees who are not commited to the Sprint Goal as Chickens. Chickens can attend (standing outside the circle) but not talk. In XP it is not clear if the On-site Customer should attend these meetings. The XP literature focuses on the software development part of a project and has very little to say about practices for the On-Site Customer. At Connextra, we had a Customer team rather than a single customer. Each member of this team gave a progress report on their activities every Monday at the company stand-up. Members of the Customer team were welcome to attend the developers standup to get an update on progress of their stories. Once we had an increasing number of users for our products we introduced a separate Customer team stand-up to set priorities for the day on Support tasks. One smell that I have observed in organizations where customer attends the daily stand-up is that some developers save up questions for their customer until the stand-up. If a team member (developer, customer, manager) is working at another site or from home they may dial in via a speaker phone. This means there is some setup to do before the meeting and remote team players may not pick up everything that is said. I have occasionally witnessed the team exchanging silent humor (such as eye-rolling and gestures) in these situations. Who runs the stand-up? In some teams, stand-ups are run by the team leader or coach. When I am coaching a team, I may run the first couple of stand-ups to demonstrate how but prefer that the team lead or project manager takes on this role, as this reinforces that leadership is bought-in to the new process. In the long term, having a single person who is responsible for running stand-ups can create an unnecessary dependency. If that person is late or out of the office then the responsibility has to be delegated to someone else. At Connextra, we formed a U-shape around the Planning board. The meeting would be run clockwise or anti-clockwise by one of the developers standing at either end of the U. When does it start? The meeting should start at strictly the same time every day. Choose a time that works for everyone and start on time without waiting for stragglers. It can help to book a recurring meeting in electronic calendars to avoid people getting double-booked. Most teams choose to start the day with a stand-up as this means no development is interrupted by the meeting. If people do not work the same core hours then an alternative is running the stand-up after lunch or at the end of the day. This can also be a good way to break pairs up who are used to working late or thru lunch. Ken Schwaber suggests a that late-comers are fined and money collected goes to charity. I do not think this works, the late-comer can then get a warm charitable feeling each time they are late. If people do not realize the scale of the problem then track lateness on a Big Visible Chart. Should the plan be visible? Although a circle is the usual arrangement in Scrum, I prefer a U-shaped huddle around the plan, as this saves some head-scratching as people struggle to remember what story they were working on. It is worth taking care to present your plan so that it can be read from a distance. Use a marker to write story title in block capitals. Use colored stickies to show what stories are in progress or done. Consider information radiators such as burn-down charts for your shared workspace, the stand-up can be a good time to remind the team of their current commitments. Create a parking lot for issues raised (on a whiteboard or using post-its) and make sure this is reviewed at the end of the stand-up meeting. Always standing up? As a coach, I try to set an example by standing up rather than propping myself up against the furniture. Where the space that you hold stand-ups in contains desks/stools/beanbags it's always tempting for the people who show up first to sit down and this can set a precedent for everyone else who enters the room. If this results in a slow running meeting then comment on elapsed time and clear furniture to the side of the room before the meeting. In extreme cases use a kitchen timer. I have encountered circumstances where sitting down is OK. One such situation is where one team member is uncomfortable standing, maybe suffering from back injury or expecting a baby, in this case I prefer everyone to sit. This also makes sense if the team was out drinking the night before and everyone is hung-over. Another situation where it seemed sensible to sit, was a team with a high number of in-sourced team members and a mountain of legacy issues that needed a half-hour team meeting every day. Scrum was originally described as a sit-down meeting. If you have a distributed team then a Scrum by audio-conference is likely to take longer and it may help to have people seated around a conference phone on a table rather than standing around a phone on the floor. I have even encountered a team who felt too embarrassed to stand for the meeting as it felt too american. As a coach, I do not play an enforcing role, instead I explain likely effects of their decision and keep giving feedback on ways to improve team dynamics. I hope these tips are useful to those of you implementing daily stand-up meetings. All too often we concentrate on the differences between agile software development methods rather than the common ground.

New Year Resolutions

It is traditional to make Resolutions on New Years Day. Typically, people resolve to to reform their behavior such as giving up alcohol or tobacco. I wonder if applying will power is really an effective way to create change? Consider getting to the root of problems that may be causing stress. I do not usually make any New Year Resolutions. I am not fond of absolute targets or rules, circumstances change and I am all too happy to give myself permission not to feel guilty breaking rules set by myself. The turn of the year is a good time to look back over the past year and reflect on what I learned and where I would like to go next. Last year I had heavy work commitments - I spent too much time in front of a computer and traveling. In 2005, I would like to strike a better work life balance. I plan to spend some time at home working on my writing. I hope to make a start by building a "writing hour" into my day with the goal of getting some articles in print this year. The great outdoors is also beckoning - in the spring I plan to take a week off to walk part of Offa's Dyke. I am also thinking about taking up some other pursuits such as T'ai Chi and the mandolin. I made a start today by visiting the bookstore today ;-)