Lazy developers hate agile and scrum discussion at #sapphirenow
During the #sapphirenow key note, CO-CEO of SAP Jim Hagemann Snabe said that he saw no drawbacks of introducing scrum to parts of SAP internal development and the challenge now was to scale it to the entire company.
I tweeted this, but received immediately a response from an analyst that “Developers hate scrum”
I thought this was a somewhat strange statement, as in my experience 98% of developers love scrum and the rest fear it because of the transparency.
I then got two more interesting replies from twitter, one from @webtonull stating the rest fear it because it is experienced as surveilance (meaning your not really doing it as intended). The other was from @cvitan who came up with the catch-line “lazy developers hate scrum”.
Myself and Twan van den Broek, who has experience from running scrum in SAP projects (see his presentation on the topic), figured out we’d do a short video to share with the world and the SAP Community. This video should be shown below; if not go here . I’ve also added it as a podcast to this post
The one downside that I can see, is the business buy-in to Agile which in turn can be influenced by the scrum master.
When programmers get called engineers and dont understand SAP, I can see why programmers dont get on with the methodology.
The whole business needs to be Agile, and the business needs to be flexible with resources to resolve issues otherwise you are burning time.
I can see Agile being used more and more - check out my blog on the correct methodology for FSCM
Agile or Waterfall - what works best for FSCM?
I read your blog before and liked it, in fact would love to hear about it in even more detail.
Make sure you catch up with the Enterprisegeeks podcasts on this topic
http://enterprisegeeks.com/blog/2010/03/23/enterprise-geeks-podcast-agile-development/
http://enterprisegeeks.com/blog/2010/05/19/sapphire-agile-throwdown/
Dagfinn
On twitter I already asked Dagfinn whether he knew Holger's reason for saying that developers hate Scrum, and I sure hope Holger will respond to the RTs. From the top of my head, here a 5 situations in which developers could hate Scrum.
1. A developer could hate scrum because he thinks that his project manager is just using it to control lazy programmers, which he is not (http://bit.ly/a708CL).
2. A developer could hate Scrum because he is resistant to change (Dagfinn already mentioned this one). Developers are human too 😉
3. A developer could hate Scrum, because he feels micro-managed by his project manager and feels that his project manager is continuously looking over their shoulder to see what he is doing. If this is the case, I wouldn't blame the developer, but look at the project manager first. Most of the time this is a matter of engagement and communication. Especially be careful with "you have to report progress every day" (http://splicd.com/09yQ2WzRHTs/117/119), without setting the right context.
4. A developer could hate Scrum because he doesn't understand what's in it for him. As mentioned on http://bit.ly/cGHzBv (How to Manager Programmers), developers don't like their time to be wasted with non-development stuff. They consider meetings are the worst time wasters of them all and might just hate Scrum because of the "useless meetings".
5. A developer could hate Scrum because when he reports his progress and mentions his issues, his team members and especially his project manager have no clue what he is talking about. As his issues are usually highly technical of nature, other team members will not be able to help him anyway.
Please don't take what I've written here as personal or my impresion of Scrum or other agile techniques. I'm just trying to say that if you look in the hearts and souls of developers, you may find a lot of misunderstood willingness, which unfortunately is too often explained as laziness or rigidness.
I totally concur with you that scrum master needs to understand both the AGILE methodology but also know the product and solution.
For a project to work - the whole project team - including sponsors, scrum master, business users, testers, developers and functional consultants all need to be working together.
It can be very hard for everyone to talk in the same languague but the scrum master should try and speak in a language that can be understood by all.
I am currently being refered as an "engineer" and development is seen as "building".
This is totally useless, and has had a negative impact on the sprint so far.
I try to make the statement that lazy developers will most likely hate scrum in the beginning, but not that everyone who oppose Scrum are lazy.
Human change management sure is complicated, and having a scrum master "psychologist" can help the team to realize the impediments which stop them from being more effective and how to remove them.
It is not for nothing that it will take years for teams to mature and reach a truely performing state (as compared to the phases before forming, storming and norming)
Cheers
Dagfinn
ps we need better twitter integration on the blog system
The reason I ask is because a valuable lesson I learned is to do a cost-benefit analysis before any meeting is held.
On my first SAP project 13 years ago, we attempted daily morning meetings, lasting no more than 5 minutes, where we stood (to ensure the meeting goes faster) and simply asked the status. But I like the pointed questions from the YouTube video better.
Great work, Twan and Dagfinn!
As with all "structured" scrum meetings, the daily standup is timeboxed. The meeting is always at the same time each day and it should have a fixed maximum length in the range 5-15 minutes, but no more. If the meeting exceeds it maximum time, it should be finished immediately regardless of if some team members have reported on the question.
We gather around our scrum wall, where we easily can look at all the user stories and tasks that we're doing this sprint, as well as the sprint burndown chart (which shows our progress so far in this sprint).
Other team members can ask for short clarifications on the answers to the questions, but it is generally not the meeting were you do fully-fledged discussions.
The team has to see the benefit of this meeting, it must not feel as surveillance from project management. This is the team's meeting and they need to find the most effective form for it. I believe this is the most important meeting in scrum as it makes the team understand that they have a collective responsibility for the progress of the entire team, not just within their area of speciality.
It is very important that all team members stand. If not, it is much more difficult to keep it short and efficient. This actually applies to all scrum meetings and in my projects we usually gather around the whiteboards for these (toptip:deck the walls with whiteboards).
In larger projects with multiple teams, you use a similar mechanism between team which called the scrum of scrums. For more information on this see http://www.scrumalliance.org/articles/46-advice-on-conducting-the-scrum-of-scrums-meeting
Cheers
Dagfinn
Thank you for the excellent response; I appreciate it. SCRUM kind of goes with the Rugby SAP Mentor shirts, as don't they have scrums in Rugby?
On a side comment, I saw on Twan's other YouTube video at http://www.youtube.com/watch?v=tyniPLtfpt4 that you got to see Duran Duran in Frankfurt. I am soooo jealous! Who listens to Notorious, Wild Boys, Girls on Film, everyday on their iPod - Me!!
Thank you again,
Tammy
- imho, a key part of scrum is the mechanisms for building ownership and high-performing teams (compared to individuals tech ace's)
- this is of course something you can also do with strong proj mgmt,but very few projects actually do it as other KPIs are more imp.
- keypoint I want to make is that going agile will require changes, and this can be scary for developers and other proj memb
He said that with the old methodology he would be given a work package estimated to have a duration of, say, four weeks. He would spend the first two weeks "thinking" about the problem; then he would start to actually code. Of course, he had to work late hours and weekends to make up for the first two weeks of "thinking" time and he probably did not do as much testing as he would have liked by the time the four weeks was up.
So, I asked him, which method do you like better? He said he preferred the new method. The work got done on time and with high quality. He could take more pride in what he did. As an added bonus, he was able to contribute fully during a normal five day week.
I think there are two issues at the bottom of his original comment.
- During the sprint we were focused on the tasks taken from the backlog. We occasionally planned a spike as a task when there was a technical uncertainty, but we never planned for personal development time when someone was feeling uncomfortable with taking a task that was completely new for them.
- Once we finished a sprint, we moved immediately onto the next one. The level of activity remained fairly constant across all sprints and did not provide any allowance for personal development or just plain old downtime. We were getting better quality work in less time than before, but we did not give back any freedom to the team to recharge their intellectual batteries.
A lazy programmer isn't necessarily low-skilled, just unmotivated. I'd rather have the "lazy" guy and try to motivate him than the other guy who doesn't admit his lack of ability.
I'd love to do Scrum in the way it is evangelicised, but if it's not done right, Scrum makes things worse; I speak from experience.
It certainly doesn't work well with large projects involving many different disciplines.
The meeting attendance can then be 7-10 people, so the daily time spent is longer. You really don't have any interest in any of the othe work except 1 or 2 topics, let's be honest.
A poor Scrum master will let trivial matters turn into design discussions. They will let "grandstanders" take the spotlight while cutting off those with important points to raise. Worse still, they don't do anything to correct the failings of the team members who are obviously generating drag.
When that continues day after day, Scrum is not meeting it's objectives so you are not motivated to take part.