Kanban Vs Scrum
Rathna
When does one choose to go with Kanban? Can someone please compare
Scrum and Kanban and explain when to use what?
Many thanks!
Rathna.
George Dinwiddie
To oversimplify, Kanban is very similar to scrum, but limits work in
progress explicitly limiting parallel work queues rather than by
timeboxing. In practice, Kanban seems to work better if you establish
regular rhythms and Scrum seems to work better if you limit work in
progress, even within the Sprint. This makes them very similar, but
with slightly different emphasis.
In my experience, a Kanban-ish approach seems to work better than a
Scrum-ish approach when the Product Owner has a hard time prioritizing
the work a sprint or two ahead of development. When the PO is being
whipsawed by other parts of the organization, or when the work has a
large research component such that it's hard to know what you want next
until you see how this part is turning out, then the regular rhythm of
Scrum can be hard to maintain. I would still suggest maintaining some
rhythm(s) (which don't have to be synchronized) with regular evaluations
of value accomplished and regular retrospectives.
- George
--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------
Ron Jeffries
> I know Scrum; and also know the theoretical definition of Kanban.
> When does one choose to go with Kanban? Can someone please compare
> Scrum and Kanban and explain when to use what?
When does one choose to have dinner, and when does one have a
potato?
Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
For me, XP ain't out there, it's in here. -- Bill Caputo
Andy Brandt
On Mar 9, 3:53 am, Rathna <rathnaku...@gmail.com> wrote:
> I know Scrum; and also know the theoretical definition of Kanban.
>
> When does one choose to go with Kanban? Can someone please compare
> Scrum and Kanban and explain when to use what?
Apart from the fact that Kanban seems to be more fashionable in some
circles now (together with Lean) than Scrum my 2c worth would be that
Kanban is good for small chunks of work that have to go through a very
clear and well defined process before they are considered done. Well
defined means also that this process is made of distinct steps with
known capacity - think of it as of a series of machines on an assembly
line. That in my experience makes it very good for bug fixing on live
systems or other types of maintenance-like work provided the release
cadence (rythm) is rather short and release overhead is low (web apps
for example). For example, we have used Kanban last year successfully
for post-deployment changes on a large web system where main project
work was already done.
Another place where I recommended using Kanban was where business was
so set up that requests from clients had absolute priority over
regular product development work done in Scrum. There a part of the
team was selected to be "firefighters" (and it was a rotating
function) to deal with such interrupts and they used Kanban to keep
track of that work.
Hope this helps a bit.
Best regards,
Andy Brandt
http://www.andybrandt.net/
Jens Meydam
On Mar 9, 4:19 am, George Dinwiddie <li...@iDIAcomputing.com> wrote:
> Hi, Rathna,
>
> In practice, Kanban seems to work better if you establish
> regular rhythms and Scrum seems to work better if you limit work in
> progress, even within the Sprint. This makes them very similar, but
> with slightly different emphasis.
That makes a great quote.
> or when the work has a
> large research component such that it's hard to know what you want next
> until you see how this part is turning out, then the regular rhythm of
> Scrum can be hard to maintain.
Isn't that the kind of project where Scrum really shines?
The Sprint backlog allows for discovery.
The timebox forces the closure of work and allows for radical changes
in direction.
Jens
Jens Meydam
I've had a look at your website. You seem to be in favor of keeping
Scrum "pure", yet you have also found value in Kanban.
Why should using a Kanban board instead of a task board and using a
cumulative flow diagram instead of a burndown chart not be compatible
with Scrum?
Because this isn't the way Scrum is described in the Scrum Guide?
Jeff Sutherland himself does not slavishly follow the Scrum Guide. If
we treat the sum of what is in the Scrum Guide as the necessary and
sufficient conditions for calling a process "Scrum" (as opposed to
"ScrumBut"), we risk being more catholic than the pope.
Jens
George Dinwiddie
Jens Meydam wrote:
> Hi George
>
> On Mar 9, 4:19 am, George Dinwiddie <li...@iDIAcomputing.com> wrote:
>> Hi, Rathna,
>>
>> In practice, Kanban seems to work better if you establish
>> regular rhythms and Scrum seems to work better if you limit work in
>> progress, even within the Sprint. This makes them very similar, but
>> with slightly different emphasis.
>
> That makes a great quote.
Thanks!
>> or when the work has a
>> large research component such that it's hard to know what you want next
>> until you see how this part is turning out, then the regular rhythm of
>> Scrum can be hard to maintain.
>
> Isn't that the kind of project where Scrum really shines?
> The Sprint backlog allows for discovery.
> The timebox forces the closure of work and allows for radical changes
> in direction.
It does until the PO has a hard time filling the Sprint backlog and
keeping it static through the sprint. Yes, you could say "Don't do
that." Or you can just work on one thing until it's done while the PO
figures out the next thing. Yes, this reduces the beneficial influence
of a timebox on the development team, but sometimes that's not your
biggest problem.
- George
Jens Meydam
> >> or when the work has a
> >> large research component such that it's hard to know what you want next
> >> until you see how this part is turning out, then the regular rhythm of
> >> Scrum can be hard to maintain.
>
> > Isn't that the kind of project where Scrum really shines?
> > The Sprint backlog allows for discovery.
> > The timebox forces the closure of work and allows for radical changes
> > in direction.
>
> It does until the PO has a hard time filling the Sprint backlog and
> keeping it static through the sprint. Yes, you could say "Don't do
> that." Or you can just work on one thing until it's done while the PO
> figures out the next thing. Yes, this reduces the beneficial influence
> of a timebox on the development team, but sometimes that's not your
> biggest problem.
But why should the Sprint backlog remain static?
Scrum as it is usually described these days assumes there is a backlog
with very small user stories at the top, and the team picks as many
for the next Sprint as it feels able to deliver. The Sprint may be as
short as a week, so they won't pick many stories. The stories are
then decomposed into tasks, some of which may be "discovered" during
the Sprint. The Sprint backlog consists of these tasks and may in
theory change during the Sprint, but since all tasks are related to
small, well understood stories and the stories are supposed to be
stable the Sprint backlog is bound to be relatively stable, too.
However, the first descriptions of Scrum (also by Ken Schwaber) paint
a very different picture. The work is described as risky, there is
insufficient knowledge, the team is operating at "the edge of chaos".
They accept a mission, corresponding to the Sprint goal. Sprints are
1 month long. The Sprint backlog is totally owned by the team and is
a means - along with the burndown chart - to help the team manage its
own work and complete a product increment by the end of the Sprint.
At the beginning of the Sprint the Sprint backlog is filled by the
team with the tasks the team thinks are necessary for reaching the
Sprint goal, but it is not expected to be complete at this point and
the team may in fact change its mind in the middle of the Sprint and
radically change its contents. What remains constant is the mission,
the Sprint goal.
Below I quote the inimitable Jeff Sutherland to further support the
point that Scrum is in fact made for research. :-)
Jens
http://jeffsutherland.com/2008/12/scrum-for-research-projects.html
Recently, a new ScrumMaster from Atlanta pointed out the project in
the photos above is a medical research project at the U.S. Center for
Disease Control. The EPM Solutions blog item by Lisa Grant has a nice
description of how you can cut research time in half and increase
innovation and collaboration with Scrum.
I spent a lot of time this year at Johns Hopkins Applied Physics
Laboratory where they invented GPS and many other innovations for
military projects. The Los Alamos Nuclear Weapons Laboratory uses
Scrum (scary thought). The secret is to timebox a research activity
with clear entry and exit conditions. Often the exit condition is an
answer to a question that will determine the next step in the
research.
If I had to do another Ph.D. thesis, I would definitely use Scrum. I
could cut the time in half and significantly improve the quality.
Andy Brandt
On Mar 9, 10:06 pm, Jens Meydam <jmey...@gmail.com> wrote:
> I've had a look at your website. You seem to be in favor of keeping
> Scrum "pure", yet you have also found value in Kanban.
>
> Why should using a Kanban board instead of a task board and using a
> cumulative flow diagram instead of a burndown chart not be compatible
> with Scrum?
Could you define how you understand "compatible" in this context? I
see Scrum as a tool for a certain set of problems. Kanban is another
tool, that I see as applying to a slightly different but overlapping
set of problems. If we do Kanban, we do Kanban, but let's not call it
Scrum and vice-versa. If we do a hybrid and it works well - great,
let's continue doing it, but it is neither Kanban nor Scrum.
> Because this isn't the way Scrum is described in the Scrum Guide?
> Jeff Sutherland himself does not slavishly follow the Scrum Guide. If
> we treat the sum of what is in the Scrum Guide as the necessary and
> sufficient conditions for calling a process "Scrum" (as opposed to
> "ScrumBut"), we risk being more catholic than the pope.
For me it's just a matter of using labels correctly to describe
things. For example, for a thing I call a fork I expect it to look and
function in a certain way. Have nothing against, say, spoons in
principle, unless someone chooses to call spoons forks. If a fork can
mean anything, then we loose ability to meaningfully use labels
(words) to describe things.
Same here. If Scrum can mean anything then it starts to mean nothing.
Best regards,
Andy
http://www.andybrandt.net/
Ron Jeffries
wrote:
> Same here. If Scrum can mean anything then it starts to mean nothing.
No one is suggesting that Scrum can mean anything. Is it still Scrum
if you draw your burndowns upward? Is it still Scrum if you use a
task or story board?
Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
The fact that we know more today, and are more capable today,
is good news about today, not bad news about yesterday.
George Dinwiddie
Jens Meydam wrote:
> Hi George
>
>>>> or when the work has a
>>>> large research component such that it's hard to know what you want next
>>>> until you see how this part is turning out, then the regular rhythm of
>>>> Scrum can be hard to maintain.
>>> Isn't that the kind of project where Scrum really shines?
>>> The Sprint backlog allows for discovery.
>>> The timebox forces the closure of work and allows for radical changes
>>> in direction.
>> It does until the PO has a hard time filling the Sprint backlog and
>> keeping it static through the sprint. Yes, you could say "Don't do
>> that." Or you can just work on one thing until it's done while the PO
>> figures out the next thing. Yes, this reduces the beneficial influence
>> of a timebox on the development team, but sometimes that's not your
>> biggest problem.
>
> But why should the Sprint backlog remain static?
Because if you keep changing what stories are in and out of the sprint,
then there's no point in /having/ a sprint backlog.
> Scrum as it is usually described these days assumes there is a backlog
> with very small user stories at the top, and the team picks as many
> for the next Sprint as it feels able to deliver. The Sprint may be as
> short as a week, so they won't pick many stories. The stories are
> then decomposed into tasks, some of which may be "discovered" during
> the Sprint. The Sprint backlog consists of these tasks and may in
> theory change during the Sprint, but since all tasks are related to
> small, well understood stories and the stories are supposed to be
> stable the Sprint backlog is bound to be relatively stable, too.
>
> However, the first descriptions of Scrum (also by Ken Schwaber) paint
> a very different picture. The work is described as risky, there is
> insufficient knowledge, the team is operating at "the edge of chaos".
> They accept a mission, corresponding to the Sprint goal. Sprints are
> 1 month long. The Sprint backlog is totally owned by the team and is
> a means - along with the burndown chart - to help the team manage its
> own work and complete a product increment by the end of the Sprint.
> At the beginning of the Sprint the Sprint backlog is filled by the
> team with the tasks the team thinks are necessary for reaching the
> Sprint goal, but it is not expected to be complete at this point and
> the team may in fact change its mind in the middle of the Sprint and
> radically change its contents. What remains constant is the mission,
> the Sprint goal.
I don't care what you do about tasks. I don't generally document those
at all. (And keep forgetting that others spend a lot of time on task
breakdown.) The stories are what count.
> Below I quote the inimitable Jeff Sutherland to further support the
> point that Scrum is in fact made for research. :-)
>
> Jens
>
> http://jeffsutherland.com/2008/12/scrum-for-research-projects.html
>
> Recently, a new ScrumMaster from Atlanta pointed out the project in
> the photos above is a medical research project at the U.S. Center for
> Disease Control. The EPM Solutions blog item by Lisa Grant has a nice
> description of how you can cut research time in half and increase
> innovation and collaboration with Scrum.
>
> I spent a lot of time this year at Johns Hopkins Applied Physics
> Laboratory where they invented GPS and many other innovations for
> military projects. The Los Alamos Nuclear Weapons Laboratory uses
> Scrum (scary thought). The secret is to timebox a research activity
> with clear entry and exit conditions. Often the exit condition is an
> answer to a question that will determine the next step in the
> research.
>
> If I had to do another Ph.D. thesis, I would definitely use Scrum. I
> could cut the time in half and significantly improve the quality.
So? If you're good at what you're doing, then you can make things work.
That has nothing to do with a PO using the hands of the Devs to figure
out what she wants.
But do what you want. I was just answering a question about scrum and
kanban. If you think that scrum is always the answer, go for it. I
don't care to argue with you. I'm just reporting my experience of cases
where teams struggle with timeboxes and going with single-piece flow
seems to help them. And nothing that you or Ken or Jeff says changes my
experiences.
Andy Brandt
On Mar 10, 11:29 pm, Ron Jeffries <ronjeffr...@acm.org> wrote:
> > Same here. If Scrum can mean anything then it starts to mean nothing.
>
> No one is suggesting that Scrum can mean anything. Is it still Scrum
> if you draw your burndowns upward? Is it still Scrum if you use a
> task or story board?
OK, so how you tell if a team is doing Scrum or if it is doing
Kanban?
(Again, to underline it: I have nothing against Kanban.)
Ron Jeffries
wrote:
> On Mar 10, 11:29�pm, Ron Jeffries <ronjeffr...@acm.org> wrote:
>> > Same here. If Scrum can mean anything then it starts to mean nothing.
>>
>> No one is suggesting that Scrum can mean anything. Is it still Scrum
>> if you draw your burndowns upward? Is it still Scrum if you use a
>> task or story board?
> OK, so how you tell if a team is doing Scrum or if it is doing
> Kanban?
> (Again, to underline it: I have nothing against Kanban.)
I don't care if teams are doing Scrum or if they ard doing Kanban. I
care whether they are effective and improving. IMO that is what they
should care about as well.
Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
A man hears what he wants to hear, and disregards the rest. -- Paul Simon
Andrea Tomasini
> Hello, Andy. On Thursday, March 11, 2010, at 8:45:23 AM, you
> wrote:
>
>> On Mar 10, 11:29 pm, Ron Jeffries <ronjeffr...@acm.org> wrote:
>>>> Same here. If Scrum can mean anything then it starts to mean nothing.
>>>
>>> No one is suggesting that Scrum can mean anything. Is it still Scrum
>>> if you draw your burndowns upward? Is it still Scrum if you use a
>>> task or story board?
>
>> OK, so how you tell if a team is doing Scrum or if it is doing
>> Kanban?
>> (Again, to underline it: I have nothing against Kanban.)
>
> I don't care if teams are doing Scrum or if they ard doing Kanban. I
> care whether they are effective and improving. IMO that is what they
> should care about as well.
Aye! Scrum is not a goal is a tool that might help in reaching your goal :-) Which we all hope is do better software faster...
Ciao
ANdreaT
Jens Meydam
> > But why should the Sprint backlog remain static?
>
> Because if you keep changing what stories are in and out of the sprint,
> then there's no point in /having/ a sprint backlog.
You see the sprint backlog as a list of small stories straight from
the Product Owner. I don't mean to say there is anything wrong with
this, but this is not a universal given, either.
Let's suppose there is only one big story, a problem that is to be
solved, and the team has the freedom to choose how to solve this
problem (they are the experts, after all). At the beginning of the
sprint, the sprint backlog is filled with tasks related to the
approach tentatively chosen by the team. What if the team discovers
halfway through the sprint that there is a better way to solve the
problem? They would change the tasks in the sprint backlog, and if
everything goes well, at the sprint review the Product Owner will be
glad that the team has found a better solution that nobody had thought
about before.
> I don't care what you do about tasks. I don't generally document those
> at all. (And keep forgetting that others spend a lot of time on task
> breakdown.) The stories are what count.
As it happens, neither do I. Whenever I can, I define work in terms
that are meaningful to a user, tiny steps towards the final solution.
Sometimes the tiny stories come straight from the Product Owner. More
often, the Product Owner cares about an "epic" (which to him doesn't
look oversized at all), not about tiny stories, so it's up to the team
(perhaps including an expert user) to come up with stories that in sum
give the Product Owner the "epic" that he's waiting for. In this
scenario, small stories take over the role of tasks: they define the
work of the team and are perhaps even under the discretion of the team
and thus can change during the sprint.
> But do what you want. I was just answering a question about scrum and
> kanban. If you think that scrum is always the answer, go for it. I
> don't care to argue with you. I'm just reporting my experience of cases
> where teams struggle with timeboxes and going with single-piece flow
> seems to help them. And nothing that you or Ken or Jeff says changes my
> experiences.
Don't beat me up, please. You possibly missed some irony in my
reply. I will actually take an advanced course on Kanban at the end
of this month, no kidding. However, I see Kanban more as a useful
tool, not as a complete approach to complex work.
Peace!
Jens
Rathna
Jens Meydam
> > Why should using a Kanban board instead of a task board and using a
> > cumulative flow diagram instead of a burndown chart not be compatible
> > with Scrum?
>
> Could you define how you understand "compatible" in this context?
I can describe what I do, and then you can judge for yourself.
I use a Kanban board (Ron Jeffries used the word "story board", which
already sounds a lot more compatible) to track how small pieces of
work flow from development into production. I don't differentiate
steps within the development phase, but once the developers are "done"
features still have to be deployed to the production environment
(which is where I start to count work as "done") and used for real (at
which point it gets interesting from the Product Owner's
perspective). These are discrete phases, and there are certain checks
and activities associated with the transitions between these phases.
I use a cumulative flow diagram to visualize the flow of work. I have
data reaching back eleven months, and I like the long term perspective
the cumulative flow diagram gives me. The phase where we have been
most effective (in terms of measurable value created) can be clearly
identified in the diagram. All lines go up in parallel. During that
phase the work was constantly being informed by feedback from
production (yet from the point of view of the Product Owner, we were
just working on one "story").
If I isolate the part of the diagram that corresponds to the timebox
of the last sprint, pick the line showing the increase in the number
of features deployed to the production environment and turn it upside
down - voilà my burndown chart.
> I see Scrum as a tool for a certain set of problems. Kanban is another
> tool, that I see as applying to a slightly different but overlapping
> set of problems. If we do Kanban, we do Kanban, but let's not call it
> Scrum and vice-versa. If we do a hybrid and it works well - great,
> let's continue doing it, but it is neither Kanban nor Scrum.
That is also Henrik Kniberg's line, but I find it slightly flawed.
Scrum stands for a set of patterns - organizational patterns and
patterns of behavior - that together invariably lead to energized,
productive teams. The "tools" and "techniques" come a distant second.
> For me it's just a matter of using labels correctly to describe
> things. For example, for a thing I call a fork I expect it to look and
> function in a certain way. Have nothing against, say, spoons in
> principle, unless someone chooses to call spoons forks. If a fork can
> mean anything, then we loose ability to meaningfully use labels
> (words) to describe things.
What does a bird look like? Like a robin? Always? The Scrum Guide
is great as a description of the "robin". There should be space for
experimentation and variation. And above all - Scrum Coaches should
be free to say such things without fear for their livelihood. I'm
totally open to the possibility that I just don't fully get it yet and
everything I do differently is just the result of a bloody beginner
fooling around, but I can't accept an atmosphere of fear and dogma.
Jens
George Dinwiddie
Jens Meydam wrote:
> Let's suppose there is only one big story, a problem that is to be
> solved, and the team has the freedom to choose how to solve this
> problem (they are the experts, after all). At the beginning of the
> sprint, the sprint backlog is filled with tasks related to the
> approach tentatively chosen by the team. What if the team discovers
> halfway through the sprint that there is a better way to solve the
> problem? They would change the tasks in the sprint backlog, and if
> everything goes well, at the sprint review the Product Owner will be
> glad that the team has found a better solution that nobody had thought
> about before.
You've just described a very good reason NOT to fill the sprint backlog
with tasks.
I recommend using the stories from the product backlog, or functional
splits from those stories.
> Sometimes the tiny stories come straight from the Product Owner. More
> often, the Product Owner cares about an "epic" (which to him doesn't
> look oversized at all), not about tiny stories, so it's up to the team
> (perhaps including an expert user) to come up with stories that in sum
> give the Product Owner the "epic" that he's waiting for.
In that case, I coach the Product Owner on how to perform that role in a
more competent manner. It really does work better than having the
developers take on that responsibility, defining the detailed behavior
to be delivered.
Jens Meydam
On Mar 12, 1:11 am, George Dinwiddie <li...@iDIAcomputing.com> wrote:
> This is certainly wandering off the topic of Kanban vs. Scrum.
Is it? I thought you were trying to make the point that Scrum is no
good when there is a lot of uncertainty, while Kanban is. As it
turned out, it may just be your favorite way of implementing Scrum
that has a problem with this kind of work.
> > Sometimes the tiny stories come straight from the Product Owner. More
> > often, the Product Owner cares about an "epic" (which to him doesn't
> > look oversized at all), not about tiny stories, so it's up to the team
> > (perhaps including an expert user) to come up with stories that in sum
> > give the Product Owner the "epic" that he's waiting for.
>
> In that case, I coach the Product Owner on how to perform that role in a
> more competent manner. It really does work better than having the
> developers take on that responsibility, defining the detailed behavior
> to be delivered.
I used to work with "Product Owners" who had the time and skill to do
that. But that was in commercial software development. I now work on
internally used software, for a small financial company (around 30
employees), and the PO is the CEO. To make the CEO the PO was in fact
the recommendation of a Scrum Trainer, and I still find it is the best
solution. The CEO is strongly involved with marketing and has a keen
sense of what constitutes value for our customers - the real ones, the
external customers. But he doesn't have the time and patience for the
tiny details. So you tell me to "coach him to perform his role in a
more competent manner"? Sounds to me like a career-limiting move.
We work closely with expert users, one of whom would make a decent PO
(and in fact has a backlog), but only for one department. I try to
make sure that the developers listen to the users and that the users
are "driving" the development of the details, wherever possible.
Having users on the team is an XP practice, isn't it? By the way, our
developers are no code monkeys. They have a very good understanding
of the business and the system, through years of experience, and are
paid accordingly.
Having said all that, have you read the Takeuchi and Nonaka paper that
was one of the main sources of inspiration of Scrum? They describe
teams that get a broad - even vague - mission and are trusted to do
the right thing. No spoon feeding of little user stories there. Of
course, that was product development; I accept the point that in
software development it is usually best to have a PO who can guide the
work on the details, too.
Coming back to the Kanban vs. Scrum topic - how does Kanban magically
resolve all these issues?
Jens
George Dinwiddie
Jens Meydam wrote:
> Hi George
>
> On Mar 12, 1:11 am, George Dinwiddie <li...@iDIAcomputing.com> wrote:
>> This is certainly wandering off the topic of Kanban vs. Scrum.
>
> Is it? I thought you were trying to make the point that Scrum is no
> good when there is a lot of uncertainty, while Kanban is.
No, I didn't say that, at all. I said that I've seen Kanban work well
when the Product Owner has trouble envisioning what is wanted for a
whole sprint.
> I used to work with "Product Owners" who had the time and skill to do
> that. But that was in commercial software development. I now work on
> internally used software, for a small financial company (around 30
> employees), and the PO is the CEO. To make the CEO the PO was in fact
> the recommendation of a Scrum Trainer, and I still find it is the best
> solution. The CEO is strongly involved with marketing and has a keen
> sense of what constitutes value for our customers - the real ones, the
> external customers. But he doesn't have the time and patience for the
> tiny details. So you tell me to "coach him to perform his role in a
> more competent manner"? Sounds to me like a career-limiting move.
It depends on how you coach, doesn't it? Or are you saying some people
are beyond help.
[a bunch of stuff putting words into my mouth deleted]
> Coming back to the Kanban vs. Scrum topic - how does Kanban magically
> resolve all these issues?
You tell me. The magic that I believe in is the magic of people working
together to find a solution that fits.
Jens Meydam
> > Coming back to the Kanban vs. Scrum topic - how does Kanban magically
> > resolve all these issues?
>
> You tell me. The magic that I believe in is the magic of people working
> together to find a solution that fits.
OK- let's leave it there. Have a good weekend!
Jens
Smith, John H
I am trying to support my organization in setting up Agile.
I am the test side of it all and would like to know what the views of this forum is on the "minimum requirements" for a tester to be able to support the Agile way (not yet TDD) but in a position to start supporting the Agile teams.
What is the profile for the tester.
Thanks
John
Hi George
Jens
--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To post to this group, send email to scruma...@googlegroups.com.
To unsubscribe from this group, send email to scrumallianc...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scrumalliance?hl=en.
Mark Levison
Cheers
Mark
|
Mark
Levison | Agile Pain Relief
Consulting | Agile Editor @
InfoQ
Recent Entries: Self
Inflicted Agile Injuries, Why
use an Agile Coach
| |
George Dinwiddie
I'd suggest the "minimum requirement" is to be able to test in parallel
with development. You might find some interesting discussions on the
Agile-Testing yahoogroup (http://groups.yahoo.com/group/agile-testing).
- George
Smith, John H wrote:
> Hi,
>
> I am trying to support my organization in setting up Agile.
>
> I am the test side of it all and would like to know what the views of
> this forum is on the "minimum requirements" for a tester to be able
> to support the Agile way (not yet TDD) but in a position to start
> supporting the Agile teams.
>
> What is the profile for the tester.
>
> Thanks
> John
--
John Clifford
when the team is working on a lot of little problems (defects, minor
enhancements) and there is limited value in estimating (you have to
fix the bugs anyway, and you really won't know how long it will take
until it's done). It's harder to accurately estimate and commit to a
sprint backlog that is almost entirely bug fixes. I agree with the
comment about having a rhythm with Kanban, because the axiom
'deadlines drive deliveries' applies outside of Scrum, too.
Again, as others have pointed out, you can use a Kanban board inside
your sprint, showing how items move through the various workflow
stages. This can be useful to spot teams that are functionally
unbalanced, e.g., not having sufficient resources working on testing
(the Agile/Scrum answer here isn't to remove devs and add testers, it
is for people to step up and do what is required to meet the
commitment).
I've also run into situations where the company culture strenuously
resists forming teams, and that can make implementing Scrum difficult.
How can you establish a team velocity if you can't even establish a
team? In such situations, Kanban is better than the ad hoc approaches
these companies are using. The Kanban board is also a signaling/
communications device, and in certain circumstances can work well with
distributed teams.
Because work in progress (WIP) limits are established for each
workflow stage, Kanban works better when most of the incoming work
items are about the same size in terms of effort/complexity. This
isn't a rule, it's a guideline, but it makes it easier to establish
continuous flow.
Finally, I've seen individual teams get together and decide, without a
mandate from management, to run Scrum... and it works because the team
buys in. I don't think Kanban can work without support from management
in terms of enforcing the Kanban rules and WIP limits. (Yes,
management can completely run over a team that has decided to run
Scrum, but the larger batch sizes make it easier for a team to evade
dysfunctional upper management and run Scrum under the radar until
they can prove that it works.)
Andy Brandt
On Mar 11, 3:17 pm, Ron Jeffries <ronjeffr...@acm.org> wrote:
> > OK, so how you tell if a team is doing Scrum or if it is doing
> > Kanban?
> > (Again, to underline it: I have nothing against Kanban.)
>
> I don't care if teams are doing Scrum or if they ard doing Kanban. I
> care whether they are effective and improving. IMO that is what they
> should care about as well.
Hm... Clearly, we have some misunderstanding. I agree with you when it
comes to that team or any other team: this is the core of agile as I
understand it - teams can do whatever they find helpful and
effective.
However, if terms Scrum (and Kanban) are to have any meaning they must
have some limitations. Otherwise - what is Scrum Alliance spreading
and certifying? Do anything as long as it helps you is a fine and
rational philosophy, but it is not Scrum nor is it Kanban.
Best regards,
Andy
Alex Reis
However, if terms Scrum (and Kanban) are to have any meaning they must
have some limitations. Otherwise - what is Scrum Alliance spreading
and certifying? Do anything as long as it helps you is a fine and
rational philosophy, but it is not Scrum nor is it Kanban.
http://alexmreis.com
+32 472 787577
Mauro Botelho
Alex Reis
+55 41 3244 7667
Mauro Botelho
John Clifford
ensure that the queue of incoming work (the work item queue before the
first workflow stage) is always non-empty and prioritized, similar to
keeping the Product Backlog groomed and ready for sprint planning in
Scrum. If there is work to do then the team never needs to come to a
stop. Just as with a Scrum Product Owner, you need to have someone who
owns the queue (backlog) and the prioritization of items in that
queue.
How to deliver a release? Use a timebox, say one or two weeks per
cycle. Segregate work in progress from tested and finished items using
your SCM; establish a team branch, for people who are actually working
on items, and a release branch, where fixed and verified items are
transferred. Deploy at the end of each cycle only the fixed and
verified issues that are included in the release branch. By using
separate branches, and including the migration/integration as a
workflow stage in your Kanban, you can isolate the impact of releasing
from the team. Having a regular release cycle creates a heartbeat that
the team can sync around... and, as in Scrum, deadlines drive
delivery.
John Clifford
Construx
http://www.construx.com
Jens Meydam
Keeping everybody busy 100% is not "lean". Spare capacity leads to
better flow, which leads to better results (also financially); this is
one of the counter-intuitive insights of lean thinking, as far as I
know.
Also, in Kanban work is usually defined in terms of functionality
valued by a customer (features/stories), not things developers have to
do (tasks).
If anything, it is Scrum where people are sometimes kept busy to the
point that dysfunctional behavior ensues. In Scrum a team may quickly
feel under pressure to accept as much work as possible and then to
deliver on this "commitment" at all cost, which may result in work
that is just good enough to pass the acceptance criteria and too
little refactoring. Which in turn may lead to attempts to enforce
good behavior by more and more criteria for "Done".
Ken Schwaber once said that ScrumMasters stand between the business
that always wants too much and the developers who are only too willing
to cut corners to make the business happy (in the short term). This
quickly leads to burnout; good ScrumMasters don't last long.
Apparently in XP teams are encouraged to take on less work than they
could probably deliver and to take the time to do whatever is
necessary to keep the code quality close to optimal, even if this
means doing less than they "promised". This sounds a lot healthier to
me than how Scrum is often described these days.
Jens
Jens Meydam
> have some limitations. Otherwise - what is Scrum Alliance spreading
> and certifying?
Certification may lead to focusing on superficial properties, rather
than the things that really matter, especially when the certification
is based on a multiple choice test. You can test spelling and grammar
with a multiple choice test, but what would you think of a
qualification in creative writing based on such a test? Which is
Scrum closer to, grammar or creative writing?
By the way, ask three Certified Scrum Trainers to describe the role of
the ScrumMaster and with some luck you may get four different answers.
And how old is Scrum? If Scrum without proper retrospectives is not
Scrum - not as old as you may think.
Jens
Peter Hundermark, CSC, CST
On Mar 15, 10:20 pm, Jens Meydam <jmey...@gmail.com> wrote:
> Keeping everybody busy 100% is not "lean". Spare capacity leads to
> better flow, which leads to better results (also financially); this is
> one of the counter-intuitive insights of lean thinking, as far as I
> know.
Yes.
> Also, in Kanban work is usually defined in terms of functionality
> valued by a customer (features/stories), not things developers have to
> do (tasks).
Do you see this as different from Scrum?
> If anything, it is Scrum where people are sometimes kept busy to the
> point that dysfunctional behavior ensues. In Scrum a team may quickly
> feel under pressure to accept as much work as possible and then to
> deliver on this "commitment" at all cost, which may result in work
> that is just good enough to pass the acceptance criteria and too
> little refactoring. Which in turn may lead to attempts to enforce
> good behavior by more and more criteria for "Done".
As I know Scrum, the team pulls what it believes it can do from the
backlog. If it discovers during the sprint that it won't complete the
work, this is a signal to have a conversation with the product owner.
This conversation might lead to removing or reconfiguring stories. The
best outcome will always be still to deliver the agreed sprint goal.
But NEVER at the expense of diluting the team's agreement on DONE.
And is not the 'good behaviour' you describe not simply the team
working professionally, which they should always do and, IMO, will
always do provided they are trusted and empowered to make their own
decisions regarding how to do the work.
> Ken Schwaber once said that ScrumMasters stand between the business
> that always wants too much and the developers who are only too willing
> to cut corners to make the business happy (in the short term). This
> quickly leads to burnout; good ScrumMasters don't last long.
Is this your observation? After 5 years of working with many Scrum
team my experience is different.
> Apparently in XP teams are encouraged to take on less work than they
> could probably deliver and to take the time to do whatever is
> necessary to keep the code quality close to optimal, even if this
> means doing less than they "promised". This sounds a lot healthier to
> me than how Scrum is often described these days.
Do you see descriptions of Scrum where teams should take on more than
they can deliver to agreed quality standards? Or do you refer to teams
who are trying to follow Scrum, but their management doesn't get the
principles? If the latter, do you think XP teams (or Kanban teams for
that matter) in the same organisation will be better off?
Peter
Jens Meydam
> > Also, in Kanban work is usually defined in terms of functionality
> > valued by a customer (features/stories), not things developers have to
> > do (tasks).
>
> Do you see this as different from Scrum?
I was referring to the following part of Alex Reis' post:
"I have been using Scrum and the Story / Task board for a while now,
and I
find they work perfectly together. As for the Lean principles, I guess
a
self-organizing team will get to filling up themselves with tasks to
keep
all team members busy, as long as there is enough tasks on the sprint
backlog."
Also, while in Scrum using tasks (within the Sprint) is standard, I've
never seen a reference to tasks in Kanban. Perhaps in Kanban, tasks
like "analyze feature X in detail", "make a sketch of the GUI for
feature X", "acceptance test of feature X" are often implied in the
workflow and in the transition between workflow stages. Corey Ladas
once linked to an article on checklists, also a useful technique to
avoid cards for tasks.
> > If anything, it is Scrum where people are sometimes kept busy to the
> > point that dysfunctional behavior ensues. In Scrum a team may quickly
> > feel under pressure to accept as much work as possible and then to
> > deliver on this "commitment" at all cost, which may result in work
> > that is just good enough to pass the acceptance criteria and too
> > little refactoring. Which in turn may lead to attempts to enforce
> > good behavior by more and more criteria for "Done".
>
> As I know Scrum, the team pulls what it believes it can do from the
> backlog. If it discovers during the sprint that it won't complete the
> work, this is a signal to have a conversation with the product owner.
> This conversation might lead to removing or reconfiguring stories. The
> best outcome will always be still to deliver the agreed sprint goal.
> But NEVER at the expense of diluting the team's agreement on DONE.
Yes, I agree that this is how it should be done. However, the
practice of the team accepting work right up to their velocity (no
slack), together with the familiar macho talk about commitment, may
easily lead to "suboptimal results" even with experienced agile
teams. Lasse Koskela described how this can happen (http://vimeo.com/
7769760).
Another problem with Scrum as it is usually described is the view of
the backlog as a list of features. This leads to Sprints in which the
team has to get features "DONE" - basically perfect. I think it makes
more sense to do a rough (but of course correctly working) version of
a feature first, get some feedback (if possible from people using it
for real) and then improve the feature to get it fully "DONE". If the
Sprint is long enough, this may happen in the same Sprint. It may
however be advantageous to get a rough version of /all/ essential
features first before working on refinement. (This strategy has been
described by Jeff Patton.)
> > Ken Schwaber once said that ScrumMasters stand between the business
> > that always wants too much and the developers who are only too willing
> > to cut corners to make the business happy (in the short term). This
> > quickly leads to burnout; good ScrumMasters don't last long.
>
> Is this your observation? After 5 years of working with many Scrum
> team my experience is different.
I also find this a bit negative.
I was quoting Ken Schwaber from memory. What Ken Schwaber actually
said is:
"This person [the ScrumMaster] is probably the least loved person in
the world because they stand right at the nexus between product
management believing that any amount of stuff can be done and our
willingness to cut quality to help them support that believe.
The burnout rate on these people is usually like thirteen, fourteen
months."
Ken made this point - of course with good dose of sarcasm - in one of
the Google TechTalks, September 5, 2006 (http://video.google.com/
videoplay?docid=-7230144396191025011#). I quote more context is
quoted in the thread "Scrum styles".
> > Apparently in XP teams are encouraged to take on less work than they
> > could probably deliver and to take the time to do whatever is
> > necessary to keep the code quality close to optimal, even if this
> > means doing less than they "promised". This sounds a lot healthier to
> > me than how Scrum is often described these days.
>
> Do you see descriptions of Scrum where teams should take on more than
> they can deliver to agreed quality standards? Or do you refer to teams
> who are trying to follow Scrum, but their management doesn't get the
> principles? If the latter, do you think XP teams (or Kanban teams for
> that matter) in the same organisation will be better off?
(Please also see my reply above, including the link to Lasse's talk.)
I think committing to work right up to the velocity is unhealthy,
effectively leading to overcommitment.
Kanban teams are better off (in this respect) because there are no
targets. Measurements are used to improve the understanding of the
system. Acting on root causes improves performance.
XP teams are better off (in this respect) because of the explicit
practice of Slack and because of the strong emphasis on technical
excellence. I would imagine that a good XP team doesn't need a long
list of criteria for "Done", delivering sound work is second nature to
them.
This is of course a question of company culture. The situation Ken
Schwaber describes would hardly be a hospitable environment for XP.
One of the strengths of Scrum (as I understand) is that it can be made
to work even in an hostile environment. Scrum has a strong immunity
system.
Jens
Tobias
> effectively leading to overcommitment.
Yes. And personally I never recommend that a Scrum team does this.
Commitment should be made at a gut-level, Velocity is an after-
effect. I advise teams to be sense-driven, not data-driven.
> Kanban [...] Acting on root causes improves performance.
There is an odd perception that only "Lean" and "Kanban" teams act on
root causes. I wonder how that came about. Any aware team will look
for root causes rather than putting band-aids on the problem. This
applies equally to Scrum teams as to any other. Asking "the 5 whys"
is something I find I focus on frequently with new teams, as do most
good Scrum trainers and consultants.
Tobias
Ron Jeffries
> Another problem with Scrum as it is usually described is the view of
> the backlog as a list of features. This leads to Sprints in which the
> team has to get features "DONE" - basically perfect. I think it makes
> more sense to do a rough (but of course correctly working) version of
> a feature first, get some feedback (if possible from people using it
> for real) and then improve the feature to get it fully "DONE". If the
> Sprint is long enough, this may happen in the same Sprint. It may
> however be advantageous to get a rough version of /all/ essential
> features first before working on refinement. (This strategy has been
> described by Jeff Patton.)
I agree that things should probably go from rough to smooth, but I
see no reason why that means the backlog isn't a list of features --
from rough to smooth.
Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
The lyf so short, the craft so long to lerne. -- Geoffrey Chaucer
Tobias
updated, refined. "Done" simply means "of a quality to be released
and doesn't break anything". We can release rough features (Google
often do, for example), but rough is not the same as broken, or
brittle.
Tobias
Jens Meydam
On Mar 21, 10:24 am, Tobias <tobiasgma...@gmail.com> wrote:
> > I think committing to work right up to the velocity is unhealthy,
> > effectively leading to overcommitment.
>
> Yes. And personally I never recommend that a Scrum team does this.
> Commitment should be made at a gut-level, Velocity is an after-
> effect. I advise teams to be sense-driven, not data-driven.
And if the commitment leaves some wiggle room (as already recommended
in the first book on Scrum by Schwaber and Beedle), the team will not
feel under pressure to hurry if they are a little behind at the end of
the sprint. For example, a feature may be delivered in a rougher (or
more polished) state, depending on how things go.
The benefit of a tight deadline is not so much that it creates
pressure to work 'harder', but that it leads to a healthy bias in
favor of simple, practical solutions that can be gradually refined as
needed.
Seen in this way, the Sprint timebox seems a big plus of Scrum, and I
wonder how Kanban manages without it. 'Pure' Kanban - without a
rhythm (cadence) of meetings for planning and demos - is probably
suited well only for maintenance.
> > Kanban [...] Acting on root causes improves performance.
>
> There is an odd perception that only "Lean" and "Kanban" teams act on
> root causes. I wonder how that came about. Any aware team will look
> for root causes rather than putting band-aids on the problem. This
> applies equally to Scrum teams as to any other. Asking "the 5 whys"
> is something I find I focus on frequently with new teams, as do most
> good Scrum trainers and consultants.
Actually, the removal of barriers to productivity is central to Scrum
- impediments are to be addressed every day in the Daily Scrum
meeting, and the removal of impediments is one of the main tasks of
the ScrumMaster.
Jens
Jens Meydam
> I agree that things should probably go from rough to smooth, but I
> see no reason why that means the backlog isn't a list of features --
> from rough to smooth.
OK.
By the way, I thought again about how to reconcile the current
practice (also favored by you) of planning work in terms of very small
features (and small feature improvements) with the inability to
identify such small units of work in advance in cases where the work
is highly creative and generated knowledge is constantly fed back into
development.
If iterations are short (like, a week) the visibility is probably
always good enough to define small stories for the next iteration.
It's like driving in the fog; visibility is reduced, but one can
always see a few meters (or whatever you use in the US) ahead. Is
that the idea?
Jens
Jens Meydam
> Yes, most software features are always being improved, tweaked,
> updated, refined. "Done" simply means "of a quality to be released
> and doesn't break anything". We can release rough features (Google
> often do, for example), but rough is not the same as broken, or
> brittle.
Agreed.
Jens
Michael D. James
--mj
Ron Jeffries
> By the way, I thought again about how to reconcile the current
> practice (also favored by you) of planning work in terms of very small
> features (and small feature improvements) with the inability to
> identify such small units of work in advance in cases where the work
> is highly creative and generated knowledge is constantly fed back into
> development.
> If iterations are short (like, a week) the visibility is probably
> always good enough to define small stories for the next iteration.
> It's like driving in the fog; visibility is reduced, but one can
> always see a few meters (or whatever you use in the US) ahead. Is
> that the idea?
It's a decent analogy ... however, I suspect that the issue with
"inability" to identify small bits of work has two aspects:
1. Insufficient practice identifying small bits;
2. Trying to identify small bits too far in advance.
I could, of course, be wrong. No, never mind. That makes no sense.
Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
Fear is the mindkiller. --Bene Gesserit Litany Against Fear
Jens Meydam
> I suspect that the issue with
> "inability" to identify small bits of work has two aspects:
>
> 1. Insufficient practice identifying small bits;
> 2. Trying to identify small bits too far in advance.
OK.
Jens
I could be wrong, but I'm not. -- Ron Jeffries, quoting Eagles,
Victim of Love
Alex Reis
Personally, I see people talking about small, executable and testable
user stories / backlog entries, and I start scratching my head.
Why does your backlog need to be refined to that level if you,
according to agile principles:
- Believe that the team is capable of dividing work into smaller units
afterwards;
- Have an open communication channel between the Product Owner and the
team, so that you can verify that the story is done with the PO before
moving it to the "done" pile?
When they have such small stories, people start breaking down tasks
like crazy, like Unit Test this; Integration Test that. It is
micromanagement all over.
This, in the end, leads to some of the agile leaders, such as Ron
Jeffries (hey mate), believing that tasks are better left not tracked
or created.
What I tend to do in my projects, is approach stories so that they, as
a single unit, add significant business value to the product. Whenever
we have our sprint planning; we then break down stories into smaller
tasks, and estimate them. We get down to the level that:
- Tasks are indivisible units of work, as in, batches of work that
without being completed, would not benefit from having another person
doing them
- Tasks are no longer than 1 day's worth of the team velocity
If you apply those (subjective, I know) criterias, we will end up with
something easily trackable in the burndown chart, while still keeping
the product backlog high level enough that you can use it as a product
feature roadmap, or can use it to discuss with stakeholders without
having to explain too much.
How does that relate to Kanban? Don't ask me, i feel we can probably
use a subject line change on this thread.
Best,
Alexandre M. Reis
http://alexmreis.com