Card Storming Workshops - Magnetic-dry-wipe System Cards

2008-07-07T16:03:00.004+10:00

Card Storming using System/Index cards is a common technique used in workshops, for generating and prioritsing ideas from a group of attendees. This can be part of requirements gathering, issues/risks logging, or part of an exercise in a retrospective or futurespective.

Usually the facilitator passes out cards to the workshop participants & asks them to dump as many ideas as possible (one idea per card) in big writing (using marker pens) into the centre of a table in a timebox (say 5 mins). The group then deletes duplicates and groups cards carrying a common theme together and/or prioritises them.

They can be difficult to see over a large table, or they're difficult to prioritise if blu-tacked to a wall. Also, over time, this can burn a lot of trees.

Enter magnetic, dry-wipe system cards (worldwide patent applied for) - the system cards have a magnetic strip around the back and are laminated in clear plastic. See below. Just make sure you don't use permanent marker pens – Doh!

You can order a box of 100 for only 1 billion dollars from sprintst1@hotmail.com - or go make your own – I only ask that you credit me with the invention when you use them. ;-)

Adhesive magnetic tape on rear surface (prior to lamination):

Implementing Agile Organisational Change

2008-02-20T13:58:00.003+11:00

Having had many conversations with people wanting tips and tricks for implementing Agile organisational change, so here's a start list...
a. You must of course get a strong sponsor – make sure they regularly stress the value & importance of the process and staff support of it.
b. Finding appropriate Agile pilot projects helps – it should be big enough to be important, but not so big that problems are all blamed on "evil Agile". Also, the project should make use of modern technology ie. CI, automated testing etc.
c. Get everyone on the same page – they must have a shared understanding about what Agile is – so training/brown bag seminars/workshops etc. for all levels of staff helps. The fully detailed/materials workshop I often use (by Nayima & Tryx) is here http://www.xp.be/xpgame/download.html
d. People should expect that the change will be difficult – implementing Agile organizational change while running a project is like maintaining an aircraft while it’s in flight. If it was easy they wouldn't feel good about making it a success. There will be bad times - but remember - battle scars are good - they give you something to tell your grandchildren about.
e. Avoid comparisons with the company's old way of doing things – it’s not a fair comparison – the organization should run at least 3 or 4 Agile projects before comparing any metrics with the good old days.
f. It’s difficult for staff not to buy into a process when features of it are their idea – so in workshops, encourage people to contribute ideas on how to best make Agile work for them, then staff feel praised when their idea (investment) becomes a publicized/used part of the process.
g. Finally, from the dirty tricks department: One of the problems with organizational change is that many client staff feel it’s their sworn professional duty to reject change & reject the consultants, at least via passive resistance (and often active). 2a. above helps combat this, but if you can get agreement from client management/HR (whoever) then individual performance targets can be set in terms of
i. personal learning about Agile
ii. proven Agile expertise & experience, &
iii. tangible individual work to assure success of Agile projects
This makes it not just the sworn duty of staff to support and make a success of the process, but also they personally gain (or not) by meeting their performance targets (or not).

Alice Through the Retrospectoscope

2007-12-12T14:29:00.000+11:00

“Alice Through The Retrospectoscope”, or

Everything You Always Wanted to Know About Retrospectives – But Were Afraid to Ask”.

I'm often asked for a copy of these crib sheet notes, which were a synopsis of excellent work done by Kerth, Derby & Larsen (see references), plus ideas and work done with awesome colleagues at ThoughtWorks over the last few years.

1 Purpose

What’s the purpose of having a retrospective? It should be:

Informative – Communicate “the story” to all
Enlightening – Capture data, metrics or collective wisdom gained from the project
Progressive – Improve process/management/culture
Cathartic – Repair damage to the team or allow the team to enjoy what’s been accomplished

2 Plan

2.1 Set the expectation

Sponsor speaks – to impress on all attendees the importance of the retrospective
Everyone introduces themselves/comfort/expectations/objectives for the retro
Kerth’s Prime Directive encourages attendees that this is not about blame/criticism:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

Note: be wary that not everyone will be happy with this -- a person said to me once that they genuinely did NOT believe that everyone on the project did the best job they could! So care on this...

Ground rules are established to help people feel safe in contributing:

We’ll try not to interrupt
We’ll accept everyone’s opinion without judgement
We’ll talk from our own perspective & not speak for anyone else
We’ll listen to everything someone has to say before developing a response
We’ll decide before speaking that it’s important enough to share at this time
We’ll not joke about anyone in the room
All participation in the retrospective is optional
Mobile phones switched to silent
Ground rules can be amended after any break

2.2 Safety & Motivation – ESVP

