From the moment I started working on a Scrum team I knew this was a better way of working than I was used to. Scrum done right promises twice the work in half the time – that in itself does not explain why working on a Scrum team feels so right. Of course, being able to be that much more productive is appealing – but I think there is more to it than that.
One day after having read Drive: The Surprising Truth About What Motivates Us by Daniel Pink the pieces seemed to fall into place. In this book Pink talks a lot about what motivates us. He compares our motivation to that of an operating system which has evolved over time. Motivation 1.0 was survival, and worked well until society started to get more complex. Pink states an operating system based purely on the biological drive was inadequate and such Motivation 2.0 was introduced. This second drive stated that humans set out to seek reward and avoid punishments. This “carrots and sticks”-approach with “if-then” rewards to boost motivation is how things have been for a long time now. This is where Pink calls for an upgrade of the operating system – to Motivation 3.0.
With Motivation 3.0 humans still have a behavioral drive and also still seek rewards and avoids punishment. The third drive however is that humans have a drive to direct their own lives. The motivation formula (so to speak) is built on a trifecta: Mastery, autonomy and purpose.
These 3 things maps really well into Scrum and that’s a plausible explanation why working with a Scrum team feels really…motivating! My take on the mapping is done below – feel free to comment on this.
Continuous improvement through doing retrospectives and receiving feedback during review/demo is all about mastery. What impediments are in our way to achieve mastery of whatever we are creating in our Scrum team? Mastery can never be achieved and thus the improvement process can never stop.
Autonomy also maps very well to how Scrum works. Self-organizing teams is all about empowering the team members and letting them decide for themselves how to solve things, which tools to use and which team member to actually perform the task. Autonomy for the individual team member is very important in Scrum, and this is one of the top reasons why I like Scrum.
Part of the product owner responsibilities is to have a vision of what he or she wishes to build, and convey that vision to the scrum team. This is key to successfully starting and maintaining any agile software development project. By sharing this vision the purpose of the Scrum team will not be just about implementing that one specific feature or fixing that one specific bug. It will be communicated on a higher level. So it boils down to the stakeholders and ultimately the product owner to communicate the purpose of the Scrum team.
I could go into more details on the specific parts of Scrum that I like, but the point here is that having Motivation 3.0 as some kind of framework helps explaining that QWAN (quality without a name). Of course I like something that boosts my motivation! If you haven’t read Daniel Pinks book – I highly recommend it.
The quote given is one I heard Patrick Lencioni use, although it probably can be traced to others as well. He describes well why a lot of companies fail to prioritize and instead have these really long lists of “top priorities”. They are afraid that if they focus on just a few important goals others will fall by the wayside. I believe this is absolutely true – and I even can see that in my personal life sometimes. However – once you realize this (probably some consultant or someone like that tells you this), you should do something about it. This is hard to do it seems – a lot of companies struggle with prioritization.
In Scrum or Kanban prioritization is often one of the most important parts of the implementation. There are a couple of ways prioritization might be screwed up. First of all – the product owner says that everything is important. This is classic and often gives the team trouble down the line because they aren’t working on the “right stuff”. The problem is of course – what is the right stuff? That is a business decision and shouldn’t be placed on the team. It is unfair to make the team make these business decisions for the organization.
Another way prioritization might be screwed up is by having multiple product owners – which actually translates to multiple stakeholders. If this is the case the team must once again make decisions about prioritization and which stories will result in most business value. This happens when the organization fails to decide or is unwilling to make one of the individuals the single product owner in charge of prioritization. This was nicely put by Mike Cohn is a recent newsletter. Here he also states that “When a decision cannot be made it should be pushed up the organization, not down”.
How can these situations be solved? Do not try to hide the organizational dysfunction – make it visible. Let the teams explain that they really have no idea how to decide how much business value the stories in the backlog represents – and that isn’t their job either! Communication is key – the word must be spread upwards in the organization. Lack of prioritization creates huge amounts of waste and can cause team moral and motivation to plummet.
If this sounds familiar – make changes – today!
Yesterdays weather, interrupt pattern and scrumming the Scrum. Those are the 3 patterns Jeff Sutherland says he always implement in every team.
I don’t disagree. We have now implemented these patterns in my current team and we are seeing a 2-3x improvement after 3 sprints. If we had only heard of these patterns earlier! Yesterdays weather helps out in a lot of ways. First of all it’s really easy and saves time and effort in calculating how many story points the team can commit to for the next sprint. It also helps the team to not overcommit. Overcommitment is one of the worst things for morale and motivation. Not being able to finish a sprint with all stories moved to done time after time crushes team spirit. Together with the interrupt pattern which calculates for all kinds of typical interrupts during a sprint (high priority bugfix in production etc) a 4th pattern actually emerges – Teams that finish early, accelerate faster. By not overcommiting the team can start pulling stories and the morale and motivation gets a boost. Its not about velocity, its about acceleration!
The last pattern, scrumming the Scrum, is about continuous improvement. Take the most important improvement the team can do (the kaizen) and put it into the sprint backlog as a separate item. This causes the team to self-organize on removing that single most important impediment. This systematical approach to continuous improvement is very beneficial in the long run – helping the team to always find and remove impediments, which leads to the possibility of increasing the teams velocity.
I’m hoping our focus on these 3 patterns will help us achieve even higher productivity than we’re already seeing. We’re out to a good start at least!
It’s probably common for everyone not familiar with Scrum to misunderstand what it really is. I have a feeling that these misunderstandings are most common among senior management. The reasons for this could be many, but of course limited time to learn what it’s all about is of the reasons (since they obviously have more important things to do!). I personally feel senior management should understand at least the basics of Scrum if any part of the organization has implemented or is going to implement Scrum.
Just recently a CEO of a company was trying to describe to a crowd of his customers how they work in relation with their outsourced projects. He started with saying that Scrum is pretty much all about estimating, and this is done by doing planning poker. In planning poker the product owner always want to have as low an estimate as possible, while the developers want as high an estimate as possible. In the end all the individual estimations are summed, and that sum is the estimation of that task. Yes, and they work in sprints too. He also consistently called the product owner a Scrum Master. It’s unclear whether he understands the difference of those two roles or not, but probably he doesn’t.
Lets not get into details about how wrong this CEO has gotten Scrum. Instead – lets just conclude that Scrum trainers and coaches aren’t going out of work any time soon.