Boring retrospectives – part 3

After some turbulent times in the course of our project, I felt it was time to take temperature of the team’s feelings about the state of the project.

I needed an exercise that invites people to share general feelings about the entire project. So I used a variant on the Art Gallery exercise, which I found on Pat Kua’s blog. It is called Mr Squiggle.

In the Art Gallery exercise, people draw an image that represents their feeling.

This is the idea behind the Mr Squiggle exercise:

“This exercise was inspired by the childhood TV show in Australia, of the same name (Mr Squiggle). Kids would literally send in a set of squiggles to the show to be put in front of a blackboard, where the main character, a puppet with a pencil on his nose, would turn them into complete drawings”

The difference between the Art Gallery exercise lies in the fact that we all start with the same basic drawing and extend it to represent our feeling.

We started with this basic sketch:

After everybody is finished, each person explains his drawing to the team. It was amazing how many similarities there were between the different drawings. I give you a few results:

 

“On our way to the jar of gold, we risk to get off-road”

  

“In the beginning, we made heavy progress. After a while, we hit a wall, which we’re starting to tear down now.”

 

“We move like a tortoise on our way to the finish. If we manage to find the bike, we could improve our speed a lot.”

Elaborating on the drawings exposes some issues that need our attention, and gets the team thinking for the next parts of the retrospective. As you probably noticed, our project is on a critical decision point. There is a slumbering risk that needs our attention, so we can assure that our train keeps running smoothly.

Scrum Gathering Munich – 10 Contract forms for your next agile project

In this session, Peter Stevens gave his view on 10 types of contracts for agile projects.

As the agile manifesto states ‘Customer collaboration over Contract negotiation’, contracts are still important when working with external suppliers. The right rules enhance the chance of success.  Contracts can lead to certain behaviors, so be sure to negotiate terms to get the right behaviors.

What should be in a contract? Peter suggested

• Objectives

• Outline of the project structure

• Key personnel (who is responsible at which level, and what are their tasks?)

• Payment and billing

• Early and normal termination

• Legal details

The audience added

• Deliverables

• Scope (for instance User stories

 

He explained some contract forms:

Time and Materials

Time and materials with variable scope and cost ceiling
Customer and vendor focus on achieving the desired business value within the budget. Risk exists that customer will end up with something that’s only partly finished.

Fixed Price Fixed scope

Time and materials with fixed scope and cost ceiling
The vendor only charges actual work. Project costs less when delivered earlier. If the cost ceiling is reached, it behaves as a fixed price contract. There’s no incentive for the vendor to deliver earlier, so he will try to hit the cost ceiling exactly.

Phased development
Chop the project into smaller releases. Funding is done per release, so vendor and supplier are committed to deliver each release in order to be able to fund the next one. Scope changes become new business goals for next releases prioritize by the product owner.

Fixed profit
Vendor works at an agreed profit margin until a certain cost ceiling after which he works at cost price. The customer can choose to back out after each sprint by paying a cancellation fee of the profit part of the remaining work. Both customer and vendor have an incentive to finish early.

Bonus / penalty clauses
The vendor receives a bonus if delivered ahead of schedule, and pays penalty if delivered behind schedule. Scope is most likely to be fixed because of the potential impact on the schedule. Often used for construction projects.

Money for nothing, changes for free
Work is basically on a time and materials basis with a cost ceiling, but the customer can stop the project when he realizes enough business values has been created. A cancellation fee equal to the remaining profit is paid. Customer and vendor have an interest in delivering the project early due to lower costs or higher margin.

Joint ventures
Two partners invest in a product of joint interest.

Different contract have different accents, and foster different relationships.

You can find Peter’s presentation here.

Scrum Gathering Munich – Being a scrum coach

Some stuff I wrote down during the panel discussion of ‘Being a Scrum coach’ at the Scrum Gathering in Munich.

The panel consisted of:

Christoph Mathis (moderator)
Rachel Davies
Siegfried Kaltenecker
Peter Hundermark
Bent Myllerup

Q) How can you help a team that is underperforming?
A) Rachel: By using retrospectives to continuously improve. By talking to individuals, but also to the team. By trying to understand.

