[LCS] Timeboxing Pros & Cons

[Dave Rooney]

A team that is approaching the end of their 10th 3-week sprint has, yet
again, a couple of stories that won't be completed. They don't seem to
have a sense of urgency about the incomplete stories, with an apathetic
shrug. The Product Owner and ScrumMaster share that apathy.

So, for this team timeboxes mean nothing. If there is no value in the
Sprint timebox, then Sprints should be abolished and a pull model like
Kanban should be established.

Discuss.

--
Dave Rooney
Westboro Systems
Web: http://www.westborosystems.com
Blog: http://practicalagility.blogspot.com
Twitter: daverooneyca


--
Subscription settings: http://groups.google.com/group/lonely-coaches-sodality/subscribe?hl=en

[George Dinwiddie]

Dave,

Dave Rooney wrote:
> A team that is approaching the end of their 10th 3-week sprint has, yet
> again, a couple of stories that won't be completed. They don't seem to
> have a sense of urgency about the incomplete stories, with an apathetic
> shrug. The Product Owner and ScrumMaster share that apathy.
>
> So, for this team timeboxes mean nothing. If there is no value in the
> Sprint timebox, then Sprints should be abolished and a pull model like
> Kanban should be established.

Would that give them a sense of urgency? Or just remove any reminders
that time is leaving them behind.

If the PO doesn't care whether stuff gets done or not, then why should
anyone else care? Is this person /really/ a PO, or just someone given
that title?

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[Charlie Poole]

Hi Dave,

I don't see much to talk about here, but that hasn't stopped me before, so
here goes...)

It seems to me that a team that's apathetic under sprints will be apathetic
under Kanban as well. Somebody has to care about delivery.

This team seems to have a poor Product Owner. If he's a proxy for the
customer, try to figure out if his apathy is a reflection of how the actual
customer feels. If they're apathetic, I don't see much you can do. If
they are not, find a Product Owner who represents their views.

I believe that a ScrumMaster should be disturbed by this situation. If
not, he doesn't understand his role, which is to (1) deliver what the
customer wants and (2) improve the functioning of the team. If I were
in such a situation, I'd call a team meeting to discuss it and find out
how satisfied the team members were with the situation. If it turns
out that everyone is apathetic, I'd terminate my role in pretty short order.

Usually, there turns out to be some dissatisfaction under the guise
of apparent apathy. I'd try to find that.

I'm more experienced in timeboxing than in a Kanban approach, but
it feels to me like this team is not ready for Kanban. Folks with more
experience may see it differently, but I view Kanban as a more
advanced approach that many teams should really not try. At least
with timeboxing, we are highlighting the failure to deliver at the end
of each iteration.

One issue I would address: what is the cause of the failure to deliver
in each sprint. By analyzing what happened as a group, the team
can surface reasons for not caring. Sometimes those reasons even
make sense... like "We estimated 20% more work than we really
thought we could complete, because X insisted on it."

Another reason that makes sense is micro-feature creep. I had one
guy tell me "If I finish a story early, I try to find out what else the
Customer wants done. After all, we promised him a certain amount
of work." Of course, this guy was never under his estimate and was
over it as often as anyone else. Do the math.

All of these are "good" reasons from some point of view but are
bad for the functioning of the team. It's worth the effort to learn
about them. In the situation you describe, you're looking for the
reason for the apathy, but you may get more accurate answers
if you sneak up on it this way.

Charlie

Charlie

[Dave Rooney]

On 04/21/2010 11:56 AM, George Dinwiddie wrote:
> Dave Rooney wrote:
>> A team that is approaching the end of their 10th 3-week sprint has,
>> yet again, a couple of stories that won't be completed. They don't
>> seem to have a sense of urgency about the incomplete stories, with an
>> apathetic shrug. The Product Owner and ScrumMaster share that apathy.
>>
>> So, for this team timeboxes mean nothing. If there is no value in
>> the Sprint timebox, then Sprints should be abolished and a pull model
>> like Kanban should be established.
>
> Would that give them a sense of urgency? Or just remove any reminders
> that time is leaving them behind.

I don't know. My gut doubts that it would.

> If the PO doesn't care whether stuff gets done or not, then why should
> anyone else care? Is this person /really/ a PO, or just someone given
> that title?

Ding ding ding!! Not a real PO. Not even a proxy. I'm preparing to
raise the issue in general.

Thanks!

Dave...

[Yves Hanoulle]

2010/4/21 Dave Rooney <davero...@gmail.com>

On 04/21/2010 11:56 AM, George Dinwiddie wrote:

Dave Rooney wrote:

A team that is approaching the end of their 10th 3-week sprint has, yet again, a couple of stories that won't be completed.  They don't seem to have a sense of urgency about the incomplete stories, with an apathetic shrug.  The Product Owner and ScrumMaster share that apathy.

So, for this team timeboxes mean nothing.  If there is no value in the Sprint timebox, then Sprints should be abolished and a pull model like Kanban should be established.

Would that give them a sense of urgency?  Or just remove any reminders that time is leaving them behind.

I don't know.  My gut doubts that it would.

That is one problem see with kanban.

I know of a team that wanted to go to kanban where I thoughed it was for the wrong reason.

They could not attain one single sprint .

When I brought up this point with David Anderson and co, (after I left that team) they told me that is not what happens. They told me that some teams better focus with a limited WIP.

Could be wurth trying. 

For me the problem is team == product. 

If you look at the PO and the SM as a team, their product is the agile team.

If the PO does not care, why should the team?

Does the SM help the team delivering what the client wants?

yes as the PO does not complain. ;-)

To paraphrase Jim McCarthy some more:

If you see a problem you own it.

If you ignore a problem, you insist on it. 

So you saw it, you react to it. 

I'm interested to know what happens

y

 

If the PO doesn't care whether stuff gets done or not, then why should anyone else care?  Is this person /really/ a PO, or just someone given that title?

Ding ding ding!!  Not a real PO.  Not even a proxy.  I'm preparing to raise the issue in general.

Thanks!

Dave...

--
Subscription settings: http://groups.google.com/group/lonely-coaches-sodality/subscribe?hl=en

