Doing Scrum and Agile is hard for developers too

I’m introducing the Scrum process in the development department of a large organisation. I anticipated the problems we’re currently facing with the rest of the organisation. Specifications are vague and several months old, people we need for information and feedback are hard to find. So in short, the usual impediments. When observing development teams you’ll usually hear people complaining about these things. But the thing that is not often discussed is that developers that are new to Scrum have some things to overcome as well.

Scrum practices
There are a few things Scrum enforces that aren’t always embraced by the development team. The time that Scrum takes for meetings such as the stand-up and sprint review are considered overhead. It’s hard to motivate people to stop and think about their process or communicate about their issues when they’re thinking ‘how to get out of this meeting’. It’s also quite hard for people not to think about all the stuff that has always gone wrong but only the trouble you’ve had in the previous sprint. Complaining about problems that are out of your scope and influence is not productive, but focussing on just a few weeks takes more effort than I expected.
Take action
In Scrum decisions are made quickly while actively seeking feedback on the result. This can also be a disruption in the way people are used to work. Decisions are usually made very carefully, with lots of discussion on the pros and cons. In Scrum we assume that decisions should be made quickly to keep the project going and in most cases the end result is acceptable. Stopping developers doing research on different options and creating proof of concepts feels like imposing a restriction on how they want to work. I think Scrum allows for a lot of freedom, but not the freedom to waste time dwelling on options.
Product owner decides
The hardest one for me is the decision on technical issues. The product owner decides on the priorities, even on taks that the developers come up with. The team has the responsibility to do the work in the way they seem fit, keeping up quality standards but other stuff such as ‘we should automate all testing’ is something the product owner can give lower priority to. ‘Creating a test script for feature X’ might be less ambitious and get a higher priority or can even be seen as a necessary step to complete a feature. This haggle between the product owner and the team is a new phenomenon, which could end in frustration because developers aren’t given to the time to make things ‘perfect’. Everything should be driven by business goals and sometimes that leaves no room for optimization or tweaking.
Listen to the team
So what can the scrum master do? First of all, listen to the team. Most of the time the frustration and complaints have a serious cause. Challenge the team to come up with things they do to deal with those causes. But some things in Scrum will just take getting used to, some things might never feel right for developers. I think that, when Scrum has been introduced, working together as a team and getting the satisfaction from getting things done and pleasing your stakeholders is more than enough reward to keep the team motivated.