Why do people complaining that they can’t do agile development with 50 crap developers not see that the problem is in the second part of that statement, not the first? I got an e-mail last week that shows the point perfectly:
We discussed whether an agile approach is right, and I concluded that not everyone can work that way.
Quite true. I find it self-evident that not everyone can do software development, agile or any other way. That requires brains, knowledge, experience is a plus, and hopefully some talent as well. And of course, there is no generic approach that works in every context.
We think that an agile approach asks programmers to be much more engaged than when they’re just being served what to do
It’s hard for me to make a comparison to answer this. I’ve always tried to be very engaged in my own work and I expected the same from everyone else working with me, even before I ever did anything resembling agile. I’ve never seen a project where people were asked not to be engaged into what they need to do, but out of general principle I would refuse to participate in one.
If your programmers aren’t engaged and they get everything served to them, your problem is right there. It is not in a process, agile or non agile.
Which means the choice of people is very important
I completely agree. Once again, this isn’t particularly specific to agile software development approaches – or even software development at all. This is important for any craft. My former colleague Relja Jovic, who was the executive editor at PC World Yugoslavia when I worked there, used to say “From shit, you can only make a shit pie” whenever we were asked to get someone unqualified to write an article (“how hard can it be?”). That holds true for programming, testing, analysis, project management and anything else to do with delivering software. With crap people, you get crap output. Tough luck. Maybe hire people who know how to deliver software instead?
|
|
The problem for the consultant comes into play when you consider that you actually need to tell your client that they did a lousy job of hiring programmers in first place. Though this might not hold, as company policies usually grow their particular style of worker. That does not mean, that these people can be taught different ways to behave, but there’s some hump of pain to overcome first.
But I agree with you. Reframing those quotes to “we did a lousy job of hiring”. On the other hand, maybe you can be glad not get hired by those peeps then?
Another manager complaining about his own mistakes: Hiring the wrong people. This is not the problem of the people working in this company, it’s the problem of the manager who hired em in the first place, he did a mistake and now blames the poor staff.
Blaming others for own mistakes is more of a management problem than a developer problem (because they have more people to blame).
On the other hand there is no room for scrum or an agile process if you think the people are engaged from the first moment on as much as required. This opposes inspect and adapt and in my eyes this is the most widespread antipattern in scrum.
I am a strong believer that people will engage actively because what they can influence is simply pleasure vs. pain for a time that is 1/3 of a day. Beeing passive and not trying to create better circumstances would point out to a mentally challenged person, so i must come to the conclusion that the environment there does NOT encourage people to actively engage, apart form the scrum.
I think the interesting question in this discussion is “Given the fact that we have 50 less fortunate developers, what is the best development process for us at this stage? How can we still make decent software?”
The reality is that programmers vary in skill. How can we best utilize the resources we have? It’s not interesting to talk about how we got these people. We have them. Don’t hire more of them. What can we do now ?
To master the agile disciplines I believe that you need to be a programmer that is passionate about your occupation. Some are. Others not so much. We need to realize this and act accordingly.
Eric Evans has a great talk about strategic design. You need to put the right developers in the right places. Hero developers that are hacks away at the code needs to be put in places where they can add value, and not do any harm to system critical components. I think there is room for most types of developers, you just need to put them in the right spot. To do this you need people that know who to put where. This role, I think, is best filled by technical managers. Skilled developers with managing skills that is.
Later.
Couldn’t agree more!
It reminds of the the line from Blackadder Goes Forth when he’s asked what they should do if they step on a landmine:
“Well, standard procedure is to jump 200 feet in the air and then scatter yourself over a wide area”
Whenever a manager asks me “but what if we only have crap developers”, my default response is “well, in that situation, standard best practice is to fail”
Good post. I don’t know why so many managers refuse to fix their hiring mistakes. Instead, they just compound the mistake by keeping shit people around without realizing the toxic affect those people have on their team.
If that manager actually has 50 crap developers on the project, how can they follow any project strategy that isn’t agile? Wouldn’t they want to inspect and adapt often to ensure that the expectations and timelines had a chance of success? And doesn’t it make sense to minimize the project risk by trying to deliver something early and often?
One of the things that I really like about introducing an agile process to a team (especially a bad team) is that the team members settle out like cream in a bucket, making it really easy to see who is good and who is shit. The only “failures” I’ve seen with agile are because managers refuse to take action on the team members that sink to the bottom of that bucket.
Assuming there isn’t an option of firing a lot of the developers and getting better ones, agile might be *exactly* what they need. While bad programmers are bad programmers, they are each coming with their own unique strengths and weaknesses, and holes in their skillsets.
When they work together, the strengths of one can compensate for the weaknesses of another, and they can learn from each other. And what gets passed the team effort of working on the code can be caught by TDD, or at least unit testing and acceptance testing.
There are certainly people that are just not cut out to be Software Engineers, either because they don’t have the ability to abstract the problem in a way a computer needs ir, and visualize what’s happening when their program runs. And there are certainly people that don’t have the ability to grow by learning from their mistakes, or are not motivated to do so. But if they’re simply inexperienced, or “learned the wrong way”, they are not lost. Hire one or two good developers to mentor them, and you have a fighting chance.
Two questions come to mind. BjartN alluded to the first and that is “Can 50 crap developers write good code under ANY circumstances?”
Second: “Given 50 top notch developers, can Agile / Scrum / Kanban / Lean really take credit for the outcome?”
“Maybe hire people who know how to deliver software instead?” I disagree. As an example a company can be started by technically incompetent people whom do a lot of work and somehow *magic involved* these companies manage to evolve to very profitable ones and still end up with a team of not so skilled managers or developers. It’s an evolutionary process most of the time and usually companies gradually raise their recruitment bar. Now when you reach that point where you see that Agile could make you more efficient but you don’t have the right people, you can think of firing all your team members.. Now you have legal problems, knowledge problems and firing someone with whom you been closely working for three years and he’s your buddy isn’t very pleasant either. Instead my answer would be that there is no easy way out of it, it’s a very common problem and it may not necessarily be anyone’s fault. If the management thinks it’s worth the investment they can fix it but they should understand it’s going to be horribly painful.
I am a crap developer but I made an exercise here
http://www.testalways.com/2010/07/05/find-bugs-and-patterns/
to serve testing purposes.
The problem with too many developers is that market seems to still ask for more, but many go into development without any passion, but just for financial reasons
Yeah, to have the best team possible, you must have very skilled, self-motivated people, and a process that doesn’t get in the way. Agile methods fits well here (although ‘no process’ would probably work in this case, too…).
But in the real world, you didn’t hire your developers, but even if you did, you had to accept less-than-superstar developers, because superstars were too expensive, or hiding somewhere, or weren’t interested in building your boring enterprise software.
In the real world, you can’t expect to have the best team, you must to do your best with what you have.
Agile processes may fit well in these cases as well, but many times one should be less ‘radical’ on its adoption. Crystal seems to be much more flexible to accomodate these scenarios than, say, XP, without becoming a ‘whatever you like’ methodology (like most ‘Agile’ implementations do).
And blaming only the developers’ skill level for a failure is just as bad like blaming the process. It’s just an excuse for bad decisions.
“When they work together, the strengths of one can compensate for the weaknesses of another, and they can learn from each other. And what gets passed the team effort of working on the code can be caught by TDD, or at least unit testing and acceptance testing.”
This approach is problematic, because if everyone on the team has got their specific areas of expertise, what happens if one (or more) team members get in to an accident, and have to take sick leave (or die)? I was recently participating in a ScrumMaster training and we were asked the following question: “How many members of your team can get hit by a buss without causing catastrophe?” The answer to that question was 0.
In our case, the problem lies in the resourcing, not the skill sets of my colleagues. The situation is not acceptable, but we (me and the team) can live with it, because replacements can be found by transfering people from less important projects. But what if a team of developers, where each one has got a very narrow and unique skill set, has to face the same situation? I believe that it could really hurt the project in a serious way.
And like the author said, this is not a problem concerning Agile methods. The scenario I presented will hurt the team of less fortunate developers and their project in a serious way. It really does not matter what kind of software development model is used. The crucial mistake was made by the manager, who hired these developers in the first place.
Well written blog. I personally feel agile consultants should evaluate if the company has “code monkeys” or software developers. Agile assumes competent software developers who care about making good software/product.
The industry also has a lot of waste in managers, vice presidents and directors, who work well in a command-control structure. It is very hard to change the culture of a company when the number of authoritative and wasteful resources out-number the worker bees who want to impact change. HR policies also make it hard to lay-off folks who are not competent. I am not sure how/when/if the industry will ever give up all the extra-fat ?
I agree that if you have an army of incompetent developers on your project, this doesn’t look good for the outcome.
What I don’t see in this blog entry is that there are also crap managers. In my experience WAY more frequent and usually very strong in demotivating his team by the sheer amount of absurd situations. I’ve witnessed often enough competent people going to waste by these career-and-ass-kissing imbeciles. Alas not everybody has the choice of quitting. We need to eat and have families.
Often managers are taken between the hammer and anvil of their company and customer. Crap managers take the easy solution: Push their crap down instead of assuming it. In practice there isn’t much you can blame a developer for. He’s there to code and other people are responsible to check his work and manage the project. They’re at the bottom of the food chain.
Maybe things would be better if those crap managers do the job they’re (well) paid for ?
End the end, who are we to blame those “crap” developers ?
Separate the 50 crap developers into ten teams of five people each. At each agile “sprint” (or whatever, depending on the process). Give the same task to all teams during the sprint.
Then evalutate the results, and only choose the best effort. Let all teams start from there with the next sprint.
Potentially, you could turn your 50 crap developers into ten good ones.
Nice article. Actually, I’ve seen worse where such teams implement agile.
Its really fun to watch how certain practices are implemented in their context. Standups running for around 1-hour, where everyone is questioned about their commitment daily and things like that, just to give an example.
I also think, once a manager has said ‘I have crap developers’, he’s given his intent pretty clear. There’s no trust/respect around. You can’t do agile on top of it.
There are better forms of management in this context. Things like ‘tell them what to do’, ‘monitor heavily’, ‘strong/multi-layered quality check team’.
On a serious note, I think a process should be tailored to the people you have. You can’t talk about either without considering the other.
Don’t do agile. Do what is best with your people.
Looking solely at the title, I felt something was wrong, and it’s really the number of developers. Can you do real Agile with that amount of developers, regardless of their quality. In my opinion (and this is only my opinion), the overhead of waterfall management might start looking acceptable when you start having a lot of developers (and 50 is a lot). This is actually one of the agile limitations.
Now about your last point, “the choice of people is very important”, but this is a given, and it is very important in any methodology. If you put bad programmers on a project, not matter what the methodology is, then the work will take a lot of time, and the quality (especially the code quality for later maintainability) will be very low.
Again, this is only my opinion… Thanks for sharing.
I find much of this discussion a bit incongruous with notions of agile and of my experiences with agile development.
First, everyone is someone else’s crappy developer and it is very difficult to separate the good on the right and the crappy on the left. Second, often you have to make do with what you have and trying to identify who is at fault just wastes time. Often, I think if I am only working with good developers, either the crappy one me or I am working with only two or three others.
Typically a team is a mix or good, crappy, dedicated and ambivalent people.
The main claim that I would make is that the *first* benefit of agile development the the power to focus people on the most important task that needs to be done and to pursue getting it done.
In classic XP, user stories that can be implemented in 1 day are written and prioritized. They are assigned to a pair of programmers who concentrate on only that task. At the stand up meeting every morning, people discuss their problems and any lack of progress.
This focus should allow even poorly preforming teams to be more productive. In a typically waterfall (or more likely a “no process” process) a crappy developer can be left to flounder for months between milestones. The results might be the same, but if you have even one competent developer to help out, this focus should help get better results.
I don’t believe you need to have a team of superstar developers to produces good software. Every team will have people who are more or less competent. Process is about getting the team to work and we should not be using crappy developers as an excuse
Not true in my experience. Someone telling you “We have 50 crap developers” definitely only states his own (wrong) point of view, as nobody can pay 50 developers who don’t deliver. Such a company would be deemed to fail and close.
I more believe that the situation is like with a friend of mine who works at a big company and who just doesn’t believe that “standard” developers can use such a “geeky” technique. Most people don’t see that agile isn’t any “harder” than standard development. They just hear all those fancy terms and think is complicated or esotherique or something like that – maybe they also think “it works our way and we did it this way forever – why change?”.
A company with 50 crap developers can work agile. Just invest some few days and teach them. And maybe this helps them getting away from what may just be “crappy” organisational structures and too much bureaucracy.
May be or may not be correct. The is due to, sometimes, with developers and sometimes with managers and even sometimes the policies if the organization.
The developers, though they are bright and easily can learn and adopt these all good practices, are never gone into this practice at all. For example if the developer grown in an organization where the co-developers and seniors are not enough talented or open to teach the juniors, the best practices. They always use them as an assistant to complete the/his work and never spend time or coach them. Even these senior developers are also grown and came to this organization like this only.
Gradually, the juniors with these all bad practices will become seniors and the story continues…
So what I feel is it the responsibility of the team leads, senior developers (all doing all these practices) should also spend time to educate and coach juniors.