Mattias Skarin

5 months have now passed since we introduced Kanban and Agile to two teams. Here is a half way report:

Good stuff

• Trust has grown significantly, to developers and to managers
• The work they put in is now visible and appriciated in the organisation
• "We now have visibility and can affect our situation" / team member
• Both have taken significant steps from specialized individuals to teams. This is seen in frequent cooperation and problem solving.
• Knowledge sharing has intensified dramaitically
• Managers can instantly spot problems by walking through the department looking at the kanban boards
• 2 months after introduction, one team was voted "best in company" that sprint. It was also acknowledged as second highest "good" thing in company retrospective same period

Challenges remaining:

• It is hard to find clear team goals (there are no sprints)
• Knowledge sharing puts pressure on senior members, it is important to give something back, making their work fun
• A constant struggle fixing root causes outside team limits
• Teams evolves so rapidly it is hard for organisation to keep up!

The positive problem of the month
I was called in to one teams retro…

"we think we have a problem.."
"uhm.. (holding my breath) . tell me"
"well in our retro, we have too few problems…"

I’d love to see more of this 🙂

I currently coach a system administration team. Anyone who has worked in one knows the constant attention required and the difficulty to find  uninterrupted time. (phone ringing constantly..) 

Doing kanban, we do iteration plannings every week and they need to be fast and accurate and we only need to keep a 45 min window. We have experimented with different approaches, and this has been the best working.

This is not you, right?

• Customer making changes at a faster rate then the development teams can implement
• A development team running short sprint lengths only to deliver crap to QA
• A development team promising features at a quicker rate than we can make avaliable to end customers – only to build up a queue of unshipped work
• A management team changing directions in a faster pace then company can absorb them,
• A software development company entering an Agile contract with a waterfall process

We apply agile principles to be fast and responsive to changes. Lean teaches us to "deferr decisions", agile to "change late". But doing this and turning a blind eye to real limitations we  fool ourselves to believe we can drive faster than we are able. Result? Quick steering adjustments aimed for a sports car brings the truck into inbalance and possible into the ditch.

running this?	..or this?

Cycle time helps us monitor our system performance. So cycle time is a good  thing 🙂

But there is two ways of tracking it. First (obvious) way is by starting a stopwatch when an item enters system and stopping it when it exits. This gives a reliable measurement but only after we have passed the process.

But there is a better way!

Have you experienced a burndown similar to this?

More than once?

Let me show how Kanban can help both team and managers to spot the underlying  problem before it is too late.

Scrum does not fit well into the fast moving world of support. There is no Sprint committment, there is just continuous work.

But support teams can go Agile. The solutions is spelled Kanban. I have coached two support teams adopting Kanban and attached is a visual representation in how we did it.

"It really helps us visualize our projects and situation"
– Team member

"The first useful thing I can bring with me"
– Team member

How support can go Agile in 5 min

This is not the only way to do it and it is certainly not the end station :). It was just the way that helped our teams to "get going" instead of talking about it.
— mattias.skarin(at)crisp.se

Building something common out of high performing individuals is not always easy. Here are my favourite five Agile team rules:

• Best idea prevales!  "No" – is allowed, if you can come up with something better
• Steady progress beats tripping and falling over
• Bad news first
• In order to lead an army, you have to be able to lead a group. In order to lead a group, you have to be able to lead yourself
• Is it better to be right or to be helpful?

The day I know I have succeeded with Agile? -The day I am out surfing 🙂

As part of development teams and as project managers, I have worked with a number of support departments. They face similar issues:

• "We can’t promise project completion – we are interrupt driven"!
• I want coworkers to take a bigger responsibility, but how?
• How can we too get Agile?

The solution is spelled Kanban Scrum (or just "Kanban"). Currently I am coaching two teams in support/operations to tackle above issues. Being one month into this, I see both teams do great progress. I will get back to tell how we do it. Stay tuned.

"Scrum is like chess, simple rules but hard to play"

    – Who else but my collegue Henrik 🙂

Here you can find my slides from NFI’s conference "Från krav till system"  ("From requirement to complete system"). It is the story of two destinies and how they overcame using Lean and Scrum.

The slides

Not all impediments are easily fixed. They can be structural by nature. Lack of space, bad air or organization legacy is not always an easy fix. So what to do? Do you:

Keep impediments on the daily impediment list (with potential demoralising effect of seeing it every day)? Assign a person and remove it from the list? Or..?

Clear roles is important in setting expectations. Not the limit (people can indeed master several roles at the same time) but bringing clearity is a way of saying "being a [product owner] this is what I expect from you".

There is a lot of stuff out there on what Scrum role do but very little about what is expected from Agile Leadership. This is the definitions I use.

In my favourite setup, this game demonstrates the power of learning by trying over "paralysis by analysis". But it also reveals productivity increase and group dynamics of your team.

Excellent game for quick learning of lean principles. You can do it anywhere and anytime with 20 pennies, some mobile phones and a team of playful people.

In Agile2008 Enthiosys held an interesting walk-by excercise where attendees collaborated to build and price a product.

What’s interesting is that they got through all the steps just using the "Wizdom of the crowds" of the Agile2008 attendees. Also, the techniques used are valuable to check out.

Read full story at their blog..

When talking about Scrum to business people I very often get the question "How do I deal with fixed priced contracts when doing Scrum?"

It struck me today no one who ever asked me this, has come to the conclusion that doing fixed priced contracts could be wrong way to go altogether.

And that is a bit scary.

Here are top three tools for any Scrum project

In Scrum it is often perceived that planning takes place on sprint planning day. Getting the required parties in the same place and do planning is a good way of making real time decisions. But getting people together is a dounting or impossible task and this also neglects some of the thought processes that needs to take place before stories are estimatable.

Because of unclear definition of benefit of removing technical debt, PO and teams risk move into a standstill regarding activities to to remove it. This is counter productive, we should remove thresholds of quality improvement activities, not introduce them. So let’s look into a simple definition that can help out.

As a Scrum team, we need to recognise that we are not alone in building business value for our software and provide visibility in where we are heading. By using a roadmap updated per sprint basis is an easy way of making everyone pull in the same direction.