--
Yves Hanoulle
Agile Coach EMEA

FR  +33 6 03 40 38 00
BEL +32 9 277 91 99 (Arrives on France Cellphone)

Blog: www.Hanoulle.be

See you at:

Agile Coach Camp Germany (30 April -  2 May 2010 ) http://ww.agilecoachcamp.eu
Agile Train to Trontheim (31 Mai)
Xp 2010 (1-4 June Norway) www.xp2010.org I will be delivering my Leadership Game.
Agile 2010 www.agile2010.org What I learned from burning down my parents house.
Agile Eastern Europe (8-10 October 2010, Kiev) http://www.agileee.org/
XPDay Benelux (25-26 November 2010) www.xpday.be

[Dale Emery]

Hi Dave,

They don't seem to have a sense of urgency about the incomplete stories, with an apathetic shrug.

I'm not a big fan of urgency. I prefer instead to attend to focus. Are they focused? If so, perhaps they're delivering as fast as they can (for now, given their current way of working).

If they're not focused on the sprint goal, attend to that. What kinds of things divert their attention? How do those diversions become higher priority than delivering features?

Dale

--
Dale Emery
Consultant to software teams and leaders
Web: http://dhemery.com
Weblog: http://cwd.dhemery.com

[Jon Kern]

I would agree... just simply keep a list of priorities one or two weeks
worth maybe... Let them churn in whatever cycle time is comfortable.

I would probably be on their side regarding not sweating that we didn't
get 3 done (unless of course we only planned 4, in which case maybe we
just suck). If we are doing our best, what else do you want? Why do you
care to hit the number dead-nuts on? BTW: Some people would call those
extra 3 stories "stretch goals" -- which I hate on so many levels.

jon
blog: http://technicaldebt.wetpaint.com
twitter: http://twitter.com/JonKernPA


Dave Rooney said the following on 4/21/10 11:31 AM:

> A team that is approaching the end of their 10th 3-week sprint has,
> yet again, a couple of stories that won't be completed. They don't
> seem to have a sense of urgency about the incomplete stories, with an
> apathetic shrug. The Product Owner and ScrumMaster share that apathy.
>
> So, for this team timeboxes mean nothing. If there is no value in the
> Sprint timebox, then Sprints should be abolished and a pull model like
> Kanban should be established.
>
> Discuss.
>


--

Subscription settings: http://groups.google.com/group/lonely-coaches-sodality/subscribe?hl=en

[Yves Hanoulle]

What about stories from previous sprints?

Do they only miss stories from current sprints?

How are they in delivering stories in order of priority?

I would say that ALWAYS being right on target is also a bad sign.

y

2010/4/22 Jon Kern <jonk...@gmail.com>

[Thomas Ferris Nicolaisen]

Just to be sure, do you deploy to production at the end of every sprint?

Anyhow, I believe an environment where you can't deploy each feature
to prod upon completion is a big minus for Kanban,

We've got two week timeboxes here, cause there's some ancient
tradition that deployments should happen every two weeks. Without
having thought too much about it, I reckon that having sprint lengths
following deployment frequency is a good thing.

If the team does not take their own Sprint-commitments seriously, you
could try publishing their roadmap outside (closer to the customer).
That oughta drive up expectations a bit, and perhaps team spirit will
follow (communicated properly, of course)?

[Dave Rooney]

Hi Thomas,

On 04/22/2010 03:10 AM, Thomas Ferris Nicolaisen wrote:
> Just to be sure, do you deploy to production at the end of every sprint?
>

No, not to production. This group is one of many teams working on
wireless telecom gear. They won't release anything to production, i.e.
that little building at the bottom of a cell tower, for quite some time.

> Anyhow, I believe an environment where you can't deploy each feature
> to prod upon completion is a big minus for Kanban,
>

I feel that way for *any* process! :)

> We've got two week timeboxes here, cause there's some ancient
> tradition that deployments should happen every two weeks. Without
> having thought too much about it, I reckon that having sprint lengths
> following deployment frequency is a good thing.
>

I fully agree with the shortest economical iteration and release
lengths. I believe, though, that a team should deploy to production as
often as it make *business sense*, not necessarily at the end of each
iteration. It could be the case that there isn't enough business value
accrued to release for several iterations. It could be that a single
story built in a few days is important enough to release on its own.

As for releasing every iteration, I don't think that's a bad thing. I
would suggest, though, that we stop calling that a sprint or iteration
and start calling it a release. :)

> If the team does not take their own Sprint-commitments seriously, you
> could try publishing their roadmap outside (closer to the customer).
> That oughta drive up expectations a bit, and perhaps team spirit will
> follow (communicated properly, of course)?
>

Ah, the Customer. That's where we get into a grey area. This client is
still using a horizontal "layered" team approach for product their
development as opposed to feature teams. The Product Owners are
essentially existing line managers. I'm told that there's a real
internal Customer, but it's a mythical beast that cannot be seen by
human eyes. :)

Dave...

[Yves Hanoulle]

2010/4/22 Dave Rooney <davero...@gmail.com>

Hi Thomas,

On 04/22/2010 03:10 AM, Thomas Ferris Nicolaisen wrote:

Just to be sure, do you deploy to production at the end of every sprint?
 

No, not to production.  This group is one of many teams working on wireless telecom gear.  They won't release anything to production, i.e. that little building at the bottom of a cell tower, for quite some time.

Anyhow, I believe an environment where you can't deploy each feature
to prod upon completion is a big minus for Kanban,
 

I feel that way for *any* process! :)

We've got two week timeboxes here, cause there's some ancient
tradition that deployments should happen every two weeks. Without
having thought too much about it, I reckon that having sprint lengths
following deployment frequency is a good thing.
 

I fully agree with the shortest economical iteration and release lengths.  I believe, though, that a team should deploy to production as often as it make *business sense*, not necessarily at the end of each iteration.  It could be the case that there isn't enough business value accrued to release for several iterations.  It could be that a single story built in a few days is important enough to release on its own.

Yes and no.

There is also business value in delivering small changes

that means that the users learn the new functionality on the job, without having to much big changes.

The longer you wait to go to production, the harder it usually is for user to make a switch.

