From Scrum to Kanban, but now what?

[Vincent Vanderheeren]

Hi, my name is Vincent Vanderheeren. I work as a delivery manager and agile coach, and next to that I am a passionate wine enthusiast but that is not quite relevant.

I'm honored that I'm invited to this group, so special thx to Yves and all the people in this group for the things I've learned so far and am about to.

4 Years ago I transformed a company from a bad working waterfall environment into Scrum. 2 years later we optimized our Scrum process with Kanban.

When I met Xavier (Quesada) and Yves I was doing Scrum already not that bad. However their help on visualisation really boosted the process incredibly fast. 

At the time I didn't realise the impact of the visualisation aspect itself. Now I can say that visualisation in all aspects (as Dave has outlined remarkably well):

• makes the entire team to understand the bigger picture
• motivates in reaching targets and communicates the road towards that target
• makes people visible, No more hiding.
• makes policies explicit
• makes the process grow organically and evolve
• forms a base on which the organisation can rely regarding productivity, predictability and quality.

Eventually (and that is where we are now) we visualised our working capacity as one big Kanban pull system. We know our cycle time, productivity and throughput, and can manage our flow quite well. All this has been accomplished with the help of the entire team. Therefore I believe Visualisation is tightly correlated with People Management. 

In my personal life I use no visualisation what so ever. As structured and disciplined that I am at work, so chaotic am I at home. My wife has a plan on making all the children's (we have 3 sons) activities visible on a board so we can plan better. This is not yet in place, so no success so far. Our home atmosphere is all chaotic, loud and stressy. But we do fine ;).

On the workfloor I have also some kind of a challenge. Our company was taken over in July, and suddenly we don't have one team of 10 people anymore, but 2 distributed teams with 25 extra people. They do not use Kanban, but Scrum. After evaluating their process it seems that they are doing waterfall, but development in a scrum way (don't take this as an offensive remark, it is just meant observational to give an idea of the situation).

Probably all visualisations we created with the original team can be useful, but the problem is that everything we have is based on relative weights which have the same meaning over all projects. Productivity, velocity, throughput (predictability) are all based on it, and have been for several years now.

The 2 distributed teams give me scalability issues. 

• How can I quickly invite them in our way of work without forcing them into a process that is not theirs?
• How can I continue my measurements and scale them over the whole team when they are not working with the same point scale?
• What about the synchronisation issues of the butcher paper charts, Kanban post-it boards, … I have everything digitally visualised the same way as it hangs on the walls, but that is just not as powerful.

Any advice is welcome.

Kind regards,

Vincent

[Yves Hanoulle]

2012/9/11 Vincent Vanderheeren <vincent.va...@one-agency.be>

Hi, my name is Vincent Vanderheeren.

Hi Vincent

Glad to see you here. and happy the security problems are worked out (I actually did not do anything more today, so mailing just works...)

 

I work as a delivery manager and agile coach, and next to that I am a passionate wine enthusiast but that is not quite relevant.

I'm honored that I'm invited to this group, so special thx to Yves and all the people in this group for the things I've learned so far and am about to.

 I have worked with Vincent before, and I can assure that he listens better then most clients. ;-)

4 Years ago I transformed a company from a bad working waterfall environment into Scrum. 2 years later we optimized our Scrum process with Kanban.

When I met Xavier (Quesada) and Yves I was doing Scrum already not that bad. However their help on visualisation really boosted the process incredibly fast. 

At the time I didn't realise the impact of the visualisation aspect itself. Now I can say that visualization in all aspects (as Dave has outlined remarkably well):

• makes the entire team to understand the bigger picture
• motivates in reaching targets and communicates the road towards that target
• makes people visible, No more hiding.
• makes policies explicit
• makes the process grow organically and evolve
• forms a base on which the organisation can rely regarding productivity, predictability and quality.

Eventually (and that is where we are now) we visualised our working capacity as one big Kanban pull system. We know our cycle time, productivity and throughput, and can manage our flow quite well. All this has been accomplished with the help of the entire team. Therefore I believe Visualisation is tightly correlated with People Management. 

aha interesting. say more .

 

In my personal life I use no visualisation what so ever. As structured and disciplined that I am at work, so chaotic am I at home. My wife has a plan on making all the children's (we have 3 sons) activities visible on a board so we can plan better. This is not yet in place, so no success so far. Our home atmosphere is all chaotic, loud and stressy. But we do fine ;).

I guess you should invite her to the mailing list too..(serious)

 

On the workfloor I have also some kind of a challenge. Our company was taken over in July, and suddenly we don't have one team of 10 people anymore, but 2 distributed teams with 25 extra people. They do not use Kanban, but Scrum. After evaluating their process it seems that they are doing waterfall, but development in a scrum way (don't take this as an offensive remark, it is just meant observational to give an idea of the situation).

