Tools Vs Physical Task Board

[Nirmaljeet M]

Hi,

This question is regarding the use of PLM tools against physical task
boards.

Our organization uses MKS as the PLM tool which provides options to
create sprints and related stories and tasks. I have run a couple of
sprints with this tool and I ended up creating the tasks in the tool
as well as on the physical task board.

This approach of mine has people complaining about the duplication of
effort going into managing the tasks on the tool as well as on the
scrum board.

My intention of recording the tasks in the tool was to leverage the
capabilities offered by the tool like generating burn down etc. Most
teams use excel sheets to generate burn down.

I would like to understand if maintaining stories and tasks in the
tool and on the scrum board is acceptable or should the duplication be
avoided?

Thanks you.

[Yves Hanoulle]

Hi

the answer of course is: it depends ;-)

My question to you is, why do you want to have the data n the tool, what advantage does the tool give you.

(or beter what problem are you trying to solve)

and is the problem bigger then duplicating data?

y

2012/2/22 Nirmaljeet M <mnirm...@gmail.com>

--
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.

[Lucas Videla]

IMHO, if the effort of duplicating every task on the taskboard to a register into any tool worths the minutes it takes, you should keep doing it.
Scrum, among other things, is about visualization: the physical taskboard accomplishes this very well, but if you don't record any, you miss other kind of metrics you can take.
That's why you tipically complete the burndown chart everyday (to keep track of the remaining effort and to be able to calculate the velocity). And most teams do this chart by hand...
If you get any other advantage by keeping a digital log of every day of the sprint, keep doing it (and please tell us). But if don't, i think you should avoid this duplication.

           L.-

[Ahmed Nasr]

Hello,

i was in your position and by answer is USE BOTH, the value is really worth it.

Tool benefit a lot to track everything, i'm using Microsoft Team Foundation System 2010 (TFS2010) it helps me a lot to track stories with tasks with bugs with builds with test cases and having a relation between them all. The benefit of this is really huge in a way you can't imagine. This actually benefit all the team members in different roles.

Physical wall, makes people feel what they are doing now and later and what is done by just one look and also to feel your other team members work.

Note: if you can get a screen 42' or more and show on it the board (extracting this info from your tool) then you will have one location to do the changes, i tried this with small team with 32' screen and it was nice :)

-- 
Best regards,
Ahmed Nasr
-------------------------------------------------------- 

[RonJeffries]

Hi Ahmed,

On Feb 22, 2012, at 6:38 AM, Ahmed Nasr wrote:

Tool benefit a lot to track everything, i'm using Microsoft Team Foundation System 2010 (TFS2010) it helps me a lot to track stories with tasks with bugs with builds with test cases and having a relation between them all. The benefit of this is really huge in a way you can't imagine. This actually benefit all the team members in different roles.

What are the top three benefits you get from MTFS? Do you have a lot of bugs in various builds that come and go? I would think that would be bad ...

Ron Jeffries

www.XProgramming.com

Everything that needs to be said has already been said.

But since no one was listening, everything must be said again. -- Andre Gide

[Nirmaljeet M]

Thank for your your prompt response.

Yves/Lucas,

I see a couple of advantages of having the data in the tool:

1. My remote product owner has a complete picture of the tasks the
team is working on and can comment on the same
2. If I have a tool, I either leverage its capabilities to generate
artifacts like the burn down and also use it for keeping record of
tasks else there is no reason to use a tool. Stickies generally land
in trash once the sprint is complete

It takes 2 minutes at the end of each day to update status of tasks
and stories and I have this as part of the DoD

Nirmal

On Feb 22, 4:16 pm, Lucas Videla <videla.lu...@gmail.com> wrote:
> IMHO, if the effort of duplicating every task on the taskboard to a
> register into any tool worths the minutes it takes, you should keep doing
> it.
> Scrum, among other things, is about visualization: the physical taskboard
> accomplishes this very well, but if you don't record any, you miss other
> kind of metrics you can take.
> That's why you tipically complete the burndown chart everyday (to keep
> track of the remaining effort and to be able to calculate the velocity).
> And most teams do this chart by hand...
> If you get any other advantage by keeping a digital log of every day of the
> sprint, keep doing it (and please tell us). But if don't, i think you
> should avoid this duplication.
>
>            L.-

[Yves Hanoulle]

2012/2/22 Nirmaljeet M <mnirm...@gmail.com>

Thank for your your prompt response.