The website flickr releases live multiple times a day.

After all these years I can't really say I saw changes happening.

Yes probably because a lot is back end changes, I'm sure it's also because the changes they make are very small.

(and I don't even use that application every week)

 

As for releasing every iteration, I don't think that's a bad thing.  I would suggest, though, that we stop calling that a sprint or iteration and start calling it a release. :)

I like iteration and release, so you can make the difference if you release yes or no.

Calling smething a release where everyone knows it is not going to be released, hurts in my eyes the proces.

 

If the team does not take their own Sprint-commitments seriously, you
could try publishing their roadmap outside (closer to the customer).
That oughta drive up expectations a bit, and perhaps team spirit will
follow (communicated properly, of course)?
 

Ah, the Customer.  That's where we get into a grey area.  This client is still using a horizontal "layered" team approach for product their development as opposed to feature teams.  The Product Owners are essentially existing line managers.  I'm told that there's a real internal Customer, but it's a mythical beast that cannot be seen by human eyes. :)

maybe you need new glasses?

;-)

[Thomas Ferris Nicolaisen]

> No, not to production.  This group is one of many teams working on wireless
> telecom gear.  They won't release anything to production, i.e. that little
> building at the bottom of a cell tower, for quite some time.

Ah, so it's the
shipping-hardware-with-software-on-it-some-time-in-the-distant-future
environment..

> I fully agree with the shortest economical iteration and release lengths.  I
> believe, though, that a team should deploy to production as often as it make
> *business sense*, not necessarily at the end of each iteration.  It could be
> the case that there isn't enough business value accrued to release for
> several iterations.  It could be that a single story built in a few days is
> important enough to release on its own.

Yes, if you are talking about hardware being shipped with software,
one sprint would be a bit seldom. If your hardware has update
possibilities (like a Logitech QuickCam software update) it's
different, but hardware which is expected to work indefinitely
straight out of the box is a different manner.

I think the clue is in emulating real releases as much as possible
(and like I see Yves just wrote, don't call it a release, call it
milestone or something). Have some ceremony around it, perhaps drag in
some external testers to try out the emulators or testing devices. Do
product demos in front of the whole department/company. Serve cake,
and go out for beer.

I again recommend having a look at Tandberg's slides for how they stay
as agile as they can in spite of shipping hardware:
http://www.pvv.org/~oma/ProductDevelopment_Feb2010_LeanMeetup_public.pdf


Switching topic a bit: Regarding business decisions and releasing.
I've come to think that *releasing* software is a purely technical
decisions that should be made by developers, just like any other
technical practice. Enabling features is a business decision, which
can be done whenever, completely disconnected from release. If the
developers think it's feasible to deploy/release once a day, go ahead
(as long as they can guarantee stability and backward-compatibility).
As long as business can decide when a feature is *enabled*, they
should be happy.