try avoiding the word "them" in your conversations. it's one company now.  ;-)

 

Probably all visualisations we created with the original team can be useful, but the problem is that everything we have is based on relative weights which have the same meaning over all projects. Productivity, velocity, throughput (predictability) are all based on it, and have been for several years now.

The 2 distributed teams give me scalability issues. 

• How can I quickly invite them in our way of work without forcing them into a process that is not theirs?
• How can I continue my measurements and scale them over the whole team when they are not working with the same point scale?
• What about the synchronisation issues of the butcher paper charts, Kanban post-it boards, … I have everything digitally visualised the same way as it hangs on the walls, but that is just not as powerful.

Any advice is welcome.

Who wants to take on this challenge?

 

Kind regards,

Vincent

--
You received this message because you are subscribed to the Google Groups "VisualizingProblems" group.
To unsubscribe from this group, send email to visualizingprob...@googlegroups.com.
Visit this group at http://groups.google.com/group/visualizingproblems?hl=en.
 
 

[Jim Benson]

Probably all visualisations we created with the original team can be useful, but the problem is that everything we have is based on relative weights which have the same meaning over all projects. Productivity, velocity, throughput (predictability) are all based on it, and have been for several years now.

The 2 distributed teams give me scalability issues. 

• How can I quickly invite them in our way of work without forcing them into a process that is not theirs?
• How can I continue my measurements and scale them over the whole team when they are not working with the same point scale?
• What about the synchronisation issues of the butcher paper charts, Kanban post-it boards, … I have everything digitally visualised the same way as it hangs on the walls, but that is just not as powerful.

Any advice is welcome.

Who wants to take on this challenge?

First, I'd say the initial goal would be to accurately map their process as it stands now. Then visualize that.

Waterfall should not be opposed to seeing work. There is no "waterfall must be blind" rule.

Once that gets up, talk to them about limiting work-in-progress. Let them know that if they do they are more likely to stick to their gantt charts.

After that, let continuous improvement take over. Bottlenecks will present themselves. Likely, the discrepancies in effectiveness between the two teams will also present themselves.

If they don't, then everything is fine and all you needed was the board.

As for distributed teams - how distributed are they?

Jim 

[Vincent Vanderheeren]

Thx Jim for the advice!

Well the first office is in Ghent, the second in Leuven. By car it's like a 1 hour distance. Sad enough you need to cross Brussels which is a traffic disaster, so by train is the only option which makes it a 1:30 hour travel. The problem is thus not that bad, but still there are 2 different locations.

The goal we got from management is simple: make sure you don't get  2 separate islands.

Mapping their process is indeed the challenge. Some teams use ideal working hours as story estimation, while others use points that are relatively different of ours. But still I think I know where to start. I think we can quickly uncover some patterns regarding delivery that we can work on to improve.

Vincent

--
You received this message because you are subscribed to the Google Groups "VisualizingProblems" group.
To unsubscribe from this group, send email to visualizingprob...@googlegroups.com.
Visit this group at http://groups.google.com/group/visualizingproblems?hl=en.
 
 

Vincent Vanderheeren

Delivery Manager

T. +32 9 216 81 11

vincent.va...@one-agency.be

GRAUWPOORT 1, 9000 GENT  •  BELGIUM  •  T. +32 9 216 81 11

WWW.ONE-AGENCY.BE

[Vincent Vanderheeren]

Jim, 

Just as a sidenote,

I just checked your site(s) and bumped onto Personal Kanban. That alone might be enough to temper my home stress. Me and my wife have so many things to do at home that we just get stress knowing it is just too much and that we fail to have some kind of an overview. 

Maybe all we need is to:

• Visualise what needs to be done
• not being able doing too much at once

I think this might be my most valuable lesson of the day. I'll discuss it with my wife tomorrow. I'm quite enthusiastic about this :).

Thx :)

Vincent

On 11 Sep 2012, at 16:50, Jim Benson <j...@moduscooperandi.com> wrote:

--
You received this message because you are subscribed to the Google Groups "VisualizingProblems" group.
To unsubscribe from this group, send email to visualizingprob...@googlegroups.com.
Visit this group at http://groups.google.com/group/visualizingproblems?hl=en.
 
 

[Pierre Fauvel]

Hi,

Just some thoughts.

Why do you need to have the same scale of estimates ? Each team can have its velocity in a different unit, no ? What counts is the ratio estimate divided by expected velocity, no ?

As for visual management, even if you use a tool, do you keep the brown paper and the postits too ?

As for distance, make sure people meet in person frequently. What about once a week ?

Cordialy
Pierre Fauvel

[Vincent Vanderheeren]

Pierre,

You have a valid point here. Trying to upscale the estimates will only give me a headache and no gain at all. It's also something that probably can never scale. Maybe that is just what we need to do: create units, and let them improve continuously on their own, as Jim also mentioned. That way I can let each unit use their own Scrum process and coach them in improving it. For that I can try to introduce Kanban in the group.