A useful initial “temperature check” – ask attendees to rank how they feel (anonymously) on the graph below, first in terms of Safety (how safe they feel about talking about aspects of the project), and then Motivation (how they feel about attending the retrospective itself. For Safety, the scale is:

5. Hey, no problem, I’ll say anything, about the project, or beyond it.
4. I’ll say most anything, but a few things might be hard to say.
3. I’ll share some things, but keep a few things to myself.
2. I’m not going to say much & will mostly let others bring up issues.
1. I’ll smile, claim everything’s great, agree with what the managers say,
but not say what I really think.

On the Motivation scale,

Explorer – Discovering new ideas & insights, pushing boundaries, keen to learn
Shopper – Looks over available info, happy to “go home” with a useful idea
Vacationer – Not really interested in this process, but might enjoy it anyway
Prisoner – Feel more/less forced to attend & could/should be doing something else

2.3 Timeline

- Build a timeline on whiteboards/butcher paper of the project calendar. Mark the project start and end dates, plus major milestones, ends of phases etc. (yellow). If there was high turnover through a project it can be useful to add names of those joining/leaving the project.
Ask attendees to mark cards with memorable events when they felt (green) positive, or (pink) negative. Then ask attendees to graph how they felt overall through the project as time progressed, using a single marker line. The facilitator may create a subjective “trend” line which they evaluate as the overall average line representing the project.

2.4 Capture Data

Having established rules, safety, motivation and reminded all of the events/feelings through the timeline of the project the facilitator can run the main exercise, asking attendees to write comments on cards, or direct on whiteboards in different respects – the Common Questions are:

What worked well?
What should we do differently next time?
What still puzzles us?

It is also useful to group cards together if they cover similar topics.

These can be on flip charts around the room, & attendees can “cycle” around to reduce “cramming” in one place.

Another alternative to the 2x2 matrix is the Retrospective Starfish

http://www.thekua.com/rant/?p=370

2.5 Vote On Priority

The facilitator can then ask the group for clarification of the meaning behind the comments where necessary (respecting anonymity as always), asking attendees to put a vote against the top few items they consider most important (using counters or “ones”).

We briefly celebrate the things “What worked well”, then move onto the “What should we do differently next time?”

2.6 Drill Down And Action

Drill down into the top priority “What should we do differently next time?” cards. Discuss as a group each card, and capture actions to resolve the issue. Assign one person to each action.

From the items with the highest number of votes, the workshop group can be split into teams (eg. team per table), and the items distributed (one or two per table), to “drill down” into each item to identify options for a way forward/solution for each.

MOST IMPORTANT OF ALL – ensure attendees “sign-up” to action items (stories) which must be taken forward. In this manner, all the learning from the retro has a responsible owner, and will be actioned, so the learning is incorporated into future work.

2.7 End

Give a final summary, of all the charts and actions.

Thank everyone for their input and confirm how the collateral produced from the retro will be handled, eg. Take high resolution (7megapixel) digital photos of all charts & distribute to attendees.

If appropriate, ask everyone to stand in a tight circle, and quarter turn clockwise – give the person in front of you a pat on the back.

Close the retro.

2.8 Quick retrospectives can be done (eg. on a daily basis) in 15 minutes by asking a team to write on green (good points), red (bad points) and yellow (questions) post-it notes their reflections from the day's work. The facilitator (a different team member each day) collects the notes & groups them on a whiteboard, and reads through them. The group then vote on which should be discussed/evaluated (three marks each).

2.9 Futurespectives
These work well when helping a group envision a way forward from the current situation. Each team member is asked to write a "Post Card from the Future". The scenario is that things have gone great & each person writes a post card from the future to describe how great things are. You then vote on the post cards and split the group into sub-groups to generate roadmaps/plans on how best to achieve the status on the popular cards.

3 Other Considerations

3.1 Attendees

Availability

Role/Department/Company representation

Focus – more on the past? More on the future? Equally balanced?

Style of the retrospective – suiting it to the culture

Model the community – eg. organizational structure to understand departments/roles/relationships

3.2 Facilitator

A facilitator should be technically competent, with experience of a variety of systems development projects, and have good facilitation skills. Someone external to the organisation and project is ideal, as they will be unbiased, and not hampered by relationships, preconceptions, politics or history.

3.3 Preparation

Precursors

Expectations – a retrospective briefing sheet should be sent to all attendees, to clearly identify purpose, location, timings, facilitator, responsibilities, expectations etc.
Interviews – it’s important for the facilitator to know something of those who are to attend in advance, to set the scene for the retrospective, understand perspectives etc.
Data

Targets vs. Actuals (original targets/risks, actual quality/cost/time/scope/staffing/issues)
Metrics (iteration velocity, test coverage, build breaks, defects)

Artifacts – outputs from the project, deliverables etc.

Length

Should reflect the period of effort concerned, eg.

1-2 Weeks work – 1hr retrospective

6 Month project – 3 day retrospective

Location (see also Equipment below)

This should be a room dedicated to the retrospective for the period of the workshops, ideally lockable, to allow equipment/materials and personal effects to remain undisturbed.

Appropriate size for the number of attendees, with easily movable work tables and chairs – “Cabaret” style layout works well, with 4-6 people per table.

3.4 Equipment

Whiteboard marker pens (what works well is red for problems, green for good things, black for points of information, blue for neutral communication), one per attendee ideally.
Flip charts (paper with wall adhesive backing is good, static plastic erasable is great too)
White boards
Name tags (pin on ideally, as stickers soon fall off)
Digital camera (ideally 5megapixel minimum)
Laptop with presentation/spreadsheet software
Computer projector
Colour printer
Electrical extension cables with one-to-many sockets

4 References

Kerth, Norman L.
Project Retrospectives: a handbook for team reviews ISBN 0-932633-44-7

Derby, Esther & Larsen, Diana
Agile Retrospectives ISBN 0-9776166-4-9

http://www.retrospectives.com/

http://www.thekua.com/rant/?p=370 Retrospective Starfish

Mike McLaughlin