Yves/Lucas,

I see a couple of advantages of having the data in the tool:

1. My remote product owner has a complete picture of the tasks the
team is working on and can comment on the same

an electronic board is just one of the options for that.

(As Jerry WIenberg says, if yyou don't have 3 options, you haven't thought hard enough about your problem)

 

2. If I have a tool, I either leverage its capabilities to generate
artifacts like the burn down

a burndown is a tool for the team.

What I have noticed with teams where a burndown is generated, the team does not care about it.

they think it is for management

when they create the BD themselves for a couple of weks/months, they care about it (as they see the value) and then swithcing to a generated version can help.

if people stop updating the BD chart before that fase, it basically means that they don't care about the it and then generating is a waste of time.

you can judge where your team is, I can't.

and also use it for keeping record of

tasks else there is no reason to use a tool. Stickies generally land
in trash once the sprint is complete

It takes 2 minutes at the end of each day to update status of tasks
and stories and I have this as part of the DoD

then it's you who has to value if it's wurth your time.

 

and that raises the question why do you do it and not the team?

[Ahmed Nasr]

Hello Ron,

I didn't say anything about lot of bugs :)

I'm saying you having a relation between everything you work on and this benefit to get a lot Reports and dashboard that you can design and refresh it at any time you want and benefit all team members

For example. Everyone in the team can generate for himself any chart or report he wants to track his/her progress if they want.

and as Nirm said, tool really benefit offshore customers , and that's the case with most of my customers

TFS helps me a lot to answer many questions.

1-Which bug relate to which task or to which user story?

2-Making many reports and combine it together to form a dashboards ?

3-Testers can check if any dev changed any task that would affect some test cases, they can get those test cases easily in 1 min and if they are automated test cases they can run it easily with no redo of work

4-Devs might want to know if their code is covering all bugs/ tasks/ stories?

5-for Devs they want to know which piece of code related to which task/bug/story? no need to check many classes

6-Devs life is easy with automated build and deployment with automatic taking of snapshot of virtual test and development machines

7-I can easily generate a ready made report showing for every iteration each story with hours/points done development for it and what is remaining , with also showing in the same line how many test cases is covering it with how many passed or failed test cases, also in the same line show how many bugs resolved , opened. (all of these info is by row for each story)

8-Devs finds it easy to visualize the build history with its branches. also this feature is very informative if we want to know if a bug were fixed or a task is done in a specific release, you get this info in 1 min just go to task/bug and know the check in for it and see if this check in where in the build made for that specific release, ALL OF THAT is by visualizing without looking in code or trace code.

As i said TOOL give you great benefit of using it. that's why you need the collaboration of all team members to update it along with the physical wall, or as i said you can get a big screen to show on it the board.

Hope i answered your question about why TOOL is benefit of using it?

-- 
Best regards,
Ahmed Nasr

--
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.

--------------------------------------------------------

[Lucas Videla]

Hi Nirmal,

I think the cost/benefit ratio is favorable for your needs.

I'd suggest to have the PO co-located, and to don't show him the task board on a daily basis, but sometimes it's utopian ;)

--
                L.-

[Alan Dayley]

On this topic, I agree with the team at Integrum:

http://integrumtech.com/2012/02/scrumcast-45-digital-boards-and-physical-boards/

Alan

[AgileSchools]

We create and manage the stories in our system digitally. This helps with communicating and collaboration with our customers who are not colocated with us. It also does help with release planning.

The colocated team does not use the digital system in their sprints. They use a physical board to create and manage tasks burn down, impediments, etc IMO, physical is superior for team collaboration than digital. They do print the stories out after Sprint planning from the system. But that just takes 5-10 minutes of persons time.

I see the digital stories are the benefit of the non-colocated customer, the physical board is for the team to do their work. I like that it creates a nice boundary and protects the teams focus and empowerment.

Regards,
John Miller

-Sent from an iPhone. Expect inaccuracies.

[Ahmed Nasr]

I agree with John, 

that's why i mentioned earlier we do both and people are appreciating the value from physical board and also the value come from a tool like TFS2010.

we all agree if something that has no value and/or is not appreciated by the team so don't use it

--
Best regards,
Ahmed Nasr

--------------------------------------------------------

[George Dinwiddie]

Nirmal,