Q) When is it better to stop coaching?
A) Rachel: When a team is under high pressure and the really don’t have any time to learn the new stuff you’re coaching. When there is a time of tension, in which layoffs are happening. People will be careful when asked to try out new stuff.

Q) What‘s the difference between a Scrum Master and a Scrum Coach?
A) Peter: A coach starts from day one making himself obsolete. For instance by coaching other coaches.
Rachel: Even scrum master can be a transient role, the team should take it on them over time.
Bent: A coach is usually the coach of the scrum masters

Q) Do you need specific skills as a coach?
A) Rachel: You need a supporting network as back up. A coach always needs more skills and should keep on learning. A good formula is pair coaching. A good coach also dares to admit he doesn’t know everything.

Some other comments during the panel discussion

Peter: You need to be able to set a clear goal, and get out of the way.

Siegfried: Create space & time to solve problems

Rachel: Step back and reflect, it is a good counterbalance for pressure

 

Scrum Gathering Munich – Effective Coaching

This session was part of the CI track (Coaching & Continuous Improvement) and presented by Tom Mellor and Lowell Lindstrom.

Central topic of the talk were their experiences as agile coaches at Tom’s company. Tom being an internal coach and Lowell being an external coach.

The audience was highly involved, sharing their views and experiences.

Some of the questions we worked around:

1) How prescriptive should an agile transition be?

‘Do this, do that’ vs ‘teaching values’ and let the team try on their own.

There are benefits and downsides at both strategies. If a coach is too prescriptive, the team focuses too hard on the process, not understanding the underlying ideas. They will understand the how, but not the why. If a coach is not prescriptive enough, the team will understand the why, but will choose its own set of rules, perhaps missing some crucial part of the process. This is what Tom said he would do different next time. Be a little more prescriptive, so each team at least does the most crucial stuff.

2) Internal / External label on coaches

People sometimes accept more from an external coach than from an internal one. It has to do with perspective. When the company brings in a stranger as a subject matter specialist, you‘re more likely to be open to his suggestions on the matter. Nevertheless an external coach can get comments like ‘you don’t know the company business’, when touching a sensitive issue.

3) How to influence the organization? Horizontally, vertically?

4) Horns and halo’s – the team perspective of coaching.

Too much stuff to write about in a blog post, but certainly interesting. A lot of the topics returned during a panel discussion on Tuesday, which I will write about soon.

Scrum Gathering Munich – Social Objects in Agile Teams

Dilbert Considered Harmful? Social objects in Agile Teams

This session by David Harvey was part of the O (Other/Miscellaneous) track.

It is built around the idea that certain social objects in teams and workplaces can be caused by underlying issues.

His main example are the dilbert cartoons, that are sometimes found on walls in offices.

Why would anyone hang this cartoon on his wall? Maybe they have issues with management? Mistrust, feeling misunderstood, disillusioned, …

David launched the following model that show different steps which can lead to these social objects:

Frictions => Work arounds => Waste => Frustration => Cynicism =>Embedded in organization

He included some scientific experiments that have shown people’s behavior is influenced by their social environment.

Then the attendants were asked to divide into pairs and think about social objects form their own experiences. Lots of stuff came up. I give you a few:

• Pictures of beautiful people in suits
Who hung these in the office? They are of no use to the dev teams, what is the point behind this?

• Lots of technical books displayed in an open cabinet.
If these books are not used, what statement do they make?

• Cluttered desk with lots of papers piled up
Is the person whom the desk belongs to making a statement about his workload?

• Cartoons about testing
Is testing a passion of this person, or is he visualizing his frustration about the lack of it?

I liked the session because I ‘ve never spent a lot of time thinking about these things. There may be a lot more going on.

David concluded by asking how we should approach these social objects?

Carefull is the answer that‘s always returning. We should try to find out the history behind them. Don’t remove them hard-handed; try questioning them carefully, maybe during an office rearrangement. And please use the information to do something about the causes.

Scrum Gathering Munich – Keynote Jeff Sutherland

