Anyone ever tried to assimilate Scrum to a team where most developers are just mediocre? I mean developers who aren't the most tech savvy, has bad time-management skills, but most of all - lack the sense of personal responsibility and commitment.
Do you think it can work? Or would you try a different methodology?
The Agile Manifesto disclaimer is telling on your question. In the first point:
'Individuals and interactions over processes and tools '
I think if the individuals have problems then methodology is futile.
I did not personally try it, but I saw a project go down b/c of this problematic situation.
Agile development takes discipline in developers. Many people think that agile means, no documentation, no planning, no specs...so you need no discipline.
But to be successful with agile methods needs commitment and responsibility.
If you have to work in such an environment it is more likely that you succeed by using a more guided methodology. And don't forget: Only because you don't use a puristic approach to agility ("doing it exactly the way they told us in that CSM course") doesn't mean you don't take to take home the benefits of timeboxed iterations, pair-programming etc. You can do many good pracices without using scrum - strictly speaking.
Many agile critics (and pundits) say that agile works only with brilliant developers. I tend to agree. If you trust me, then Scrum wouldn't work with mediocre developers. :-)
Why is this so? Well, because agile assumes that so much stuff emerges automagically as developers code away. Architecture, for example, is rarely planned for; it is supposed to turn up as code is added and refactored over and over. Brilliant developers can make this happen, but mediocre ones cannot.
On the one hand, planning in detail for the short period of time that is a sprint would work well. On the other hand you will have problems getting those developers to make a real commitment to getting the planned work done during the sprint.
I think it may be better than not doing it, but I wish you the best of luck either way. :)
I've implemented Scrum with such a team.
It took a few iterations for them to get on board, but they discovered that Scrum made them better developers. They appreciated being able to influence the process. At each iteration's retrospective we examined success factors and challenges, and as a team we worked to eliminate the barriers the challenges created.
At that year's annual employee recognition dinner, my team nominated me for an achievement award: not for my achievements, but for the achievements the team was able to attain as a result of moving to Scrum.
Too many teams are beaten down and demotivated because they don't have a say in the process. The lack of personal responsibility and commitment may be an artifact of the current development process, and Scrum may help your team overcome that.
I think te most major thing with Agile is the fact you should work in small teams. Anything more than about 6 people and your team is too big. Personally I think 4 is a good number. The bonus is that with much smaller teams people are much happier to take ownership of what they do and face the consequences of their mistakes (Provided the rest of the team are happy to step in and help with any schedule slips, ie not sit and blame the person who made a mistake for all the problems). Quickly people learn how to schedule well because they are scheduling such small tasks. After a few months they will know TRULY how long any given task is likely to take and the system will then be invaluable.
If they are still suffering after a few months then it will never work and, tbh, its unlikely anything will get them to work. IMHO, at this point its worth admitting that they are useless. Some may disagree but if you give people chances and they don't take them you can either spend your whole time trying to get them to be useful, move them to something they CAN do, or get rid of them. I don't see many other choices ...
You can use SCRUM to your advantage with your situation:
I've had the "privilege" of working with less-than-optimal teams using a Scrum-like methodology, and found it more successful than a traditional waterfall methodology would have been with the same people, for reasons including:
work is done (and progress is measured) in smaller chunks, so if your team messes up or misses a deadline, you know sooner and can adjust sooner. it's also easier to hold people accountable for problems wtih one-day work items vs. month-long screwups.
Scrum has a higher expectation of transparency within the team, so if things go wrong (as they certainly will with an underpowered and/or under-motivated team) you'll more easily discover the problems. In traditional waterfall methodology, it's more acceptable for a developer to "go dark" for weeks on end-- and with a bad team this is the worst possible thing that can happen.
Developers who have good basic skills but are sloppy and/or un-motivated can particularly benefit from Scrum's high-touch, incremental approach.
Daily standups mean that every team member has to at least show up for work every day and come up with something to say they've been doing. This can increase motivation for some devs who may be lazy or distracted but who also don't want to be embarrassed in front of their peers. And standups provides at least a minimum bar of transparency and accountability without hounding grumpy team members for written status reports.
Scrum also has a higher expectation of transparency outside the team (business owners, etc.), so there's more opportunity for more people to see how bad your dev team is, and hence you'll more likely gain the support of your company to upgrade your team.
if you have a mix of good and less-good devs on your team, Scrum (with higher expectations of transparency and lower expectations of individual ownership without feedback) makes it easier for the good devs to help keep the team on track.
Note that I agree with the other answers, that the ideal situation is to get a better team. But there are certainly cases where you have no choice, e.g. rescuing a project gone awry with only a few months before shipping, where replacing the team is not feasible and you need to do the best with the folks you have.
The mark of good teamwork, no matter what the methodology, is the ability to achieve excellent results with ordinary people. It is very much about motivation, communication, and cooperation. If you don't have these things, it really doesn't matter how brilliant the individuals are.
If you include some XP ideas into your scrum framework, you may be able to bring the "weaker" developers along a little as well. Probably the best example would be to implement pair programming. I was sceptical about it at first, but am now completely sold on the idea. While it falls outside the scrum methodology somewhat, you have to pick and choose what works for you from all the agile methodologies out there, and not be constrained to a single tenant.
Is it just that team of developers who are uncommitted/lacking in motivation or is that the general feeling within the organisation, i.e. is their attitude just a symptom of bigger institutional problems?
In that case, Scrum could be more beneficial here (as other commenters have noted) so long as you have sufficient clout to give them the freedom to get things done.
Q.E.D.
I am sorry to say that Jamie Ide's 3-point argument is flawed. It assumes that the many teams that are successfully using agile methods (point 2) are composed of the mediocre developers that are described in point 1. However, we have no evidence of that. These teams might as well be composed predominantly of above-average developers. This would offer an alternative explanation as to why they are successful.
It depends on your definition of work.
Ken Schwaber actually said in his Google Talk that crap developers that use hopeless tools and hate each other can certainly follow the scrum rules and produce increments of crap software on time and budget.
... so I guess mediocre developers with industry standard (i.e. average tools) and an average level of team co-operation is likely to produce increments of mediocre software on time and budget.
If that's what you're after then fine - but here are the problems:
What I like about Scrum is this: It is the team that exerts pressure on the erring team members. Not the scrum master, not the team lead (no such thing in scrum), and not even Management.
This makes addressing issues on commitment and responsibility easier.
I've seen it done with average coders and it works. The good thing about scrum is that in each iteration (sprint) you could use some time to improve their skills (books, videos...), put old code into tests - maybe a goal could be to put 1% of the old code into test in each sprint - to clean the mess, do some pair programming so they learn from each other....
Mediocre developers can definitely follow Scrum and apply it successfully. But this is not an end, the end is to produce software. Will they produce good software? I don't think so, or at least not with a very high velocity. Finding innovative solution, coding, persistence, orm, software design and architecture, unit testing, refactoring, code reviews, acceptance testing, build, automation, etc require some skills. For this, you need talented people, or a least a couple of alpha developer.
The most important is their learning willpower. If they are ready to learn and progress, then Scrum can guide them. If they are satisfied with things as described, then ...
Moreover, with Scrum the Team will know sooner how they are doing, which could challenge them.
Add a seasoned developer to lead by example, if possible.
The short answer: yes, Scrum works with teams regardless of the innate ability of the team members.
The long answer: a software development team will have a natural best rate of functionality implementation. Most teams don't run at their best rate because they are fighting hidden impediments. Scrum exposes those hidden impediments so they can be addressed and removed. Once the process-related issues are gone, then the team can focus on skill improvement as the next step to increase velocity.
So, maybe a team of collaborative mediocre developers won't be as fast as a team of collaborative superstars, but a collaborative team of mediocre developers who are working at maximum efficiency will be more productive than a dysfunctional team comprised of prima donna superstars each running off on their own. In fact, a collaborative team of mostly average developers with one superstar who can mentor team mates and step in to help solve their problems will be a very productive team indeed.
Of course it works with such a team. It works the way you and themselves understand quicker that they have to develop some skills. With traditional project management you would find out it at the end of the project.