On 2/22/12 6:44 AM, Nirmaljeet M wrote:
> Thank for your your prompt response.
>
> Yves/Lucas,
>
> I see a couple of advantages of having the data in the tool:
>
> 1. My remote product owner has a complete picture of the tasks the
> team is working on and can comment on the same

Um, no, it does NOT give a remote product owner a complete picture of
the tasks. It just gives the illusion of a complete picture and provides
a seductive temptation to operate on the information in the tool and
bypass actual conversations.

See, also, http://blog.gdinwiddie.com/2012/01/16/agile-planning-tools/

> 2. If I have a tool, I either leverage its capabilities to generate
> artifacts like the burn down and also use it for keeping record of
> tasks else there is no reason to use a tool. Stickies generally land
> in trash once the sprint is complete

Why do you want to keep track of tasks after the sprint? That seems like
very low-level detail that's not worth the effort.

Are you trying to track actual hours against estimates? If so, that's
not only not worth the effort, but tends to cause problems.

> It takes 2 minutes at the end of each day to update status of tasks
> and stories and I have this as part of the DoD

Your definition of done includes updating the burndown? DoD of what?

In any event, it doesn't take me 2 minutes to update a burndown. I don't
estimate hours; I don't re-estimate; I don't count partial work.
Tracking completed stories gives enough detail for steering, is less
work, and is more reliable than estimates.

You might be interested in
http://idiacomputing.com/pub/BetterSoftware-BurnCharts.pdf where I talk
about what to track in burn charts.
[snip]

>>> Our organization uses MKS as the PLM tool which provides options to
>>> create sprints and related stories and tasks. I have run a couple of
>>> sprints with this tool and I ended up creating the tasks in the tool
>>> as well as on the physical task board.

If you want to use an electronic tool, then that's the way to do it. Let
the team use the physical board. Don't slow them down with an electronic
tool.

>>> This approach of mine has people complaining about the duplication of
>>> effort going into managing the tasks on the tool as well as on the
>>> scrum board.

Why do they complain if YOU are the one entering the data in the tool?
Or are you insisting that THEY do this for YOUR purposes?

>>> My intention of recording the tasks in the tool was to leverage the
>>> capabilities offered by the tool like generating burn down etc. Most
>>> teams use excel sheets to generate burn down.
>>
>>> I would like to understand if maintaining stories and tasks in the
>>> tool and on the scrum board is acceptable or should the duplication be
>>> avoided?

I would recommend just using the board. There are more important things
to do than play with "PLM" tools.

- George

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

[Glenn]

My experience has been that the physical board is the only thing that
matters to the team. Management has an interest in the digital
artifacts, but rarely does anything with it. Currently, we track epics
in our software, but the scrum teams track their stories and tasks on
the physical board. Bugs are a little different. We do track those
electronically so that we can preserve quality metrics. Whether or not
you want to track things electronically should carefully take into
consideration the balance between interfering with the team vs. the
value you are getting from it. Over the last 8 years, we have gone all
over the map from boards only to software only and to a combination of
both. The physical board is not optional for us. It is true
transparency, impossible to ignore, and a tactile experience. I've
seen programs that mimic this and they are like a photograph of
something really cool. Still possibly cool, but not the real thing. It
has become the focal point of our morning scrums. Team members update
their hours remaining on their cards as they speak. At the end of the
standup, the burndown is updated. Developers point out the cards in
the acceptance column to the Product Owner. Without the physical
board, it all crumbles, standups become robotic monotone verbal
exchanges, cats and dogs living together, grown men crying.

-Glenn

[George Dinwiddie]

Glenn,

On 2/24/12 5:26 PM, Glenn wrote:
> ... The physical board is not optional for us. It is true

> transparency, impossible to ignore, and a tactile experience. I've
> seen programs that mimic this and they are like a photograph of
> something really cool. Still possibly cool, but not the real thing.

What a great image! I wish it were short enough to tweet.

> It
> has become the focal point of our morning scrums. Team members update
> their hours remaining on their cards as they speak. At the end of the
> standup, the burndown is updated. Developers point out the cards in
> the acceptance column to the Product Owner. Without the physical
> board, it all crumbles, standups become robotic monotone verbal
> exchanges, cats and dogs living together, grown men crying.

It seems difficult for people to understand this--more so since many
organizations want to start with electronic tools and never experience a
real board.

[AgileSchools]

"get real" could be a cool tweet.

Regards,
John Miller
Director of IT
Litchfield Elementary School District
Http://it.lesd.k12.az.us

-Sent from an iPhone. Expect inaccuracies.

