This one has bugged me for some time and I heard a reference to it again the other day which has prompted to me ask about it here.
At last years Agile Development Conference in Salt Lake City, I was on a park bench panel with several others on Adopting Agile. The panel had been running for maybe half an hour and I happened to have one of the four "speaker chairs" at the time and I'd just finished speaking quite a bit myself. Alistair Cockburn came in and took one of the speaker chairs. He said that he'd just come from a presentation by Roy Singham, CEO of Thoughtworks, and Roy had said that to do Agile required 50% of the people to be experienced in Agile. Someone in our session asked Alistair if that meant 50% of the people had to be trained (e.g. had to have done an XP course - for example) and Alistair answered no. Not just do 50% had to have done an XP course, they had to also have done an XP project.
I heard just the other day that a "50% must be experienced" assertion is also made in the Scrum book (I don't have the book so I don't know if this is true or not. Also, FWIW, I quite like Scrum).
I am intrigued by this because I'd like to understand it better and learn. It just doesn't match my experiences at all. However, I am not interested in a "FDD is better because..." or "method x is worse because..." type of discussion. I'd just like to understand better why such a high number is required.
My experience is about 20-25% or 1 in 4 or 5 people need to be experienced. However, I can qualify that to be 1 in 4 or 5 need to be what I call an A-class. That is, they do not even have to be FDD experienced. When I do an FDD project and the majority are not FDD-experienced, I run my 5-day workshop first and then proceed to the kickoff and the first FDD process.
This isn't what I think works, it is what I do. It is my experience across many projects and many years.
So, what are your experiences and thoughts in this regard?
Jeff
Who makes daily design decisions
Immediate thoughts: Might have something to do with how many people are involved in daily design and refactoring decisions.
If pair-programming is the main way communication, design and programming is done in a project team then having at least 50% of the team experienced means you can pair up experienced people with less experienced folk so that you do not have 2 novices working together making significant design and refactoring decisions. I actually think XP would really want about 75% experienced so that pairs of experienced people could be working together significant amounts of the time without leaving pairs of novices working together. No data or experience to back that up though.
Feature teams tend to be mostly 3 to 5 developers working together (IMH experience) one of whom is the chief programmer i.e. experienced. This gives you a rough ratio of 1 experienced person to 2 to 4 not necessarily experienced people when daily design and refactoring decisions are being made.
I don't remember how scrum is organised.
Different experience
Hi,
well this doesn't quiet fit my experience. I was a member of a
6 person XP team with just one guy with XP experience. The rest
of us learned the XP practices quit fast, because of the pairing
practices and the relativ simple techniques used.
Of course it took us a few weeks to get safe, but that's
quiet fast compared to other approaches I used until now.
For me the difficult part in XP is not learning the practices
but following them consequently (it is a high discipline method
to me). For mastery you need to know the whys but as you should
start with the sugested standard method, that is no problem
at the beginning.
So far for XP-experience as stated in the article. Nevertheless I
always would vote for an pretty large amount of experienced software
developers (in any software development project, with any methodology).
I don't know, if there is a magical border at 50 percent.
I would say, the more the better. And with more inexperienced people
the risk of project failure rises dramatically. Maybe 50% is an
absolute minimum but having 50 percent experienced developers
is seldom the case (which fits most projects failing one way or the other).
For me software development is all about the people and their
knowledge and competences (not only technical but also social).
Ciao Alex
http://www.alegu.de
XP experience or experience in general
OK Maybe I misunderstood. I was talking about experience in general. 50% need to have done an XP project previously for a project to be successful? Again that sounds high but again it may be due to the fact that most of the communication in an XP project is in programming pairs.
However, XP is not hard to learn, I'd expect experienced developers to pick it up quickly. In fact I'd expect Jeff's A class developers to be able to pick up any coherent process quickly and succeed with it because they are good. Its not the process; its the people. And no they do not have to be heros or supermen; just have a decent mixture of skill, experience and emotional intelligence.
50% isn't my experience
I don't recall that figure from the Scrum book either and I've read it cover to cover. I do recall the notion of at least 1 really experienced senior developer per scrum i.e. about 1 in 6, but not the notion that 3 from 6 had to have done scrum before.
Anyway, enough of Scrum...
I've been giving this topic some thought too lately. Over the last 5 years I've run (or been closely involved with) over 15 agile projects in carrier grade applications for wireless phone companies or wireless device manufacturers. I've been thinking a bit about what worked best. Often I've introduced teams to FDD with no one else with any agile experience. In every case, this worked best.
In the worst case, where decent adoption took aroun 18 months, the team had pervious exposure to (some) XP practices.
I think the biggest factor is cultural. Where there is a culture of discipline and professionalism and a knowledge of software engineering, I have found the results to be very positive. Where there is a culture of "what is analysis", "we have no time for design", "we get punished if we don't just cut some code" resulting in indiscipline and poor adoption. The indiscipline may extend beyond the working environment and be an attribute of the individuals.
I also feel that attitude to team work is important. Where there is a good collegiate attitude amongst the developers to work in a team and a management that encourages team working then the results are also better. Where there is a culture of individual heroism and a group of people who don't like team working then the results are poorer.
If others feel that there is a need for 50% of the team to have a proven track record of team working (rather than a proven track record in "agile") then I could buy that argument.
Going forward in new opportunities I will be focusing on "a culture of disciplined approach to software engineering", "a culture of team working" and "breaking work down into small (preferably client-valued) elements which can be tracked transparently through a series of transformations culminating with quality assured complete".
I truly believe these three aspects of FDD (or other agile methods) are where the lions share of the gains come from.
David
--
David J. Anderson
author of "Agile Management for Software Engineering"
http://www.agilemanagement.net/
read it again
"Scrum requires a balance of individuals with at least 50% of them to be experts ..." page 121
I think you are misinterpreting
You quote from page 121 correctly, from a section on the psychological impact of Srum. However, I think that you misinterpret.
The sentence does not suggest that 50% of the people must be experts in Scrum but expert in software development. This is a common aspect of agile methods - they rely on good people. They gain speed through trust and eliminate bureaucracy designed to regulate performance.
FDD differs from Scrum in this respect because FDD insists on reviews, and standards documents to facilitate review. FDD pushes knowledge from a small number of experts to a large number of journeymen and apprentices. In this respect, FDD scales better and works better with poorer quality people.
I would go as far as to say that 6 good people in a team of up to 50 will produce results in an order of 4 fold better than a typical RUP project in a Fortune 1000 company. When you get 6 really good people and a team of solid journeymen then the results can be fantastic - way beyond 4 times the typical performance. Jeff knows this only too well (and IMHO rather takes it for granted).
David
--
David J. Anderson
author of "Agile Management for Software Engineering"
http://www.agilemanagement.net/
Relying on good people.
This is a common aspect of agile methods - they rely on good people.
I think this is a common misconception - agile relies on good people no more than any other method.
What it does do is make it explicit: if you want things to work you need the right people. No amount of process can make up for a lack of them. We know this - the 20 volume process definitions like MethodOne and others simply dont work. You can't expect that by trying to document every little aspect of the hundred of activities that are part of software development that you can reduce a process to something that can be carried out in the same way that McDonald's makes burgers.
It's hardly suprising that the agile folk address this - from the manifesto it's clear there's a focus on the human aspects of software development.
And it's equally unsuprising that propietary processes pushed by large vendors would conveniently fail to mention this fact. It's lying by omission. Just because most agile folk are up front and state that you need the right people, and other methods don't state it, people want to automatically jump to the conclusion that only agile methods need good people.
Crap.
I think this thread is more along the lines of what we should be thinking about. Rather than sweep the issue under the carpet with a few more volumes of process definitions, it's more useful to contrast how the various roles are organised and the resulting lines of communication for the various approaches. This might give us the best clues as to the conditions under which each approach is suitable. As you've noted here with FDD, it may also give us insights into why some approaches may scale better than others and how the mix of roles might change (or not) as we scale.
Paul.
Right People in the Right Roles
Paul,
You won't get an argument from me that it is all about the "right people in the right roles".
However, there has been a reasonable body of work published by the agile community this past 12 months which seeks to measure just how many good people you need on a project with a particular agile method. My guess is that this topic is an active area for people such as Alistair Cockburn, Jim Highsmith and Barry Boehm.
Personally, I think you are on a better track. Defining roles and lines of communication and studying how that affects performance would provide insight as to how different approaches scale. Of course, not every method relies on person-to-person communication. In the more radical self-organizing methohds, some form of visual control is used for communication. Hence, communication is achieved through some indirect method such as a burndown chart on the wall with the "owner"'s name against it and some form of status self-declared.
Of course, if you substituted "good" for "disciplined and professional" in the above thread then you might be getting more to the nub of it. It could be said that most methods assume "discipline and professionalism" but they probably shouldn't.
David
--
David J. Anderson
author of "Agile Management for Software Engineering"
http://www.agilemanagement.net/
50% isn't my experience either
I have had similar experiences to David. All it took to succesfully introduce several FDD practices, including design and code inspections, and 2 week development iterations was one person who understood the practices and knew how they worked - namely me. You have to get management buy-in, particularly at the project/development manager level. This is in relatively large development groups (30 plus developers) with management discipline. All it took to get inspections worling was management telling they had to do it, and me running the first few inspections with an inspection form/record and set of simple rules to follow. Enough people picked up on it that it quickly became an accepted part of the culture. Good developers liked it; weak developers didn't like it. But the strong developers quickly dominate the process. The biggest problem is making sure it doesn't get personal between people. And yes, some people never get to like inspections, but they are the people who have problems working in teams.
And BTW I think the 50% figure results from a 'no management' form of Agile which would not be my choice (an understatement
)
phil
One is often enough...
I have worked on two fairly recent FDD projects, where I was the only one with any experience. I introduced FDD to both, and it ended up working just fine. It did take quite some effort to begin with, as any sort of culture change is always difficult. After going through various resources (web, books, etc) and stepping through the processes, people caught on fairly readily.
Sometimes it is actually easier to train less experienced developers, because they don't have strong preconceived notions about how things should work. I guess that can apply to many situations.
The feedback I got was all positive: managers liked the reporting, developers liked working in small teams (with lots of feedback), and even grew to like inspections.
If you are the only experienced person, you will invariably have everyone emailing you or dropping by to ask questions, so just one expert on a large project is not enough. Up to around 15 or so seems to be manageable for one person.
:: Gavin Baker - http://antonym.org
What you mean by 'experienced software professional'?
Seems like we have not defined the concept of 'experienced software professional' yet while we are discussing the percentage.
What do you mean by 'experienced'? Does it count when one has worked in software field for 10 years but without any software degree?
I am telling the true situation. In the software company I am working at, of the 108 'professionals', less than 20% were graduated from software department. Others are not but they strongly believe they are software professionals because they have got their certificates of 'software training classes' for six months. I am not sure but FDD training course might be one of the courses they have taken in their whole education profile.
To my understanding, even in US, many of the 'software professionals' have switched into software development industry after six months short period of training. They claim they are software professionals. Are they? If not, who can claim they are? Bill Gates does not have a software degree. Is he a software professional?
I believe we have spent too much time in the research of theories instead of dealing with real situations and practical problems. Are we spending too much time on unimportant topics here?
Of course, I am not saying that FDD is a nonimportant topic. But I would say that FDD is no more than just adding certain new lights into our existing development methodologies.
The conclusion is that, even the whole team are experienced XP or FDD gurus, they cannot guarantee the successful development of a project. On the contrast, if all of the team members are XP/FDD experts, I would worry about the project because there are too many 'gurus' in the team.
Jonathan
Professional Software Development
For a good and thorough definition of what it means to be a professional software developer, I would recommend that you read Steve McConnell's recent book, Professional Software Development.
David
--
David J. Anderson
author of "Agile Management for Software Engineering"
http://www.agilemanagement.net/
Kickoff and FDD process #1
My experience:
It's possible to do the domain modeling starting with the kickoff and one experienced lead modeler and the rest new to FDD as long as the lead modeler can communicate well and keep the engagement/interest up and there are a couple of the participants that switch on to it quickly. That is my experience but maybe it was luck. I think out of a group of 15 or so, you have reasonable odds of having one or two "modeling naturals" that will carry the team through the first two days until the others begin to "get it". These naturals are not always experienced OO developers - in fact OO developers who think they know it all can be a serious impediment and I once encountered a SME with no prior knowledge of OO who put most of the developers to shame when it came to colour domain modeling.
Having a good facilitator is essential of course and you really need to stack the odds in your favour (good coffee, good room with natural light and plenty of space away from the normal place of work, plus some humour, interesting conversations, ...) to pull off a successful workshop.