The results

Thanks to all the people that came along to the workshop. I had a great time and I was amazed by how many different behaviours everyone could come up with as a group. I promised to post the results, so here they all are (as a single page). I probably should migrate them to a better format, but here’s the initial step. If you have any suggestions on a better way of formatting them, please leave a comment or email me. Here are the different classifications the groups came up with for the seven different practices we could cover.

The presentation is made available through here. (PDFed as it’s smaller than the original).

The Practice: Continuous Integration

Novice

• Shutdown automated build
• Ignores build failure
• Manually integrates
• Checks in code and leaves before “green”
• “Removes feedback” from build machine
• Checks-in, in spite of broken build

Advanced Beginner

• Has an automated build
• Using a check-in token

Competent

• Checks in code relatively often
• Runs the build locally prior to checkin

Proficient

• Integration includes automated tests

Expert

• Stop the line on failure
• Nursing build machine
• Creates automated builds

Practice: Using user stories
Practice: Using User Stories

Novice

• Uses index cards
• Uses story template
• User stories have some estimates
• Trying to complete too many stories per sprint
• Everyone on team picks a user story to implement

Advanced Beginner

• Team members write a user story together
• Product owner clarifies stories at meeting
• Using storyboard
• Estimation of user stories is relative and quick
• Write name/title for story rather than reference number
• Defining stories as slices of customer functionality (rather than technical chunks)
• No one thought how to demo story
• Talks to customer/product owner
• Preparing user stories before whole team meeting

Competent

• Combining stories
• Consistent layout for story cards, “e.g. estimate in corner…”
• User stories are delivered throughout the sprint
• Noticing user stories epics and split
• INVEST criteria used in evaluating stories
• Identify technical risky stories to customer
• Identify tasks for a story
• Not turning down stories that need to be further investigate

Proficient

• Splitting user stories well (small sized slices)
• Doesn’t focus on “writing” stories
• Estimating value on stories
• Product owner/team regularly grooms backlog (allowing time)
• Adding additional analysis use cases + business rules if it helps
• Questioning user stories

Expert

• Doesn’t need story template any more
• Questioning if story is done
• Using personas or stakeholder maps to look for missing stories

Practice: Updating storywall

Novice

• Never moves items on the wall
• Only 1 person updates the wall
• Avoiding some items on the board
• Command others to take a task
• Waits for someone to tell what to do next

Advanced Beginner

• Running stand up around the wall
• Picking up the next task from prioritised list
• Actively goes to wall to get next task/story

Competent

• The team goes to the wall and updates freely during the day
• Suggest new task to be added
• Raises bottlenecks
• Flagging blockers
• Brings discussions focused on items on the wall

Proficient

• Changing the story wall based on process changes
• Picking up tasks from other “stages” when noticing bottlenecks
• Adding limits to “stages” to control WIP

Expert (none listed)

Practice: Participating in Retrospectives
The Practice: Participating in Retrospectives

Novice

• Shows up
• Doesn’t know what to write on sticky notes
• Identify what you liked/thought went good
• Identify what did not go so well, or went poorly
• Ignoring others
• Respects format and timeslot
• Yelling at others
• Talks all the time
• Doesn’t really care
• Always covers up / Avoids conflict
• Just listens
• Not raising issues
• Blaming problems to something outside the team’s control/influence
• Not discussing/raising actions to actually change/improve the process

Advanced Beginner

• Suggests ideas for team to try
• Raises issues they are concerned about
• Identify what went well or not so well *for everyone* (not just individual perspective)
• Write action items
• Discuss actions to take
• Brainstorm, “What went less well?”
• Brainstorm, “What went well?”
• Doesn’t disrupt others
• Listens to others
• Ensures all members participate
• Feel a need to keep all stickies “as documentation”

Competent

• Prioritise most important action items
• Prioritise what to discuss
• Asks what happened to actions
• Well prepared
• Follows up previous meeting
• Facilitates
• Identify and understand the “mood” of the team
• Records actions
• Plays the devils’ advocate
• Signs up for actions
• Is honest about issues/doesn’t hide problems
• Discusses events/issues without blame
• Does pre-work
• Brings calendar (to remind them of what events occurred)

Proficient

• Dares to present crazy ideas
• Encourages others to speak
• Comparisons of past retrospectives
• Shows appreciation for others
• Follows up others with their actions
• Offers appreciations
• Reminds participants of ground rules when deviating
• Comparisons of past retrospectives
• Shows reflection on how things have progressed *over time* and shares ideas for future
• Identifies categories of patterns
• Moderator running/facilitating the meetings
• Ownership of action items

Expert