I know the above is not technically feasible some times (like in
Dave's), and sometimes you can't not change the product/service by
doing a release. But if you can't, I think it's a sign of poor
architecture, poor backward-compatibility, and poor versioning. If you
can't switch to using an old version of your Blog-comments engine
without rebuilding and redeploying your blog, perhaps you should
consider a more plugin-based architecture.

[Ilja Preuß]

2010/4/21 Dave Rooney <davero...@gmail.com>:

> A team that is approaching the end of their 10th 3-week sprint has, yet
> again, a couple of stories that won't be completed.

Do you mean this happened every of the 10 sprints?

How did they come up with the number of stories to plan for the sprint?

> They don't seem to have
> a sense of urgency about the incomplete stories, with an apathetic shrug.
>  The Product Owner and ScrumMaster share that apathy.
>
> So, for this team timeboxes mean nothing.  If there is no value in the
> Sprint timebox, then Sprints should be abolished and a pull model like
> Kanban should be established.
>
> Discuss.

- the main purpose of the sprint timebox is *not* to create a sense of urgency
- if the PO shows apathy, that's an impediment that just got surfaced
by using timeboxes. Using Kanban won't remove that impediment.
- according to the Scrum guide, a team commits to a sprint goal, not
to stories. If they notice that they can't finish all stories, they
renegotiate with the PO on how to change the stories in the sprint so
that the goal still can be accomplished.

Cheers, Ilja

[Dave]

Would it be useful to ask what problem(s) is (are) solved by time-
boxing? If a team/organization has that (those) problem(s), then maybe
time-boxing is a good technique in that situation. Otherwise, we might
consider a different technique.

IMHO getting business value delivered is the main goal. If the
impediments to that goal are such that time-boxing offers a practical
way to keep the work moving, then let's use time-boxing. If the
impediments are different, then let's do what's practical to keep the
work moving. (The problems mentioned in the original post don't really
seem to speak to pros/cons of any particular method, though. If people
just don't care about what they're doing, changing the process won't
make any difference.)

I've found that it's often helpful to focus on continuous flow whether
explicit time-boxes are part of the process or not. Stopping and
starting seems to create process waste. (I think the Lean term for it
is mura - unevenness.) If the stopping/starting inherent in the time-
boxed iterative model is a worthwhile cost to keep the work moving,
then it's okay because there's a payback. If the stopping/starting
doesn't have a payback, then it's just overhead. (I think the Lean
term for that is muda - non value-add activity). I've found that
problems in grooming the backlog upstream of the delivery team are
usually at the root of difficulties in delivering small batches in a
time-boxed process or maintaining continuous flow in a flow-based
process.

I'm not sure what it means to say a team isn't "ready" for kanban.
What does it mean?

Thanks,
Dave

On Apr 22, 4:16 am, Ilja Preuß <iljapre...@googlemail.com> wrote:
> 2010/4/21 Dave Rooney <daveroone...@gmail.com>:

[Jon Kern]

if i were to say it, it would mean that the team plus the surrounding
business environment and client environment, are not able to efficiently
deliver a single feature.

jon
blog: http://technicaldebt.wetpaint.com
twitter: http://twitter.com/JonKernPA

Dave said the following on 4/23/10 11:27 AM:

> I'm not sure what it means to say a team isn't "ready" for kanban.
> What does it mean?
>

[Dave]

Interesting. Seems to me that if the team plus the surrounding
environment can't deliver, then they /are/ ready for something that
can help them deliver - possibly kanban, if that's the appropriate
choice in context.

The implication in the original comment seemed to be (although I'm not
sure of this) that kanban is somehow difficult or "advanced." That
struck me as odd, since kanban is simpler than most other agile-style
methods.

[Jon Kern]

i'll admit to being confused by your assertion.

i only have experience with designing and implementing an MES system for IBM that included supporting Kanban on the factory floor.

my assumption is that for software dev Kanban, the team would be able to work at a fine enough level of granularity to enable delivery of a single "feature" even while other members of the "factory" might be working on 5 other features.

so i guess that led me to assume you better have a really good capability to confidently roll out new features, which might lead me to think you need, as an example, the following:

• the client/product owner has to be ready with the order of features desired (the demand pull)
• the development team needs to have a very good capability of isolating changes
• the software better be well-designed so as to not have crazy dependencies that get in the way
• the software better be fully covered by confidence-inspiring tests
• the QA cycle better be really short and cost virtually NOTHING to conduct it -- or better yet, there is no traditional QA cycle
  

sadly, i have never had a team be that perfect, mind you we have always tried. sometimes it's the client not interested in getting new features, sometimes the QA cycle required too much cost & time to spool it up too frequently.

i am working on a project right now with just a couple of folks, and i am doing the bulk of the work (Rails), and have tried real hard to have a good set of tests (cucumber, rspec, etc) by practicing/learning TDD. So far, this is the closest I have come to being able to deliver single features in a confident manner without a lot of pomp and circumstance.

so, i'd be delighted to learn that there is an easier way to instantly deliver features than what i have experienced on large projects. i would love to experience working with such a team.

jon
blog: http://technicaldebt.wetpaint.com
twitter: http://twitter.com/JonKernPA

Dave said the following on 4/24/10 11:24 AM:

[Thomas Ferris Nicolaisen]

I agree with Jon on those points.. But perhaps you could implement a
fake Kanban system where features are delivered only into a QA/staging
area upon completion. Granted, you might need some kind of stable
branch where "completed" features go to mature and undergo QA, and
this stable branch could be pushed into production periodically (the
tedious part is that all the fixes in stable branch have to be merged
back to the development branch).

When I think about it, the above is how we (and probably many others)
do critical fixes and bugs.

It ain't Kanban, but it gives the team a place where they can minimize
WIP. They will have to deal with fixes in the stable branch, but
that's a cost that might grow smaller over time as the team matures
with good tests and DoD-discipline. The next steps are then to make QA
superfluous, increase deployment frequency and do more automation.
Perhaps one day one can reach true Kanban this way.

Related note, this is a pretty cool desciption/experience of
Kanban-like environment:

http://timothyfitz.wordpress.com/2009/02/10/continuous-deployment-at-imvu-doing-the-impossible-fifty-times-a-day/

[Michael Feathers]

On Wed, Apr 21, 2010 at 11:56 AM, Charlie Poole <cha...@nunit.org> wrote:
> I'm more experienced in timeboxing than in a Kanban approach, but
> it feels to me like this team is not ready for Kanban. Folks with more
> experience may see it differently, but I view Kanban as a more
> advanced approach that many teams should really not try. At least
> with timeboxing, we are highlighting the failure to deliver at the end
> of each iteration.

I echo that concern. I think that there are so many good lessons a
team can learn from the discipline of iterations.

[Dave Rooney]

On 04/25/2010 12:02 PM, Michael Feathers wrote:
> On Wed, Apr 21, 2010 at 11:56 AM, Charlie Poole<cha...@nunit.org> wrote:
>
>> I'm more experienced in timeboxing than in a Kanban approach, but
>> it feels to me like this team is not ready for Kanban. Folks with more
>> experience may see it differently, but I view Kanban as a more
>> advanced approach that many teams should really not try. At least
>> with timeboxing, we are highlighting the failure to deliver at the end
>> of each iteration.
>>
> I echo that concern. I think that there are so many good lessons a
> team can learn from the discipline of iterations

I agree as well. The team in question has just started their 10th
sprint, and there just doesn't seem to be a sense of urgency to get work
done.

The work itself is on wireless phone equipment, and it still has over a
year to go before release. Historically, the development teams worked
at a comfortable pace until it dawned on everyone that they weren't
going to hit the projected ship date. I seem them doing the same thing,
except that they are able to see it sooner (which is good). Before Dale
jumps in and gives me a shake :), I do realize that what I say doesn't
matter - the team has to believe that they need to get to "done". I'm
leading that horse to the water, and it now just has to realize that
it's thirsty.

Dave...

[Michael Feathers]

I've thought of a training exercise that I haven't put into practice
yet, but I think it would be great to drive the point home. Solve a
problem in iterations.. a real coding and analysis problem. The first
iteration is 2 hours, the second is one. The third is a half hour,
the fifth is fifteen minutes.. the sixth is 7.5.

Could be interesting. Not sure 0.5 is the right increment. Will have
to try it out.

Michael

[Yves Hanoulle]

2010/4/25 Michael Feathers <michael....@gmail.com>

and what do you want to learn them by 0,5 the time?

 

Michael

[Mark Levison]

It doesn't seem timeboxing or not is really part of the problem. If we had started this conversation with a team didn't use timeboxes and was having this problem would the situation seem any different? I doubt it. The deeper issue is understand what motivates this team, where does their lassitude come from?

Maybe we need a round or two of Resistance as a Resource :-)

Cheers

Mark

		Mark Levison | Agile Pain Relief Consulting | Agile Editor @ InfoQ Blog | Twitter | Office: (613) 862-2538 Recent Entries: Self Inflicted Agile Injuries, Why use an Agile Coach

[Sean Chambers]

To add my own experiences to the conversation. 

My team is struggling with this somewhat as well. I've noticed that as a result of us improperly identifying iteration goals, the team(s) then exhibit this behavior. 

We have goals but they're not Visible enough to get people rallying behind completing the iteration goals. 

Could that possibly be the underlying cause here? If so, what is everyone else doing to keep iteration goals visible? Large notecards on a board perhaps?

