Skip to Content
Author's profile photo Former Member

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


Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member
      I agree that scrum can be very good for all in a project. I am currently working for an Agile client and the overall feeling is that it is very customer focused and can deliver solutions in a quicker more organised process.

      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?

      Author's profile photo Dagfinn Parnas
      Dagfinn Parnas
      Thanks for the comment Mark.

      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


      Author's profile photo Jan Penninkhof
      Jan Penninkhof
      I think laziness and desire of obscurity could be a reason, but I would be careful calling everyone that opposes Scrum as lazy.

      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 (
      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" (, 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 (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.

      Author's profile photo Former Member
      Former Member
      The one common factor in all of your points raised is the impact or influence of the "project manager" or scrum master for an AGILE project.

      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.

      Author's profile photo Dagfinn Parnas
      Dagfinn Parnas
      Thanks for the insightful comment.

      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)


      Author's profile photo Dagfinn Parnas
      Dagfinn Parnas
      @industrialist: I am not lazy - just old 😉

      ps we need better twitter integration on the blog system

      Author's profile photo Tammy Powlas
      Tammy Powlas
      In the Scrum meeting, where you ask what did you do yesterday, what are you doing today, etc., how long do most typical meetings last?  I agree with one of the comments that developers do hate meetings.

      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!

      Author's profile photo Dagfinn Parnas
      Dagfinn Parnas
      Thanks for the comment Tammy

      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


      Author's profile photo Tammy Powlas
      Tammy Powlas
      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 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,

      Author's profile photo Dagfinn Parnas
      Dagfinn Parnas
      @hkisker: Good disc, but video misses point, explains strong proj mgmt, not scrum
      Author's profile photo Dagfinn Parnas
      Dagfinn Parnas
      My replies via twitter:
      - 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
      Author's profile photo Former Member
      Former Member
      I had an engineer on a SCRUM team of mine comment one day that he was working harder than ever before with the new methodology. He was not a lazy programmer and I asked him why he thought he was working harder; after all, he no longer worked late or on weekends. What he told me was very telling.

      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.

      Author's profile photo Former Member
      Former Member
      There are lazy programmers but I think these days they are far outnumbered by inept programmers. These are the ones who fear daily scrutiny, as they couldn't do the job faster or better even if they wanted to.  When you make ABAP and Java coders a commodity this is what you get.
      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.