Energized Work | agile in action: May 2006

Collaboration and Agile Teams

Here's a presentation I made the other day about Agile Teams. The presentation includes the following activities:

Create a poster about yourself based on your Myers-Briggs type and use this to introduce yourself to your team mates. (My poster is included in the presentation)

Using the information gained from the Motivation Exercise, tell your team mates what motivates and demotivates you.

Define and agree on the team norms. The team I made the presentation to selected the norms shown in the picture.

norms
Originally uploaded by sjb140470.

Tags: collaboration

Links to this post

0 Comments

Comfortable with 'emergence'

When employing Agile software development it's vital that everyone is comfortable with the reality that, over time, the requirements, the system and the team order will all emerge. Understandably, this makes a lot of people uncomfortable because they're trained to believe that the essence of a project is structured and largely predictable. They want to control the project using a plan that attempts to predict future events based on assumptions made up-front about the stability of the requirements, business landscape, team and estimates, and the accuracy of the information available.

By letting things emerge you're accepting the inherent uncertainty and instability in a project given the inadequacy of information available. By planning adaptively, you steer the project in response to new information that emerges through feedback, rather than controlling it based on predictions made in an up-front plan. The driving force is to deliver what is needed today based on what is known, and not to plan what you think is needed tomorrow based on what you think will happen in the future.

New and modified requirements emerge from feedback on earlier implementations, shifting business priorities and modified user needs. Using iterative and incremental development the final system emerges from progressive working increments that have been adapted to accommodate these changing requirements. Through self-organisation rather than hierarchical command and control, a team organisation and working order emerges based on common values, principles and practices, a shared vision, and intense collaboration with the customer. The team is empowered to decide how best to utilise resources, skills and technologies to best meet the requirements, deliver business value and maximise return on investment for the customer.

Trying to limit and control changes results in the delivery of a solution that is compromised by cost and does not meet the real needs of the customer exactly. Through feedback mechanisms, Agile software development is geared to respond to change ensuring that what is delivered is actually needed by the customer and not just what they thought they needed at the start of the project.

Tags: agile, adaptive planning

Links to this post

2 Comments

Better Builds With Maven

Better Builds With Maven: A free how-to guide on Maven2 and Continuum from Mergere.

Tags: continuous integration, ten-minute build

Links to this post

0 Comments

Value-based management

Deming's 14 Points of Management
Eight Attributes of Management Excellence by Tom Peters and Bob Waterman
Peter Senge's 5 Disciplines

Links to this post

0 Comments

Daily Stand-up / Scrum meeting

The daily stand-up meeting or scrum meeting presents the team with a regular opportunity to synchronise development activities with the iteration plan and to check and reflect on the progress of the team's commitments towards the iteration goal.

As a forum for communication and feedback, the team members co-ordinate their work and make a commitment to the team about what they aim to achieve in the day. They also identify any difficulties and obstacles to progress. The meeting is not intended to generate solutions nor remove obstacles. Making obstacles visible in this meeting raises awareness early, and allows team members to provide assistance and work collectively from the beginning. However, the meeting should not prevent issues and obstacles being raised at any other time.

Who attends the meeting

The chicken says to the pig, "Let's start a restaurant".
The pig thinks it over and replies, "What would we call this restaurant?"
The chicken says, "Ham n' eggs!"
The pig says, "No thanks, I'd be committed, but you'd only be involved!"

Only the pigs participate in the meeting. The pigs are people who have committed to the completion of the current iteration, i.e. developers, testers, and scrum master. The chickens are restricted to observing the proceedings. The chickens are people who have an interest in the iteration but are not committed to its completion, e.g. onsite customer or product owner, other stakeholders, management.

Start the meeting at the same time every day

It's important that the meeting starts at the same time every day. This helps the team feel like they own the meeting and their compulsory attendance helps them view the meeting as a habit. It also allows any interested observers to simply drop-in unannounced to get an update on progress.

