Re: [scrumdevelopment] Scrum Principle: Cross-Functional Team
- On Tue, Aug 3, 2010 at 4:02 PM, Geoffrey <geoffrey_slinker@...> wrote:
>From my various interactions with Ron I think that he intended for the
> "From the Agile viewpoint, what we have here is a fundamental violation of the Scrum principle that the software must be done by a cross-functional team: a team that has all the skills needed to do the project. This team doesn't have the design skills to do the project … and therefore they are not an Agile team at all!"
> If a team has all of the skills needed to do a project then any process management methodology and any software development methodology would most likely be successful.
> If a team does not have the skills needed to do a project then any process management methodology and any software development methodology will fail.
> I find the quote at the beginning to be troubling in its implications. Is it saying, "Hey, you can't blame Agile because YOU didn't have a properly skilled team."
statement to be troubling in its implications. Is it also true? Seems
to me that it is. So what do we do about it?
> Is this Scrum principle in conflict with "people before process"?Ron is saying that a group of people who has the necessary skills will
find the processes and tools that work. That is in complete alignment
with what the Agile Manifesto says (And he is calling that approach
However, a group of people without the necessary skills will have a
hard time getting the processes and tools to work. Ron suggests that
you might be able to game the results by telling this group of people
which processes and tools to use. That would not be a particularly
"Agile" approach, because it is in conflict with "Individuals and
Interactions over processes and tools." It might work. There is
evidence that it has worked in the past, but the success rate is not
I don't know if Ron is right, but I suspect he is on the right track.
The implication is this:
Either (a) build a cross-functional team and *do not* tell them how to
do it. They will figure it out.
Or (b) hire the cheapest folks you can find and tell them how to do
it. This is risky, but probably better than nothing.
I know from experience that (a) works if you do it well. I know from
experience that (b) may or may not work regardless of how well you do
it. I know from experience that the following are fraught with peril:
(c) build a cross functional team and tell them how to do it -- This
is even more risky than (b) because the team is more likely to revolt.
The chance of success is only slightly higher than (b) and depends on
(d) hire the cheapest folks that you can find and let them
self-organize -- This will almost certainly fail to produce results
and is the source of many failed "Agile adoptions."
- I think also team based organizations do need leaders and there should be a succession plan for CTO and the like.
I read this book years ago before starting with scrum and it deals with some of your concerns.
M.On Fri, Aug 6, 2010 at 3:24 PM, Satish Thatte <smthatte@...> wrote:
From my own experience (in a role of traditional project manager in my past industry experience), project plans elaborated with Gnatt charts, etc., do not work well for software projects, unless the project requirements/scope is very stable, technology platform is very stable, there are very low risks, and it’s a simple, small, short duration project… and that is a rare occurrence indeed.
CEO, New Synergy Group
Hello, Satish. On Thursday, August 5, 2010, at 7:40:49 PM, you
> In traditional project management, project managers still prepare elaborate
> project plans (with Gantt charts, etc.) and tell each project members their
> tasks, start and due dates, task dependencies, etc., and then try to track
> or manage them.
How's that working for them? :)
The opinions expressed here /are/ necessarily those of XProgramming.com.
But I might change my mind.
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.851 / Virus Database: 271.1.1/3050 - Release Date: 08/06/10 03:37:00
I keep six honest serving-men (They taught me all I knew); Their names are What and Why and When And How and Where and Who.