The a-team as agile pioneers @ SDC2010

 
Image courtesy of moproblems.files.wordpress.com

On March 17, 2010 I will be speaking at the Scandinavian Developer Conference in Göteborg, Sweden. My session is called ‘The A-team as agile pioneers’.

That’s right! I’m going to talk about your heroes. Hannibal, Murdoch, Face and B.A. Baracus. Four guys in a black minivan, saving humanity from evil (without ever killing someone).

Off course the conference organizers wouldn’t have accepted my proposal if it had nothing to do with software development.

So I’ll be comparing them with your standard agile development team. Responsibilities, collaboration, communication, trust, … By mirroring to the A-team, we try to get more insights.

Come and join me, it will be fun. Take a look at the rest of the program, it looks promising.

See you in Sweden. Skal!

Reflections on The People’s Scrum

After reading Tobias Mayer’s post ‘The People’s Scrum’, a lot of thoughts popped up in my mind.

When I discovered Scrum in mid 2007, my first thought was “What a great process!”. I immediately jumped right in, trying to get a hang of it. After some reading and the obligatory CSM course, I thought I had it all figured out. Man, was I wrong!

A couple of months later, the other approach on planning really begun to sink in. What were we doing these previous years, making up detailed plans for years to come? Trying to predict the future? We were just fooling ourselves!  Why couldn’t we trust each other and work our way through a list of features, prioritized by the customer on business value?
Once again, I thought I figured it out.

After a while I began to investigate ‘Customer collaboration’. We worked on a basis of trust with our customer, followed the scrum flow, but still could not manage to build what the customer had in its mind. I read some great material about ‘Sofware development as a cooperative game’ by Alistair Cockburn and ‘Programming as theory building’ by Peter Naur where the complexity of getting a team to understand the business problem was placed in the center of focus.
Again I thought, this should be it.

Some time later, I started to get into the depth of self-organization and servant leadership. As you probably know, creative processes (such as software dev) require a different management approach. Command and control style simple doesn’t work in that context. A project manager should act as a servant leader, doing everything in its power to help the team reaching their goals.

This is where I’m at now. Convincing myself that through these values of respect, collaboration and trust, an organization can become so much better. If we let go of the command and control style, and invest in leadership, collaboration and personal growth, retention will be much lower and we would attract much more high potentials. Scrum can be a first step to introduce this, and certainly fits well in the new organizational model.

As sad as it may sound, I think this is much harder to sell than the hyper-productivity case of Jeff Sutherland.

I guess what I’m trying to say here is that it takes a lot of time to grasp the full potential of Scrum.  Realizing that it’s more than a tool. I don’t believe Henrik thinks of Scrum as just a tool. He may have chosen some bad words when trying to compare the practical side of Scrum and Kanban.

Lean 5 S thoughts

While learning about lean, I came across the five S’s, which is a tool to organize a workspace with visual controls and order.
The S’s stand for five Japanese words that start with an S: seiri, seiton, seiso, seiketsu, and shitsuke. Translated in English this becomes Sort, Straighten, Shine, Standardize, and Sustain.

 
(image courtesy of b2b.blogsome.com)

Sort
Sort your material and get rid of all the unnecessary pieces.

Straighten
Give every item a fixed place and make it visual.

Shine
Clear up and inspect for shortcomings.

Standardize
Create standards to monitor and guard the previous 3 S’s.

Sustain
The discipline that is needed to maintain this in a process of continuous improvement.

Working in a clean, organized workplace is not the only goal of the 5 S’s. The biggest benefit is the prevention of errors and defects that are caused by waste. This is a reality for manufacturing, but can also be applied to software development, as you can read in the Poppendieck’s book Implementing lean software development.

Sort
Reduce the size of your codebase

Straighten
Organize the projects and packages

Shine
Clean up. Resolve failing unit tests, warnings, TODO’s, … Problems are more visible when everything is clean and tidy.

Standardize
Keep clean and refactor mercilessly to reduce complexity and improve maintainability.

Sustain
Build in regular checkpoints to control the current state (ex. Retrospectives), so actions can be taken.

I think it goes further than code. By keeping the team room clean, we

• avoid being influenced by old information which may no longer be accurate
• assure that every information we look at is still relevant
• stimulate the use of visual aids, such as whiteboards and flipcharts
• keep our stress level down
• make it easier for stakeholders to get the data they need from the information radiators

I don’t like to clean up, and probably neither do you. Fact is that I do want to have these benefits and cleaning can go fast as long as you don’t let the clutter pile up.

Agile alarms – part 1

Lately it becomes more quickly visible to me when people have difficulties understanding the agile values.

Certain reactions or statements are alarming. For instance this example:

During a sprint planning, the Scrum master gets nervous when discussions about a user story take some time. He tries to pressure the team to cut their discussions short, or worse, demand a story point estimate immediately, so they can move on to the next one.

The idea behind this behavior is closely related to classical management style. Workers are told what to do, by when. Reasons or goals are not communicated. Feedback is not requested. Perception exists that managers have more knowledge about the actual production process than the executors. He wants to get this planning meeting over asap, because it is costing x developers per hour.

In the western industry of our days this idea is no longer valid. More and more people are working in creative processes, which have the property to be difficult to plan. You need intense collaboration between management and execution in order to come up with a realistic short-term planning. Trust needs to be established when moving towards a goal oriented management style. The people who are executing the process are in most cases best suited to make decisions about the execution, within the boundaries of the goal and strategy. Using the knowledge and creativity of the people to reach goals and even exceeding them distincts great companies from mediocre companies already and will do so more and more in the future.

Please let them finish their discussions, otherwise these will pop up during development and you will be in bigger trouble because estimations have been made and committed to.

This is a great post by Bas De Baar of Project Schrink about the difference between Top Down and Bottom Up project management.

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.