• Asks how improvements will be measured
• Suggests retrospective on retrospective
• Guerrilla facilitating
• Suggests changes for retrospectives
• Suggests improvements or new ideas for what could work in retrospectives
• Suggest appreciative inquiry

Practice: Facilitating Retrospectives
The Practice: Facilitating Retrospectives

Novice

• Creates an agenda
• Books appropriate room and puts appointment in the calendar
• Just asks for good or bad

Advanced Beginner

• Not skipping retrospectives
• Prioritises actions
• Introduces the prime directive / ground rules
• Brings materials (stickies and pens)
• Ensure last (sprint completed)?
• Setting the stage
• Prepares room and seating arrangement
• Sticks to times in agenda
• Ensure everybody understands the purpose (not blame, did as well as possible given the circumstances)

Competent

• Uses different formats
• Focused retrospectives
• Checks with participants if outputs can be shared outside the team
• Checks with participants before writing up
• Ensures the team tries to “fix” their own problems
• Writes flipcharts legibly and well-presented
• Prepare some data (gather some data)
• Introducing the speaking token
• Follow up on last retrospective

Proficient

• Raise issues team is avoiding
• Explains if stepping out of facilitator role
• People looking forward to retrospective!
• Actions set completed
• Varies exercises in retrospective to accommodate introvert/expert
• Participate and facilitate

Expert

• Prepares team to agree how actions will be measured
• Inviting a guest facilitator
• Facilitates big release retrospective with pre work & broader audience
• Rotating the facilitatorship within the group

Practice: Pair Programming
Novice

• Passive when not at keyboard
• Hogs the keyboard

Advanced Beginner

• Active when not at the keyboard
• Switching keyboard between people in pair

Competent

• Mix pair programming with other practices (e.g. TDD)
• Rotates pair
• Pushes over keyboard to partner
• Suggests pairing

Proficient

• Respects the partner’s views
• Notices partner’s mood
• Recognises that there are different personalities
• Answers questions

Expert

• Questions why pair programming is not good in a particular situation
• Knowing when *not* to do pair programming
• Handles different skill levels
• Handles different motivation levels
• Adapts to different partners

Practice: Agile Estimation
Novice

• Over estimating to protect
• Too optimistic on estimates
• Estimating using hours
• Gaming the numbers
• 1 person estimates alone
• Trying to influence other’s estimates

Advanced Beginner

• Discuss details about story

Competent

• Encouraging re-estimation and more discussion when initial estimate range is too wide
• Encourage discussions when members differ too much
• Estimation as a group effort
• Request more information from the Product Owner

Proficient

• Raising “un-estimatable” stores to avoid assigning a random “big” size
• Knowing when to stop estimation process
• Bringing historical data to estimation process
• Avoid over-discussing one time
• Raising a need for a story to use as reference for comparison

Expert

• Raising questions/improvements about estimation process
• Avoid estimating too far in advance
• Do we need estimates?

Pre workshop Details

Tell me a bit about it

Adopting agile isn’t as simple as ticking practices off a known list and moving onto the next one. It takes some effort to simply start applying a practice, and even more effort to attain a certain level of mastery. Distinguishing between apprentice-like behaviours and master-like behaviours is an important element of pushing the boundaries of a practice even more.

This workshop will introduce learning models (focusing on the Dreyfus Model of Skill Acquisition) and map behaviours we see of agile practices to the model. We will spend the majority of the session mapping behaviours we see to the stages, and discuss how people can use this model as a tool to help people progress to further levels of mastery within a particular practice.

What to expect?

Don’t worry. It’s not just going to be a lecture. 2 hours is a long time without an interactive part. I believe in lots of experiential learning and sharing with other people, so the workshop is designed with that in mind. We will have to make sure we have a common understanding of what theory before jumping in

Is it for me?

People most interested in learning, teaching and training organisations in agile methods will get a lot out of this session. This will probably include many types of coaches, people in leadership positions and any other people trying to transform an organisation into a more agile environment. I’d especially welcome people who have participated or observed agile teams as your experiences and stories will be invaluable to making this session rich and vibrant.

Wanna come along?

Everyone is welcome to participate although I’d like to keep the session to about 20 to 25 people. Contact me directly (details below) as I will give priority to those who contact me before the conference starts.

Get in touch with me

Email is best using the following address: emailpat@thekua.com. Remember that the first people to contact me will be given priority attendance if the workshop fills up. Please tell me what sort of role you are in, what you hope to get out of the session and any questions you may have. I hope that people have the right expectations before they take part.

Credits

I’d like to thank the coaches and training people in ThoughtWorks, particularly Elizabeth Keogh for the background work of this model and her continued passion for coaching.