Sean

[Dale Emery]

Hi Sean,

To add my own experiences to the conversation. 

My team is struggling with this somewhat as well. I've noticed that as a result of us improperly identifying iteration goals, the team(s) then exhibit this behavior. 

We have goals but they're not Visible enough to get people rallying behind completing the iteration goals. 

Could that possibly be the underlying cause here? If so, what is everyone else doing to keep iteration goals visible? Large notecards on a board perhaps?

Some things I've seen that help:

- Supplement each story with precise, clarifying examples--as many as are needed to give a reasonable definition of "done."

- Express the examples as automated acceptance tests.

- Run the acceptance tests as soon as there is something to test, and for every change thereafter.

- Post test results visibly at all times.

I've also seen this done without automation, with similarly good results. I've been surprised to discover just how motivating it is to have real clarity about the goal. (Looking back, I don't remember why I was surprised. It seems obvious in retrospect.)

[Dave]

To Jon, Thomas, Michael, and Dave R:

At first I was a bit surprised at your reaction to my comment about
kanban, but I think I understand where you're coming from. In reading
through your replies, I noticed that you appeared to be looking at the
world from the perpective of the developers; you made the assumption
(apparently) that if "kanban" were to be introduced to a development
team, others in the organization such as business stakeholders, QA,
and production support would somehow be "external" to that. I found
this surprising. Maybe I shouldn't have.

I never said "instantly." I said "possibly kanban, if that's the
appropriate choice in context." What Jon did in his reply was to list
the key success factors that would have to be present in that context.
Good. There's no disagreement with any of that on my end.

What I obviously did not communicate clearly is that I assume those
success factors would have to be in place, or that we would be working
to move the organization toward that state. When I go into an
organization to help them improve their delivery process, I try to
deal with the end-to-end delivery process and not just the software
development activities. That isn't always what the client wants, but I
prefer it when we can approach it that way.

I think kanban is a pretty simple model. I'm at a loss to see why you
think it's complicated or hard to learn. Even with novice agile teams,
and even when using a time-boxed process model (as on my current
engagement), I prefer to use a kanban-style card wall. It seems to
make sense intuitively to team members and visitors to the team room.
Usually it doesn't need any explanation at all. It's also easy to
extend beyond the boundaries of the one team, if/when the organization
is ready to do that.

Even if the best you can do in a given organization for the moment is
to help a given development team with the work they do, and you don't
have a mandate to deal with the end-to-end process, a flow-based
approach may be appropriate. I don't think we should just assume that
time-boxing is the only way to solve delivery problems. I'd rather
think that we have more than one tool in our toolkit. The appropriate
approach depends on the circumstances.

Cheers,
Dave

[George Dinwiddie]

Hi, Dave,

Dave wrote:
> I think kanban is a pretty simple model. I'm at a loss to see why you
> think it's complicated or hard to learn. Even with novice agile teams,
> and even when using a time-boxed process model (as on my current
> engagement), I prefer to use a kanban-style card wall. It seems to
> make sense intuitively to team members and visitors to the team room.
> Usually it doesn't need any explanation at all. It's also easy to
> extend beyond the boundaries of the one team, if/when the organization
> is ready to do that.

I don't recall when and where I first was introduced to card walls, but
I'm sure that it was before I heard about kanban and queue-limited
process models.

> Even if the best you can do in a given organization for the moment is
> to help a given development team with the work they do, and you don't
> have a mandate to deal with the end-to-end process, a flow-based
> approach may be appropriate. I don't think we should just assume that
> time-boxing is the only way to solve delivery problems. I'd rather
> think that we have more than one tool in our toolkit. The appropriate
> approach depends on the circumstances.

Exactly. Unfortunately I've had some "kanban is better than scrum"
colleagues tell me point blank that it's not a tool, but a belief system
(e.g., http://tech.groups.yahoo.com/group/leanagile/message/4726). I
find your comments much more conducive to conversation. Unfortunately,
the conversations still contain baggage from past non-conversations.

I hope that we can make this list free of such problems.

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[Dave]

George,

It's a relief to know the problem wasn't simply that I had forgotten
English. I feared that was the case, since nothing I wrote seemed to
be understood at all.

Of course people were using card walls long before anyone thought
about applying lean principles to software development. When I used
the phrase "kanban-style card wall" what I meant was that there are
columns for value-add activities, and just in front of each of those
is a buffer or WIP column. I label those types of columns in
contrasting colors to make the difference visual. People pull from the
buffer in front of the activity they're about to perform, and push
their results in the next buffer. The organization of the card wall is
based on those lean concepts, often associated with "kanban." I may be
out of step with the discussion, because when I think about "kanban"
I'm thinking of the general definition and not necessarily the
adaptation that folks like Karl and David have been crafting for
software development work. So, I'm thinking about one station pulling
from the previous station on the line (loosely). I like the card wall
to reflect that model.

I've found that software development work tends to fall into a "hybrid
push-pull" system, which is one of the typical variants of kanban in
lean manufacturing. I know Karl and the other guys want to see a pure
pull system, but I think there would have to be substantial changes in
conventional assumptions about organizational structure and other
business factors before that will be realistic. If that were possible,
it would imply a lot of other very good things about the way
businesses were run! But not this year.

The difference between that and a conventional agile card wall is that
the concepts of WIP, WIP limits, pull, and push are explicit. I think
that's a minor difference, but it seems to be helpful. When people
look at a conventional card wall and see that one of the columns is
empty, they might think nothing of it. When they look at a kanban-
style card wall and they see that one of the buffers is empty, it sets
off an alarm. They ask, What will happen when someone is ready to pull
work from that buffer? When people look at a conventional card wall
and see that one of the columns is jammed full of cards, they might
remark that the team has a lot of work to get done. When they look at
a kanban-style wall and see more cards in an activity column than the
WIP limit specifies, they immediately ask why the WIP limit was
exceeded. Their attention is drawn upstream in the process to discover
the cause. When people see cards piling up in one of the buffers, they
immediately see there's a bottleneck in the process, and it's obvious
what the team needs to do to keep the work flowing. This doesn't seem
to happen naturally with a conventional card wall; it seems to take
some discussion to get to the point that people realize what's going
on with the work flow.

It's not really a dramatic difference, but it seems to affect people
differently when they look at the board. Maybe it has something to do
with psychology, but that's not my field. I just allow myself to be
guided by what works vs. what doesn't work. Not very "scientific," I
guess. But if I'm not a psychologist, I'm not a scientist, either.

A kanban-style board looks a bit like a series of hand-offs, and some
(immature, IMO) teams do treat it that way, but it doesn't have to
represent hand-offs; it can just represent states that the work passes
through on its way to Done. The same team members can work on anything
they wish. I like to see people start to pick up tasks outside their
official job descriptions and begin to become generalizing
specialists.

Another cool thing about this is you can take the view of the work
back by a level of abstraction and show how the development team fits
into the larger delivery process. Here it becomes a tool that exposes
where the biggest delivery problem really is. It also shows the impact
of dependencies between teams and between agile and non-agile work
activities. In my experience, the biggest delivery problem is rarely
the developmen team or QA team. Those are the points in the process
where management sees smoke, but they aren't where the fire is
located. Kanban is a simple tool for making this visible to management
so that when they engage services from people like us, they're asking
for the right sort of help. This relates to the idea of the weakest
link in the chain; if you strengthen the development or testing team,
and it isn't the weakest link, then the improvements will have no
impact on the overall delivery process, and the improvement initiative
will fizzle. I don't know about you, but I've seen many teams ramp up
with agile practices and learn to work very effectively, only to have
the whole initiative quashed by management because it doesn't have any
impact on the overall process. It's because we've strengthened the
second-weakest or third-weakest link in the chain.

But this thread is supposed to be about time-boxing. Kanban is
orthogonal to that topic.

IMHO time-boxing is useful to help organizations break out of
complicated, linear processes in which people work in silos and depend
on indirect communication, such as documents, to get things done. It's
great for breaking out of Meeting Hell. I've often used time-boxing to
help people focus on value and flow. That might sound odd to a kanban
enthusiast, since the time-boxes by definition create mura (uneven
flow). They create batches, and the iteration ceremonies cause
stopping and starting. The thing is, if the organization is so locked
into a linear process that they can't even see the problem, they won't
be able to focus on continuous flow anyway, and the cost of time-
boxing will be repaid many times over. And that was the status quo in
organizations when time-boxed approaches started to gain traction in
the industry. Anyway, what I often do is make people stop what they're
doing when the time-box expires.

For instance, say the team is doing short-term planning, like
iteration or sprint planning, and they're sizing user stories (or
equivalent activities under whatever name). (You could just as well
talk about any other activity, too.) Novice teams often extend the
time they spend in sizing or estimating because they think they have
to get it all done in detail before they can move on. When I make the
team stop and they aren't finished, then they complain that they're
going to run out of work in mid-iteration. I assure them they are
right about that, and they need to experience the consequences of
failing to get the sizing done within the time-box. They worry that
they will "fail" in the iteration. I tell them they're right again,
and they will have the opportunity to explore the reasons why when
they have their retrospective.

The conventional assumption is that we should avoid all failures at
all costs. My view is that we should use minor failures as learning
opportunities while keeping work flowing steadily toward Done. I've
never seen the problem repeat itself. The very next iteration, the
team does a lighter-weight version of sizing and gets enough done to
set up their work for the iteration. Usually they do it entirely on
their own. IMHO the reason they do so is that they have experienced
the consequences of their own choices, and they own those
consequences. Time-boxing is a powerful tool for breaking habits like
that at all levels, even with management.

When people say kanban is more "advanced" than time-boxing, they might
be thinking about a pattern that I've seen in some organizations and
teams. As a team practices continuous improvement, they learn to shed
more and more iteration management overhead and it becomes feasible
for them to shorten their iteration length. Once the iteration length
goes down to about one week, teams begin to question the value of the
iteration management overhead and ceremonies. The same techniques that
initially helped them break out of the linear model start to become
overhead that doesn't provide any obvious benefit. That's the stage of
improvement when the team might be ready to dispense with formally-
defined iterations and move to an explicit continuous-flow process.
Since this sort of "kanban"-like thing appears to emerge after
practicing continuous improvement for some time, it can be called
"advanced" in a sense. But I do think a kanban-style system could be
instituted from the very beginning, provided expectations are set
properly, the rest of the organization is engaged appropriately, and
the success factors Jon listed are taken into account. We might also
use time-boxing, or we might not, depending on the circumstances. In
any case, I think the success factors are relevant to any change
initiative, and they are not "barriers" to approaches other than time-
boxing.

Cheers,
Dave

On Apr 26, 5:08 pm, George Dinwiddie <li...@iDIAcomputing.com> wrote:
> Hi, Dave,
>
> Dave wrote:
> > I think kanban is a pretty simple model. I'm at a loss to see why you
> > think it's complicated or hard to learn. Even with novice agile teams,
> > and even when using a time-boxed process model (as on my current
> > engagement), I prefer to use a kanban-style card wall. It seems to
> > make sense intuitively to team members and visitors to the team room.
> > Usually it doesn't need any explanation at all. It's also easy to
> > extend beyond the boundaries of the one team, if/when the organization
> > is ready to do that.
>
> I don't recall when and where I first was introduced to card walls, but
> I'm sure that it was before I heard about kanban and queue-limited
> process models.
>
> > Even if the best you can do in a given organization for the moment is
> > to help a given development team with the work they do, and you don't
> > have a mandate to deal with the end-to-end process, a flow-based
> > approach may be appropriate. I don't think we should just assume that
> > time-boxing is the only way to solve delivery problems. I'd rather
> > think that we have more than one tool in our toolkit. The appropriate
> > approach depends on the circumstances.
>
> Exactly.  Unfortunately I've had some "kanban is better than scrum"
> colleagues tell me point blank that it's not a tool, but a belief system

> (e.g.,http://tech.groups.yahoo.com/group/leanagile/message/4726).  I

[Dave]

George,

I just followed the link to the leankanban list you posted, and saw
the "belief system" thing came from Alan. Yeah. He's kind of a zealot,
isn't he? At least, he comes across that way.

Dave

On Apr 26, 5:08 pm, George Dinwiddie <li...@iDIAcomputing.com> wrote:

> Hi, Dave,
>
> Dave wrote:
> > I think kanban is a pretty simple model. I'm at a loss to see why you
> > think it's complicated or hard to learn. Even with novice agile teams,
> > and even when using a time-boxed process model (as on my current
> > engagement), I prefer to use a kanban-style card wall. It seems to
> > make sense intuitively to team members and visitors to the team room.
> > Usually it doesn't need any explanation at all. It's also easy to
> > extend beyond the boundaries of the one team, if/when the organization
> > is ready to do that.
>
> I don't recall when and where I first was introduced to card walls, but
> I'm sure that it was before I heard about kanban and queue-limited
> process models.
>
> > Even if the best you can do in a given organization for the moment is
> > to help a given development team with the work they do, and you don't
> > have a mandate to deal with the end-to-end process, a flow-based
> > approach may be appropriate. I don't think we should just assume that
> > time-boxing is the only way to solve delivery problems. I'd rather
> > think that we have more than one tool in our toolkit. The appropriate
> > approach depends on the circumstances.
>
> Exactly.  Unfortunately I've had some "kanban is better than scrum"
> colleagues tell me point blank that it's not a tool, but a belief system

> (e.g.,http://tech.groups.yahoo.com/group/leanagile/message/4726).  I

[Thomas Ferris Nicolaisen]

Hi Dave,

I think this is a great explanation of Kanban and its values that I
will definitely use next time I try to get it in place.

I didn't think we have opposite views. I'm fairly rookie when it comes
to Kanban, and perhaps I view it to be more exotic than it deserves.
For example, I don't know if Kanban strictly requires that completion
includes that something is brought to production (I assumed yes, which
I think now was wrong). I've heard others saying that Kanban is much
simpler than Scrum, for instance, and I can understand why. The
curriculum is fairly small, after all.

I did suggest to some of our teams to try Kanban-like-boards last
year, and some teams did, but after some time people couldn't be
bothered with updating the boards anymore, and just stuck to the issue
tracker. The lack of pull disabled the flow through the system, and
build-up of queues were blamed on outside/political causes beyond our
control.

I don't think this is a fair experience report, because I didn't teach
it well, and I didn't put pressure on the correct places (I didn't
know where to push).

We come from a chaotic/pragmatic environment. I think Kanban could be
a great way to go for us once we overcome our current organizational
problems.

Perhaps it is different for teams that come from traditional/waterfall
environments? It could be easier to go from budget-driven iterations
to Sprints, and then evolve into Kanban, like you say.

Certainly for greenfield-projects/organizations, I'd like to start off
with Kanban right away.

[Dave]

Hi Thomas,

This bit

>after some time people couldn't be
bothered with updating the boards anymore, and just stuck to the issue
tracker.

doesn't sound like a problem with kanban or scrum or whatever, it just
sounds like the team wasn't on board with the idea of using
information radiators to manage their work. People with a lean
background call "information radiators" "visual management," but it's
the same general idea. I don't think yours was the first project where
this has happened. It's going to be hard to get very far with agile
or lean thinking if we can't get people to think of the visual,
tactile tools as "primary" and the electronic tools as "secondary."
It's a big shift in mindset in some cases.

Cheers,
Dave

On Apr 27, 10:02 am, Thomas Ferris Nicolaisen <tfn...@gmail.com>
wrote:

> ...
>
> read more »

[Thomas Ferris Nicolaisen]

Yup, we've got bigger problems :)

On a related note, someone tweeted me this explanation/definition of
Kanban, which some of you may find useful:

http://finance.groups.yahoo.com/group/kanbandev/message/6954

[Mark Levison]

Dave - one thing that has bothered me in this conversation. Make changes around time boxing, kanban (small 'k'), etc are about the most drastic changes we can make in the way that a team works. Its a bit like turning the heat on the stove to 'HI', it might work well but we don't know if its necessary and if it doesn't have the desired effect undoing it would be costly.

Thinking using the tools from some of Joseph Pelrine's workshops I'm wondering what other smaller changes you might consider, before such a big change. At its heart the question appears to be, why is the team behaving this way?

Changing systems before we have a good model to understanding their behavior appears to be jumping the gun.

Cheers

Mark

[Dave Rooney]

Which Dave... Nicolette or Rooney?

[George Dinwiddie]

Dave wrote:
> George,
>
> I just followed the link to the leankanban list you posted, and saw
> the "belief system" thing came from Alan. Yeah. He's kind of a zealot,
> isn't he? At least, he comes across that way.

Sometimes he comes across that way to me, and sometimes I think he's
just in hard-sell mode, and sometimes I don't know what to think.

I hate to flip the bozo bit on anyone, but I've pretty much given up
trying to have a dialog with Alan. I've got a theory that he's an
output-only device.

<sigh>It makes me feel bad about myself to come to that conclusion. I
don't seem to have what it takes to do anything more productive.</sigh>

[Dave]

Mark,

Yes, it would be jumping the gun. It would be like the old saying
about the guy who has a hammer and thinks everything looks like a
nail. A lot of the "discussion" around scrum vs. kanban seems to be
about whose hammer is shinier, and not about how to identify and solve
each client's unique problems.

When you say "big" and "small" change, doesn't that assume something
about the current state of the team or organization? Every team and
every organization isn't at the same starting point, and every team
and every organization isn't aiming for the same target.

That only underscores your point that we ought to understand the
problem and the goal before we start recommending changes. But the way
you stated it sounds as if you're making some broad assumptions about
which particular changes are likely to be easier or harder. IMHO that
will vary by situation.

I'm also a Pelrine fan and I'm looking forward to the publication of
his book. I use his material quite often when working with clients.

Dave

[Dave]

Getting back to your original message...

What's the root cause of the apathy, especially on the part of the PO?
IMHO that's going to be key to success, whether the team continues to
use iterations or tries any other sort of process framework. I doubt
the problem can be solved by tweaking the process.

Cheers,
Dave

On Apr 21, 11:31 am, Dave Rooney <daveroone...@gmail.com> wrote:
> A team that is approaching the end of their 10th 3-week sprint has, yet

> again, a couple of stories that won't be completed.  They don't seem to

> have a sense of urgency about the incomplete stories, with an apathetic
> shrug.  The Product Owner and ScrumMaster share that apathy.
>
> So, for this team timeboxes mean nothing.  If there is no value in the
> Sprint timebox, then Sprints should be abolished and a pull model like
> Kanban should be established.
>
> Discuss.
>

> --
> Dave Rooney
> Westboro Systems
> Web:http://www.westborosystems.com
> Blog:http://practicalagility.blogspot.com
> Twitter: daverooneyca

[Mark Levison]

On Tue, Apr 27, 2010 at 12:35 PM, Dave <daveni...@gmail.com> wrote:

Mark,

When you say "big" and "small" change, doesn't that assume something
about the current state of the team or organization? Every team and
every organization isn't at the same starting point, and every team
and every organization isn't aiming for the same target.

My only assumption - to my knowledge- was that the team is working iteratively. My point was removing the timeboxes would be a big change.

 

I'm also a Pelrine fan and I'm looking forward to the publication of
his book. I use his material quite often when working with clients.

Well he started a discussion group for the book and has posted some material (maybe on Ning?), but I haven't taken the time to look. I'm not going to complain about how long he's taken to get his book done since my own hasn't gotten off the ground yet.

Cheers

Mark

[Mark Levison]

On Tue, Apr 27, 2010 at 12:47 PM, Dave <daveni...@gmail.com> wrote:

Getting back to your original message...

What's the root cause of the apathy, especially on the part of the PO?
IMHO that's going to be key to success, whether the team continues to
use iterations or tries any other sort of process framework. I doubt
the problem can be solved by tweaking the process.

I wonder what motivates the PO? The team? What have they received rewards/praise for in the past? What has been ignored?

[Dale Emery]

Hi Mark,

Changing systems before we have a good model to understanding their behavior appears to be jumping the gun.

I agree if you're talking about large changes.

For small changes... Making small changes (or trying to) is a great way to learn about the larger system. Resistance is an indication of structure (organizational, physical, technical, social, interpersonal, personal). Probably amplification is an indication of structure, too. If a small change triggers an out-of-proportion response, there's structure in there somewhere.

As coaches, we probe with small changes all the time. Like "what if" thought experiments. "What if we tried switching pairs more often?" This may or may not result in switching pairs more often. It always yields information, which helps us to revise our model of the system.

[Dale Emery]

Hi Mark,

I wrote:

I agree if you're talking about large changes.

For small changes...

Eeep! I see you were already distinguishing between large and small changes. My apologies. I plead caffeine deprivation.

Dale

[Dave Rooney]

The original message was intended to provoke discussion. I'd say that
was successful. :)

My opinion is that a good part of the problem is that the product's
release horizon is, well, beyond the horizon. This is being addressed
by senior management for work on existing products, but will likely be a
problem for new ones.

Another significant issue is that 'Agile' is being projected onto the
existing organizational structure that uses horizontal component teams
rather than vertical feature teams. When I brought this up I was
assured that they do indeed use feature teams. I then described what I
meant and it wasn't really the same. I suspect we're into terminology
mismatch akin to "unit test". Perhaps GeePaw could donate another term
like "microtest" to help us out. :)

