A few years ago at AgileCoachCamp2010 Marc Bless walked around and asked people to give them a name of a book. just one book. He had one extra rule. The book could not be on his list yet. I stole that idea and recreated booklist with people at conferences like
The quiz was created by Sallyann and you can find her answers below.
1. Which of the following has Pair Programming as a core practice?
b. Extreme Programming. Although pairing is useful in any other the others is it only described as a Core Practice in XP.
2. When pair programming, the most regularly used names to distinguishing which person is currently typing are:
c. Driver and Navigator. Some say the Driver types, while the navigator looks at the broader problem / real world level. I (Sallyann) dispute this though
3. In Jim Coplien and Neil Harrison’s book “Organisational Patterns”, pair programming is referred to as:
c. Developing in pairs. Illustrated with a lovely ‘Two Amigos’ picture.
4. Pair programming has not been shown to have a helpful effect on:
b. Pair programming has actually been shown to lengthen the amount of effort required to develop a feature, however this is considered a cheap price to pay for the eventual time saved through not having to fix the extra defects found in solo-developed code.
1) When do you normally do a retrospective? b is the best answer, all others are wrong or do not reflect the real intention of a retro.
2) Who should attend the retrospective? a and c are both valid answers, this questions aims to trigger reaction if the PO should or should attend the retro.
3) What is the best way to do a retrospective? a
4) What happens with the actions that come out of retrospectives? b is the correct answer, e is not wrong but doesn’t emphasize enough that it is the team who takes action
One of the ways I am coaching companies, is that I offer what I call free mini agile training sessions.
These are brownbag sessions, something I learned from Linda & Mary Lynn great book: Fearless Change
Today these are 1 hour (optional) sessions for anyone in the company that wants to learn about agile.
Depending on how much time I spend at the company, I do them once a week or ever x weeks.
Sometimes they are workshops I am doing for a long time, sometimes they are try out’s of something new.
This is an example of a such a try out-session.
I show a picture of a kanban board similar to the one below:
(I took a different one, so I can keep mine for my exercise 😉 )
Scrum Board
I gave everyone post-its and a 5 to 10 minute timebox to write down what they saw.
Then everyone could present one post-it and in a round-robin way we went around the table. (After we have done one round, we turn again, until most people have no post-it’s left anymore.
Depending on how many idea’s there are, we look at all of them.
Every time a person presented a post-it. I asked everyone if it was a fact or an interpretation.
let me give you an example: – people are already working on the second story before the first is finished.
> actually the first lane is a priority lane, that is working with support tickets.
Ok, I admit that is hard to figure out from a picture that is not complete. let’s look at a next one.
– Alex is working on too many stuff.
mm the fact is, there are 3 post it’s with a small post it Alex on it.
In this case, the team leaves a post it in the WIP colum, untill the next stand up. Yet they do a blue Done sticky, when finished. Alex is actually only working on one thing.
by this time people start realize that seeing facts is really hard.
yet at the same time they do miss a lot of obvious facts. So obvious that we ignore them.
The board uses black tape to make the squares. this might seem trivial and not important, untill I tell you that this is the black team and the color of the tape is making the difference on the boards.
Other facts: some post it’s are yellow, others are green.
Extra:
When I did the tryout of this exercise, we had a team member joining this workshop rather late.
This turned out very fortunate, as I told this person the exercise and when he presented his post it’s, I asked the already present team members to replay the exercise with him.
It was very nice to see what they had already learned from the previous time.
When I tweeted about the exercise, I was reminded of the ladder of Inference
An adapted version of the exercise could be, to not only select fact or interpretation, yet to see if you can come up with post it’s for all 7 layers of the ladder. As a first exercise for team members that have to learn about the difference between fact and interpretations this was already cool.
I show this list of topics, to show that a small workshop that is only loosely facilitated, can bring up many interesting topics, where the students choose themselves in what they are interested in.
For me, the power of training from the back of the room