I prefer to conduct the meeting as close to the start of the day as possible, at a time that works for everyone in the team. I see three benefits for doing this. First, the energy level generated by a well run stand-up conducted at pace invigorates the team, aligns everyone in the same direction, and provides an excellent impetus for jumping into the days development activities. Second, often developers do not use the time preceding the meeting to perform work that contributes to their goal for the day. Therefore, minimising the time preceding the meeting minimises waste. And third, once development has started it's not interrupted by the meeting occuring later.

Hold the meeting at the planning board

Have the team form a U-shaped huddle around the planning board so that the iteration's story cards are in plain view. The iteration plan displayed on the board is the driver for the team's work and reminds everyone of what needs to be done. The story cards provide a context for the listeners and visual cues for the speaker. Any information radiators or big visible charts, e.g. a burndown chart showing the progress made and the work remaining, should also be within view so they can be updated during the meeting. It's imperative everyone leaves the meeting with a clear understanding of what remains to be done in the iteration and the issues and obstacles raised.

Keep the meeting to a 15-minute duration

Keep the meeting to 15 minutes or less. Minds wander and focus is lost if the meeting continues beyond this time frame.

Kicking off the meeting

Require that all attendees stand up. Standing up ensures the meeting doesn't take too long and keeps everyone focused and engaged. Establish a consistent route around the huddle, in either a clockwise or an anti-clockwise direction, so that everyone always knows who's turn it is next. One of the developers standing at either end of the U-shape should kick-off the meeting.

Each team member answers 3 (unspoken) questions

In turn, each team member answers the following 3 (unspoken) questions:

What have you done since yesterday's meeting?
What are you going to get done today?
What obstacles do you need to be removed?

Any other useful information should also be shared with the team.

When answering these (unspoken) questions the team member should talk to the team and not to the scrum master and should reference the relevant story cards on the planning board to provide context. It takes practice to convey the right level of detail that is useful to the team. Providing the 15-minute duration of the meeting is safe guarded, clarifying questions can be accommodated, but long discussions should be postponed until after the meeting has concluded otherwise the meeting loses focus and people can become disinterested. Certainly, engaging in immediate problem-solving during the meeting should be avoided at all costs

The obstacles raised should be noted on an action plan together with an owner and timeframe for removal. It's the scrum master's responsibility to ensure the prompt removal of these obstacles. The action plan should be stuck to a wall in the team's workspace so that the obstacles are displayed publicly.

The story cards should be updated with the expended and remaining effort, and the burndown chart should reflect the latest progress.

At the end of the meeting, the team should choose the first pair programming partners for the day.

Facilitation notes for the scrum master

Every team member has a responsibility to prepare for the meeting. The meeting will run more smoothly if everyone knows the answers to the 3 (unspoken) questions.
Opening the meeting: Ensure the meeting starts on time. Don't wait for stragglers. The meeting is a whole team practice and is not for any individual. At the appointed time, ask are we ready to start the daily standup?
Ensure everyone is standing up at the start of the meeting and huddled around the planning board. Assume a position off to one side, where you can still view everything clearly, to ensure that the speaker does not direct his comments to you rather than to the team.
Let the team run their meeting but use an egg timer to time the meeting, keeping its duration to 15 minutes.
When answering the 3 (unspoken) questions, the team members should talk to the other team members and make reference to the planning board. Do not ask these questions of each team member, otherwise responses will be directed at you and not to the team (See Lasse Koskela's On Scrum and the curse of the three questions).
For the first (unspoken) question - 'What have you done since yesterday's meeting?' - keep each team member focused on the commitments they made during the last meeting and have them explain whether they met these commitments.
For the second (unspoken) question - 'What are you going to get done today?' - keep each team member focused on the commitments they are willing to make to the other team members for today.
For the third (unspoken) question - 'What obstacles do you need to be removed?' - write the obstacles on an action plan together with an owner and timeframe for removal.
Steer talkative team members away from story telling and help the team ask clarifying questions that reveal the right details. If further discussed is required, acknowledge it, and say 'take it offline' to remind the team of the meeting's purpose and that such discussions should be held after the meeting has finished.
Ensure each team member keeps their story cards up-to-date with respect to the effort expended and the effort remaining, and that their progress is recorded on the burndown chart.
Closing the meeting: Review any actions and obstacles resulting from the meeting.