Anyway, projecting Agile in this way is similar to the projections of a
3-D spherical Earth onto a 2-D map. Every projection is flawed in some
way, with significant distortions.

Changing organizational structure sure as hell isn't "tweaking the
process". However, the message that has been provided to executive
management is that they need to use cross-functional feature teams, and
to perform the agile migration at a product level rather than pilot
teams withing a product group. If they can actually do that, then I see
some of these issues being resolved by virtue of having more visible and
accessible product management than they have now.

As for the process itself, I've been shot down in attempts to get one of
the teams to do cleanup work during the last couple of days of a sprint
rather than starting new stories that won't be completed during the
timebox. One area that I would see Kanban making a hidden issue very
visible is with verification. Limiting WIP, especially for
Verification, would highlight to everyone and anyone that they simply
don't have anywhere near adequate capacity at that stage.

Thanks!

Dave...

[Yves Hanoulle]

2010/4/27 Mark Levison <ma...@mlevison.com>

Dave - one thing that has bothered me in this conversation. Make changes around time boxing, kanban (small 'k'), etc are about the most drastic changes we can make in the way that a team works. Its a bit like turning the heat on the stove to 'HI', it might work well but we don't know if its necessary and if it doesn't have the desired effect undoing it would be costly.

I understand what you mean.