First session at the Scrum Gathering in Munich was a keynote by Jeff Sutherland called ‘A Practical Roadmap to Great Scrum: A Systematic Guide to Hyperproductivity’. Jeff is really enthusiastic about the performance gains he got with the introduction of Scrum in enterprises. He talks about double, triple, etc performance when teams move towards high performance ecosystems.

On one hand, this sounds a lot like a marketing talk. But on the other hand, I believe the results can be really great when scrum is applied appropriately (any agile process by the way).

When selling agile to senior management, in the end this is the only thing that matters to them. What do we get out of it? Is it worth the effort and risk?

You can find his presentation here.

Scrum 2.0

Today during the Srum Gathering in Munich,
the Scrum Alliance board formally replied during a panel discussion that they don’t have any strategy or plans for a second version of the scrum framework.

Tom Mellor, CEO of Scrum Alliance put it like this:

When waterfall releases version 2, we will release scrum 2.0

The daily hands-up

Having trouble keeping your daily stand up’s time boxed?
Sometimes our team had. Until I read a great tip on Kevin E. Schlabach’s blog.

Getting bored in the daily standup? Raise your hands…

The idea is genius in its simplicity. If you’re getting the feeling the current topic is not relevant during the daily standup, raise your hand. The other team members notice your feeling. Some might agree and raise their hands as well. Most of the time, it is sufficient to let the person talking realize that he should put the topic in the parking lot and move on.

The great thing about this is the immediate visibility of consensus. In a few seconds, you get an idea of who is agreeing to your feeling. If nobody raises their hand, it means the topic is still relevant and doesn’t have to be treated outside the daily standup.

I’ve seen a lot of projects where it was always the scrum master asking team members to take discussions out of the daily stand up. Now everybody does it by simply raising their hands. It’s a non-aggressive way to remind people about the goal of a daily standup.

Besides that, it’s fun too

Just make sure the idea is taken seriously so everybody still has the time to express their thoughts.

Building up technical debt?

Retrospectives are the ideal time to remind the team about specific practices.

In our last retrospective, I tried to find out if we were building up technical debt.

By holding a poll, the results would show us if we took enough time to refactor.

Every team member graded the code health on a scale from 0 to 5. Zero being dramatic, five being perfect code.

This was the result:

The team responded that five is impossible to achieve, but we that it should always be our ambition.

We concluded that 4 was a great score and that we took enough time to refactor.

Keep up the good work, guys! We’ll do the poll again in a couple of weeks.

Boring retrospectives – part 2

When your team is operating in short iterations, retrospectives tend to get boring after a while. If you’re working in an agile organization, most suggestions for improvement have been executed and evaluated. The obvious improvement actions have already been identified.

Now, you have two options:

1. Keep doing the same retrospectives, and accept that no more valuable ideas for improvement are found.

2. Change the format of your retrospectives. Go for gold and try to improve on the less obvious stuff.

If you go for option 2, there are great exercises that can help your team going through this process.

For starters, get the book Agile Retrospectives by Esther Derby & Diana Larsen. It has a list of activities which you can use to get some variety in your retrospectives and get inspiration to come up with your own variations.

This is one I used recently, which I call ‘Actions centered’. It is based on the ‘Temperature reading’ activity. Similar to the Starfish exercise, it changed our perspective and as a result, we found some new area’s for improvement.

This is how it works,

You draw a big square with a little square in the centre. That’s where the actions go. The area around the small square gets divided into 4 pieces. Each piece serves as a placeholder for the following categories:

• Appreciations (what did you like during the previous iteration?)
• Puzzles (general wonderings, things you have no answer to)
• Risks (future pitfalls that can endanger the project)
• Wishes (goes further than improvements, your ideal project)

This is how it looks on a flipchart:

 

Next, everyone gets some time to write up their thoughts for each of the four categories. When everyone’s done, each team member at a time gets to explain one of his notes and sticks them on the corresponding category.

After a previous retrospective with moderate results, this one was a complete success. All four categories were completely filled with post-its. Even better, 6 tangible actions were defined.  We used dot-voting to rank the risks.

I really like the Puzzles category. It gives you the opportunity to get your wonderings into the group, which can lead to discussions and other views on the subject. I believe some of these thoughts wouldn’t end up on the wall if we would have done the classic ‘good / better’ exercise.