[Glenn]

George, I feel compelled now to share a story.

A friend of my wife described to me, about a year or so ago, how her
husband had started a new job as a manager at a manufacturing plant.
He was astonished to realize that they tracked everything with paper
cards on a corkboard. The very notion of this seemed evidence that
this company was stuck in the cave man era. We have computers! Why
write on the walls! You can imagine the grin I labored to conceal as
she laid out the scenario. I did eventually explain to her my position
on the matter but my point is this: people seriously underestimate
the power of physical, spatial representations of a thing that, until
brought into fruition, is only a concept.

For example, we recently created a physical corkboard of every product
backlog item on a matrix of Product Value vs. Story Points. The
product owner group had assigned Product Value and the developers had
assigned Story Points. The process of creating a large corkboard,
plotting the Y axis (Product Value) against the X axis (Story Points)
made it ridiculously clear what groups of enhancements would be most
valuable to work on next. Immediately, we created three more
corkboards … Bugs, Technical Debt, and (within technical debt) Test
Automation Items. Everything is now scored on a hugely visible matrix
of estimated VALUE over COST. All this data is visible in our
electronic tracking system, but once it is large as life, people
gather around it. They point their fingers at it. They react to it.
Good things happen.

-Glenn

[AgileSchools]

Glenn,

I fell into the same trap, but, before I entered the Agile age. As a technologist with my "everything is better with tech" worldview, I HAD to have a PMIS. Paper was so 20th century.

The Toyota Way talks about Toyota only uses tech when it has a definite, proven value over a non-tech approach. Same should apply anywhere.

[Stuart Turner]

I would say some of the biggest benefits of using a physical board
are:

It makes you more aware of your processes as you need to manually
monitor, calculate and update.
It acts as a hub for team discussions.
People outside the team, particularly those located remotely, cannot
easily see intra-iteration progress.
It encourages co-located teams.
It makes knowing the progress of the iteration easily visible at all
times.
Anyone on the team can easily update the board. No software or
granting of permission is required.
You can take the cards written in the iteration planning meeting
directly to the board.
It encourages not using a tool or computer in the iteration planning
meeting.
It is obvious when someone goes to the board and changes something
There's no need to agree on which electronic tool to use, purchase,
install, maintain.
There's no risk of 'features' of the tool distracting you from the
simple capability you actually want it to provide.
There's no risk of getting sucked-in to desiring and using additional
features of the tool, distracting you from its true purpose. No tick-
box comparison of features required.

Most teams I've worked with prefer the task board. Feedback suggests
they feel they own it and it's not for reporting to anyone else.

Stuart

On Feb 26, 4:25 am, AgileSchools <agilescho...@gmail.com> wrote:
> Glenn,
>
> I fell into the same trap, but, before I entered the Agile age. As a technologist with my "everything is better with tech" worldview, I HAD to have a PMIS. Paper was so 20th century.
>
> The Toyota Way talks about Toyota only uses tech when it has a definite, proven value over a non-tech approach. Same should apply anywhere.
>

[George Dinwiddie]

Stuart,

Nice list. I've got a few additions.

Multiple people can enter data at the same time. Or move stuff around at
the same time.

The team can handle oddball situations in a few minutes.

The team can re-organize their process easily.

>
> Most teams I've worked with prefer the task board. Feedback suggests
> they feel they own it and it's not for reporting to anyone else.

Yes, it's a working tool, not a monitoring tool.

[Steve Berczuk]

I agree that a physical task board has advantages, but many of them are about habit formation rather than something intrinsic about electronic tools that can't be addressed. If people buy in to the process, you can still do many of the things mentioned in this list with a tool. And with many tools you can even generate paper cards :)

The big things for me in terms of ease of you are :

 - Visibility, (which a paper board give implicitly to a co-located team, but which you can also get with always on monitors that show the task board)

 - Focus. On the one hand doing calculations about work left (if you estimate) was you move cards forces you to consider the effect. But it's also secondary in some sense.

 

Some of the points below like being able to work in parallel on the task board, or permissions, don't make sense to me based on my experience using tools. as every team I've worked on  that has a tool (it's usually been Jira +greenhopper) anyone could change/enter data and unless you are changing the same card, you could work in parallel (and in a paper world, 2 people can't edit the same card anyway)