At the same time, when I want people to try agile, I'm asking them to change radically.

(a lot of things are different)

so then not wanting to undergo other big changes feels wrong to me.

it's like, yes big changes are good, if it are the big changes I know.

  

that is not the message I want to bring...

I like "the medium is the message."

doing a big change might tell people: look I'm serious there is something big wrong with the way we work.

yes I know a small change might have that effect on a team

y

y 

[Mark Levison]

Part of what bothered me and I don't think for a second Dave was going to do this.

I hear many of the Kanbanista's say how they were working with a team failing at Scrum, so they introduced Kanban and magic ensued and it worked. Did they really examine the situation well? Was Scrum the problem or was they there something deeper.

Cheers

Mark

[Dave]

Ah, the -ista suffix.

On Apr 27, 2:39 pm, Mark Levison <m...@mlevison.com> wrote:
> On Tue, Apr 27, 2010 at 2:27 PM, Yves Hanoulle <Mail...@objectsoft.be>wrote:
>
>
>
>
>
> > 2010/4/27 Mark Levison <m...@mlevison.com>

[Charlie Poole]

Personally, I've worked with teams failing at XP and "introduced XP"
and it worked.
I've also worked with teams failing at Scrum and "re-introduced Scrum"
(with XP engineering practices) and it worked. I'm sufficiently vain
to imagine that I could do the same with teams failing at Kanban - or
kanban.

My evidence is only anecdotal, but I suspect that what a team calls
what it is doing has little influence on success or failure.

Charlie