Published by Fabian on 18 Oct 2009 at 10:40 pm
Developers do not need SCRUM
During my daily job we are talking a lot about SCRUM. We need to talk a lot about it because we need to convince customers that SCRUM is a good idea. But I think we should never talk to developers about SCRUM. The reason for this is that SCRUM is a project management framework. It is made for people managing projects. And it is a great tool for that. But let us face it: developers do not care about project management. It does confuse them. They are developers not managers. SCRUM can be explained easily to them:
Listen lads & guys, you are tasked to work as a team on the companies product. We are doing it differently this time, instead of working on the boring DB all day, we are rotating tasks so everybody gets some joy. And because we just want to do the best for the product, management comes tomorrow to us and tells us what high prio tasks to work on. Deadline for those tasks is in three weeks, but I am sure we can make it. I also do not want some boring project status meetings. Just meet every morning at 9 and in 15 minutes let us say what we work on so we can help each other in case there is need. Ready? Lets do it! In case you need anything just come to me.
See? No word of SCRUM or any of its buzz-words. Developers are happy and they do not have to bother with management. Thats management stuff. Instead they can experiment with eXtreme Programming practices, because they are fun for developers.
And from managers point of view this is also ok. They have everything they need, and in case they need any technical expertise they will consult someone of the team as they did before.
What do you think, is the hype with SCRUM perhaps too much for devs?
Friedel on 19 Oct 2009 at 12:59 am #
I don’t like a culture where people do what other people say without understanding that. I believe it is a benefit when you understand why you do things like you do it.
I agree, that in your example it is not important that the developer knows that method (which he is managed by ) is called SCRUM. It is sufficient to understand the manager style in general.
In my team we recently focused on my Manager’s Management style and how he/we can improve that one. We don’t use SCRUM but we needed more than one meeting to figure out which roles people have in our team. If we would use SCRUM we have an unified language. That might help. (I’m not familiar with the SCRUM)
So, the point is, that you have to understand the management style and if you live in a SCRUM world you can buy books and read articles about it.
NiKo on 19 Oct 2009 at 8:15 am #
I don’t agree. I cannot stand project manager with zero knowledge of basic technologies involved in a project, so I think developers are clever enough to understand the basic principles of Scrum. Also, as the Scrum team must be totally involved in the process to be really efficient, I just can’t imagine they’re not aware they’re using scrum tools (brundown, backlog, sprints, etc.)
What’s important is the work of the Scrum Master: he must ensure the team won’t ever be disturbed in its work by something or someone that is not directly related to technical matters of the current sprint.
David on 19 Oct 2009 at 9:28 am #
What you are describing is an exact opposite of SCRUM:
“And because we just want to do the best for the product, management comes tomorrow to us and tells us what high prio tasks to work on. Deadline for those tasks is in three weeks, but I am sure we can make it”
One of the SCRUM key points is that the DEVELOPERS are in full control of the time plan. They are the only people who know when the product will reach a specific state! “Deadline for those tasks is in 3 weeks, but I am sure we can make it” is last millenium’s team leading style.
I agree that SCRUM does not always work, but it’s a great concept that requires some radical changes in management. Since you are from Germany, I can recommend reading the last 3 or 4 “iX” magazines – there’s a great series of articles about SCRUM in there!
Thomas Ferris Nicolaisen on 19 Oct 2009 at 9:42 am #
Hi Fabian. Although I don’t see anything strictly wrong about Scrum in your statement (although you should mention retrospectives), I think this viewpoint is bit unhealthy.
There is a chasm between business and development, which is very disruptive for the success of a company:
Every day, developers make a hundred tiny decisions which are not necessarily in the best direction for business. These decisions lie in implementation details, spending too much or too little effort on a particular bit of code, selecting a certain layout or design, choosing this or that algorithm or library.. It is the job of a developer to make these decisions, but she/he needs to have a good understanding of the business to make as many good decisions as possible.
Likewise, business people make decisions that affect development. Going for this or that customer, signing this contract, buying that product, etc. For a business to make the most of its technical resources, it is important for the suits to have a good understanding of their developers.
Scrum forces business people down to the development level, and forces programmers up to the business level. In my Scrum implementation, I would love to replace “Developers are happy and they do not have to bother with management.” with “Developers are happy and interact with management every day.”.
There is a lack of business understanding in our industry, some places even ignorance. I think Scrum is a step in the right direction to aligning both sides. Like Friedel says, having a unified language is important, both when discussing products and solutions, as well as methodology.
Dave Dash on 19 Oct 2009 at 11:14 am #
I agree – don’t need need scrum, but I think it can be very healthy for teams.
We used scrum at Delicious (and they probably still do), it was a good way of just having engineers be organized and deliver deadlines. Scrum-mastering was tough and the learning curve was a bit steep, but we ended up being more predictable – which was a nice way for us to know what features we could assure our users would be coming out soon.
-d