So, while I like physical task boards, and I agree that they are great tools for changing habits, I think that the second most important issue: visibility is simply a technical one. and the most important issue (already mentioned):

 ***Most teams I've worked with prefer the task board. Feedback suggests
they feel they own it and it's not for reporting to anyone else. **

can be facilitated with a task board. but You can have a board and still not have the ownership.

I don't mean to disagree, but I also think that focusing on the tool takes us away from focusing on the goal we are trying to accomplish.

Steve

--
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 scrumalliance+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/scrumalliance?hl=en.

--
Steve Berczuk  | steve....@gmail.com | http://www.berczuk.com
Twitter: @sberczuk 
SCM Patterns:   www.scmpatterns.com

[George Dinwiddie]

Steve,

On 2/27/12 8:15 AM, Steve Berczuk wrote:
> I agree that a physical task board has advantages, but many of them are
> about habit formation rather than something intrinsic about electronic
> tools that can't be addressed. If people buy in to the process, you can
> still do many of the things mentioned in this list with a tool. And with
> many tools you can even generate paper cards :)
>
> The big things for me in terms of ease of you are :
> - Visibility, (which a paper board give implicitly to a co-located
> team, but which you can also get with always on monitors that show the
> task board)

I've worked with teams that tried this, and it didn't work as well as
the wall. There's not nearly as much visibility--the resolution of the
largest monitor is much lower than the wall. And without the direct
interaction, people tune it out in a relatively short time.

> - Focus. On the one hand doing calculations about work left (if you
> estimate) was you move cards forces you to consider the effect. But it's
> also secondary in some sense.
> Some of the points below like being able to work in parallel on the task
> board, or permissions, don't make sense to me based on my experience
> using tools. as every team I've worked on that has a tool (it's usually
> been Jira +greenhopper) anyone could change/enter data and unless you
> are changing the same card, you could work in parallel (and in a paper
> world, 2 people can't edit the same card anyway)

Two people CAN edit the same card, but not without a conversation. That
seems to be a benefit, to me.

[Neil]

Yes a physical board is better than a virtual one, but as @Steve
points out, a physical wall is still a "tool", just like a virtual
wall is, and thus should be under scrutiny for improvement by the team
just as much as a virtual wall should be.

But to sum up my experience on this matter - "agile" PM tools like
Rally are great for backlog management, release planning, etc., but
intra-Sprint workflow (i.e. the Sprint Backlog tasks and their
progress to "done") is best handled on one physical wall, EVEN IF the
team is distributed. The location with the most team members has the
wall and the offshore team members update their tasks via
communication with the team. The day-to-day activities of the team,
including the act of updating the wall, should ALWAYS be based around
conversations, and a virtual wall simply hides what is really going
on.

When you ask the team to update their tasks in a PM tool you always
end up with an admin overhead, are generally doubling-up on effort and
are taking the team away from the Sprint tasks. Keep it simple and
just use a wall.

[Steve Berczuk]

I agree with all of this. The wall is better for tracking during a sprint. And serves as a good "culture change" tool, forcing interaction and ownership among team members. I think it is possible that you can maintain the communication culture with a tool ,and also have dysfunctional teams that are using a wall, but if you are trying to change from an "assignment" culture to a "communication one, the wall makes roadblocks clearer.

And the difference between planning and tracking matches my experience. I have worked on teams where the "2-systems" approach got pushback, and the team members really wanted to use the tracking system. What have other people done in that circumstance? Mandating a wall seems very command+control-ish. especially when the team is meeting goals and collaborating well (perhaps not optimally, but well) using the issue system + talking. (and yes, "printing cards" can work but can also be awkward....)

Steve

--
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.

[RonJeffries]

Hi Steve,

On Feb 28, 2012, at 8:36 AM, Steve Berczuk wrote:

And the difference between planning and tracking matches my experience. I have worked on teams where the "2-systems" approach got pushback, and the team members really wanted to use the tracking system. What have other people done in that circumstance?

I generally take this as evidence that the team is not high in trust, and not very sociable in general. These are the teams that want to communicate via email and that look at their own shoes, not the speaker's shoes, during standup meetings.

[Steve Berczuk]

On Tue, Feb 28, 2012 at 9:24 AM, RonJeffries <ronje...@acm.org> wrote:

On Feb 28, 2012, at 8:36 AM, Steve Berczuk wrote:

And the difference between planning and tracking matches my experience. I have worked on teams where the "2-systems" approach got pushback, and the team members really wanted to use the tracking system. What have other people done in that circumstance?

I generally take this as evidence that the team is not high in trust, and not very sociable in general. These are the teams that want to communicate via email and that look at their own shoes, not the speaker's shoes, during standup meetings.

Usually, yes. But what can one do to change this? Give up? (which is sometimes the right answer.)

And to add another twist: On some of these same teams, people have been very clear about accomplishments, goals, and roadblocks in standup meetings, (and are communicative in person, in chatrooms etc during the work day), (and who talk to each other before "assigning" or "taking on" issues in the system) but seem to think of the project walls as either "double work" since we are already using the issue tracking system to manage the backlog.

I'm not trying to be difficult; I've seen the dysfunctional teams where resisting the scrum board was a proxy for resisting interaction. But in other cases not using paper is seen as being efficient. It may be holding the team back a bit, but the team is doing OK. 

So how do you overcome the barriers to a more  visible task board when the team is doing most of the right things with a electronic-based system.

Steve

[RonJeffries]

Hi Steve,

On Feb 28, 2012, at 9:35 AM, Steve Berczuk wrote:

Usually, yes. But what can one do to change this? Give up? (which is sometimes the right answer.)

And to add another twist: On some of these same teams, people have been very clear about accomplishments, goals, and roadblocks in standup meetings, (and are communicative in person, in chatrooms etc during the work day), (and who talk to each other before "assigning" or "taking on" issues in the system) but seem to think of the project walls as either "double work" since we are already using the issue tracking system to manage the backlog.

Stop using the issue tracking system. It's like using the navigation system to drive in traffic.

I'm not trying to be difficult; I've seen the dysfunctional teams where resisting the scrum board was a proxy for resisting interaction. But in other cases not using paper is seen as being efficient. It may be holding the team back a bit, but the team is doing OK. 

You get to decide what to do. However, not using paper is NOT more efficient. It is less so. More is settled standing in front of the task board than is ever settled via email.

As this thread is beginning to show ...

So how do you overcome the barriers to a more  visible task board when the team is doing most of the right things with a electronic-based system.

No one is saying this is the top priority. If it were ...

Me? I'd delete the electronic system. You? You may have more of a need to be reasonable. I've already been fired once for saying that, and I'm still in business and the guy who fired me isn't. :)