The tool for us is less important than the boards  and charts hanging aroung in the room. It has more impact in communication and information sharing.

Meeting each other once a week should be doable.

Thx,

Vincent

[Dave Nicolette]

Team-level estimates or story sizes need not be consistent across
teams or even across projects carried out by the same team. That is
only meant to help individual teams do their own short-term planning.

If you're looking at Lean stuff like kanban, then consider Lean
metrics as well. They are agnostic about the details of how the work
is done. They just measure outcomes.

Throughput - quantity of work delivered per unit time

Cycle time - average length of time to complete a single work item of
average scope

Process cycle effficiency - percentage of total lead time in which
value is actually added to the product

These are good measures for tracking process improvement, because as
you change your process the metrics continue to have the same meaning.

Hope that helps.
Dave

[Vincent Vanderheeren]

I'm interested in this PCE metric. All others are in place already. How do you distinguish "value added time" from your cycle time? Does this imply business value towards the end-product, or efficiency time necessary to analyse, develop, test or integrate a workitem?

[Dave Nicolette]

On 9/12/12, Vincent Vanderheeren <vincent.va...@one-agency.be> wrote:
> I'm interested in this PCE metric. All others are in place already. How do
> you distinguish "value added time" from your cycle time? Does this imply
> business value towards the end-product, or efficiency time necessary to
> analyse, develop, test or integrate a workitem?
>

That question calls for a long answer. I'll do my best to answer it as
soon as I can.

Short version:

It doesn't measure business value, it measures "efficiency" of delivery.

When someone pulls a work item, it is officially in an "active"
status. But no one works on an item 100% of the time. Say you have
pulled 5 work items and you are task-switching among them. PCE would
distinguish between the time an item is waiting for your attention and
the time you are actively adding value to it.

For thing-making companies like manufacturers, industry figures for
the best performers are around 25% PCE. For information-shuffling
companies (including software development activities), industry
figures for best performers are around 5%. This tends to be rather
shocking to people when they first discover it.

Most IT organizations I've seen have a PCE of around 1%. They spend
most of their time waiting for each other to do tiny, tiny things like
adding an index to a database table or opening a port on a router, or
to "review" or "approve" things.

A work item might wait for 6 weeks for someone to add an index to a
table; adding the index takes 5 minutes; then the items waits another
2 weeks because the developer who is working on it has become busy
with some other task while he was waiting for the index.

Multiply that by all the activity happening in a company that runs
200-300 projects concurrently with a staff of 1500-2000. Nearly all
the time is wasted. People don't see the waste because they are
looking at how "busy" everyone is, rather than at the relative amount
of time each work item spends waiting for attention. PCE can be a real
eye-opener.

More later.

Cheers,
Dave

[Vincent Vanderheeren]

I really love this and look forward to the long version.

I will try to implement it in my next project. :)

My only worry is that "starting the timer" when a work item gets active won't be to intrusive and controlling to some people. This will work for sure in a team where people know me (as the opposite of command and control), but will be more difficult for the people not knowing me. It certainly makes the process a bit more heavyweight because people need to add the net working time to the work item every time they work on it. Won't be easy for some :)

--
You received this message because you are subscribed to the Google Groups "VisualizingProblems" group.
To unsubscribe from this group, send email to visualizingprob...@googlegroups.com.
Visit this group at http://groups.google.com/group/visualizingproblems?hl=en.

[Dave Nicolette]

On 9/12/12, Vincent Vanderheeren <vincent.va...@one-agency.be> wrote:
> I really love this and look forward to the long version.
>
> I will try to implement it in my next project. :)
>
> My only worry is that "starting the timer" when a work item gets active
> won't be to intrusive and controlling to some people. This will work for
> sure in a team where people know me (as the opposite of command and
> control), but will be more difficult for the people not knowing me.

Maybe it would help them to understand that PCE is not about
monitoring people, it's about understanding how the work flows through
the process.

> It
> certainly makes the process a bit more heavyweight because people need to
> add the net working time to the work item every time they work on it. Won't
> be easy for some :)

That is true. Gathering the raw data to develop the PCE metric is a
bit cumbersome. There are no electronic tools that can help with it.
The only way I've been able to gather the raw data is to ask people to
make a note of when they start and stop working on each item. It is a
bit intrusive, but so far I don't know of a way to make it more
painless. I think it's worth doing because it gives us really valuable
information for process improvement. Maybe you can think of a way to
make it simpler!

Dave

> Vincent Vanderheeren
> Delivery Manager
> T. +32 9 216 81 11
> vincent.va...@one-agency.be
> GRAUWPOORT 1, 9000 GENT • BELGIUM • T. +32 9 216 81 11
> WWW.ONE-AGENCY.BE
>