Type “Scrum” into Google and you’ll get a plethora of articles about Artefacts, Roles and Ceremonies and all that good stuff. You’ll also get plenty of information about “Business Value”, “Adapting to a changing environment”, “Work tracking”, “Process improvement” etc, etc, etc. All that stuff is great. The former makes users of Scrum feel like it’s a “proper” methodology/process (whatever the hell you want to call it – interesting, if slightly pedantic article about this discussion can be found here), the latter helps execs who should know better buy in to something they don’t really “get”. It’s all got some value but it’s not what this article is about. This is about how adopting Scrum can turn an unproductive, stalling, unmotivated, disjointed team into a killer software development team with a real product focus in a matter of days.

Guess what? Like most things in business and, for that matter, in life…it’s all about the PEOPLE. Put very creative, very intelligent but poorly motivated people into a room with the best tools and materials available and they won’t be able to come up with a prototype for a matchstick together. Put some “average” but well motivated people in a room with no materials and tools, point them in the right direction and they’ll improvise, pull together, accept their environmental limitations and work magic.

I interviewed a “Senior Developer” a couple of months ago who had 3 years .Net web development experience with Citibank or some such similar organisation. Her 3 years of experience had been rebranding a single web form for various co-branded credit card partners. She had a Masters in Software from somewhere or other and had basically used all of her OO design skills to manipulate the same chunk of HTML for 3 years! This isn’t going to inspire motivation in anyone…but why?

Hackman and Oldham (1976) said that the failure of the developer described above to be motivated is directly attributable to the core characteristics of the job . Hackman and Oldham (ibid.) described, in their work on motivation theory, the Job Characteristics model which saw motivation as an outcome of job design with a number of heirarchichal dependencies. They said that in order to achieve motivation at work, the design of your job must help you achieve three Critical Psychological States (Meaningfulness, Responsibility, Knowledge of Results) and in order to do that, your job must have certain core characteristics (Skill Variety, Task Identity, Task Significance, Autonomy, Feedback from Job). It looked a bit like this:

Without too much of a leap in faith, we can map the attributes of the Scrum process to Hackman and Oldham’s (1976) core characteristics. What I’ve presented below is just a starting point, there’s plenty “missing”:

I’m sure you’ll agree, the fit is pretty straight forward.

Scrum works, QED.

References

Hackman, J. R. & Oldham, G. R. (1976). Motivation through the design of work: Test of a theory. Organizational Behavior and Human Performance, 16, 250-279.