Ron Jeffries

www.XProgramming.com

Wisdom begins when we understand the difference between "that makes no sense" and "I don't understand". -- Mary Doria Russell

[Derek Davidson]

Hi Ron

> Stop using the issue tracking system. It's like using the navigation system to drive in traffic.

I've been following this thread with great interest and I love the
quoted text above :) I see merit in both sides of the discussion and
am greatly interested in your thoughts on the following three
situations which I have found challenging when using only a Scrum
board:

1. Part of the Development Team is outsourced and located in another
country / timezone.

2. The Scrum Board is located in a public area (no space for it
anywhere else). Some wags (not team members) think it hilarious to
relocate some of the User Stories (especially if one of the
development team goes on holiday).

3. Senior Management outside of the team draw great comfort from, and
often request, burndown chart reports, preferably in PDF format
because they have meetings to go to where they have to report on
performance and they don't quite grok this new-fangled agiley stuff.

Thanks.

Derek Davidson
http://www.webgateinternational.com

[Derek Davidson]

Hi Ron

> Stop using the issue tracking system. It's like using the navigation system to drive in traffic.

That comment made me smile :)

I've been watching this thread with interest and can see merit in both
sides of the debate. I do see challenges in using a physical board
under a number of situations though and would appreciate your insight
into the following:

1. Part of the team is located in another country / time zone.

2. The project board is located in a public space. Some wags find it
highly amusing to relocate some of the board items, especially when
the developer responsible has gone on holiday.

3. Your boss needs to report progress at exec meetings. He doesn't
really grok all of this agiley stuff and needs reports (Ok, I suppose
a burndown chart will just about suffice - bit I miss my Ganntt charts
dammit!) to show to the other execs who are definitely on the stiff
side of agile. He wants the reports in PDF format and has a habit of
asking for them at very short notice (ps: Taking out a hit on the said
boss, or 're-training' him aren't options).

nb: I swear that I posted a reply to your post earlier today but I
can't see it in the groups hence why I've posted this new reply.
Apologies if there appears to be duplicates.

--
Derek Davidson
www.webgateinternational.com

[RonJeffries]

Hi Derek,

Unfortunately I unmoderated both. We'll manage ...

On Feb 28, 2012, at 11:28 AM, Derek Davidson wrote:

I've been watching this thread with interest and can see merit in both
sides of the debate. I do see challenges in using a physical board
under a number of situations though and would appreciate your insight
into the following:

1. Part of the team is located in another country / time zone.

Best solution I've ever seen was that the whole board was replicated physically in both locations.

I've seen big monitors. People ignore them in ways they don't ignore a board.

2. The project board is located in a public space. Some wags find it
highly amusing to relocate some of the board items, especially when
the developer responsible has gone on holiday.

Get a webcam. Find out who does it. Kill them as an example to the others.

3. Your boss needs to report progress at exec meetings. He doesn't
really grok all of this agiley stuff and needs reports (Ok, I suppose
a burndown chart will just about suffice - bit I miss my Ganntt charts
dammit!) to show to the other execs who are definitely on the stiff
side of agile. He wants the reports in PDF format and has a habit of
asking for them at very short notice (ps: Taking out a hit on the said
boss, or 're-training' him aren't options).

Schedule creating his report as a backlog item. Track it, including time spent and impact on actual work.

nb: I swear that I posted a reply to your post earlier today but I
can't see it in the groups hence why I've posted this new reply.
Apologies if there appears to be duplicates.

My bad. I thought "should I look?" and didn't. You're wide open for posting now.

[Yves Hanoulle]

2. The project board is located in a public space. Some wags find it
highly amusing to relocate some of the board items, especially when
the developer responsible has gone on holiday.

Get a webcam. Find out who does it. Kill them as an example to the others.

I agree with Ron (not about the killing) but this is not acceptable behavior.

y

[John Miller]

Hi,

I would suggest taking a step back and looking at your team and stakeholder needs. What are the goals and your context? What best serves the team's needs and the stakeholders, while allowing you to focus as much as possible on value creation vs overhead?

Some general advice that may or may not serve you:

Are your teams collocated or distributed?

If collocated, I would abandon, at a minimum, the digital tasks and go pure physical artifacts. You may want to ask the team how valuable tracking the "how" is digitally for them and are the reports like Burndowns serving them? You'll see lots of discussions in this group list archives about if Burndowns are beneficial or not to the team. 

If your customer is nearby you physically, I might abandon the digital all together. If they are not nearby, then, you may want to keep the digital tool for visibility into the backlog and how the project is progressing, such as a Burnup chart. There are benefits, if you need to report out , in keeping the backlog and Sprint backlog digitally, as it may automate the reports and transparency at the value level to stakeholders. 

Thank You,

John 

Sent from my iPhone. It likes to sabotage my grammar. 

On Feb 3, 2013, at 4:58 AM, Tim Jenks <tim....@14principles.com> wrote:

Hi,

This has been an age old problem and it's always a sad day when another physical board goes to the grave due to the practicalities of maintaining them in some situations.

Often distributed teams can't or don't want to spend the energy maintaining both tooling and physical, but ultimately it's up to the team.

If the team are getting the visual management benefits of a physical board, then they'll ask for it to be retained. If they aren't, then it probably isn't a great deal to them and maybe the tooling route is better in that situation.

There are a couple of existing software solutions to reduce the duplication of maintaining both like http://flowkaizen.com/ by Rodrigo Yoshima and http://boardsyncnow.com by us at 14principles.

We've been using boardsync for a good few months now with a couple of distributed teams and it's working a treat at reducing the duplication. If you don't mind printing out some barcodes that is!

-Tim

On Wednesday, February 22, 2012 11:05:20 AM UTC, Nirmaljeet M wrote:

Hi,

This question is regarding the use of PLM tools against physical task
boards.

Our organization uses MKS as the PLM tool which provides options to
create sprints and related stories and tasks. I have run a couple of
sprints with this tool and I ended up creating the tasks in the tool
as well as on the physical task board.

This approach of mine has people complaining about the duplication of
effort going into managing the tasks on the tool as well as on the
scrum board.

My intention of recording the tasks in the tool was to leverage the
capabilities offered by the tool like generating burn down etc. Most
teams use excel sheets to generate burn down.

I would like to understand if maintaining stories and tasks in the
tool and on the scrum board is acceptable or should the duplication be
avoided?

Thanks you.

--

You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.

To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.

To post to this group, send email to scruma...@googlegroups.com.

Visit this group at http://groups.google.com/group/scrumalliance?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.