We are people!
Why does Scrum work? Why does such a simple framework work and sometimes fail?
In PeopleWare by By Tom DeMarco, Timothy R. Lister, the authors argue software companies are not really technology companies, they are people companies! And this is why Scrum works: Scrum is about people and Scrum fails when people fail to understand it is all about people and just think Scrum as a process to deliver software as opposed to a framework to engage and motivate people to deliver better software? Mike Cohn provides some “Twenty Tips to Help You Avoid Success” including “Start customizing an agile process before you’ve done it by the book!” (link). This is an important point here: Scrum is deceptively simple and it is very easy to be cavalierly around ceremonies, sometimes in the name of efficiency to implement stories rather than team’s effectiveness. Such ceremonies are made to engage and motivate people so that they deliver shippable products. Hence they are not directly aimed at delivering products: they really aim at engaging people! Once you customise Scrum, you take the risk to derail from the agile values and make Scrum a soulless process, without much common sense falling into mindless bureaucracy rather than quality as presented by Steve McConnell’s 10 myths of Rapid Development “Good processes are Based on Good Common Sense”:
Source: Telcordia Technologies: The Journey to High Maturity, Bill Pitterman, IEEE Software, July 2000
Scrum gives sense of purpose, Mastery and Autonomy
Dan Pink explains that 3 factors motivate people: Sense of Purpose, Mastery and Autonomy. So how Scrum (based on Agile values and principles) becomes an excellent framework to motivate people?
Sense of purpose
A short story:
An itinerant wanderer traveling over country roads in thirteenth-century France who comes across a man exhaustedly pushing a wheelbarrow full of rubble, he asks what the man is doing: “God only knows. I push these damn stones around from sunup to sundown, and in return, they pay me barely enough to keep a roof over my head”. Further down the road, the traveller meets another man, just as exhausted, pushing another filled barrow. In reply to the same question, the second man says: “I was out of work for a long time. My wife and children were starving. Now I have this. It’s killing, but I’m grateful for it all the same”. Just before nightfall, the traveller meets a third exploited stone hauler. When asked what he is doing, the fellow replies: “I’m building Chartres Cathedral.”
Some engineers have always been managed by (project) managers where “command and control” is just the way to get things done. Jean Tabaka (link) explains with humour how “command and control” lowers IQ of your team and hence lower IQ of management (and as a former colleague of mine replied “Is that possible?”): engineers are not just builders, they want to create and build hence, as a Product Owner, you need to give them a sense of purpose: something greater than just fulfilling their basic needs!
Scrum helps: get the team to contribute to creating user stories and use “lift-off” sessions to engage them (see “Liftoff: Launching Agile Teams Projects” book by Diana Larsen and Ainsley Nies). Explain the team you want to build the “cathedral of Chartres!”.
In a nutshell, Scrum helps teams create and build something great giving the team a real sense of purpose!
With Scrum, this “Hero” culture is vanishing in favour of the team capability to deliver. Through sprints, “storming, forming and norming phases” should be quick, especially around the Scrum master. Through planning poker, daily stand-ups, sprint review, retrospectives and planning, there are lots of opportunities for the team to get to understand each other.
Regarding Performing, we are not talking about efficiency, it is about effectiveness. To explain the difference, climbing a ladder very quickly to realise you have the wrong wall can show you are efficient but ineffective.
So with Scrum, you are likely to realise you have reached the wrong wall at the end of the sprint, when you demo your product. And worst case scenario, if you have a Minimum Viable Product, an MVP (see The Lean Startup) your earlier customers can try out, you will get critical feedback!
The team is going to learn to work together, to reflect on their practices through retrospectives, they are going to pick tasks of their own choosing (based on business priorities) giving them opportunities to learn skills, areas of code they don’t know etc.
There is no mastery without learning: as a Scrum master, you want to make sure the team is constantly looking for opportunities to learn and that failing is just part of the game. You may want to make sure team members don’t just pick up tasks that keep them in their comfort zone but on the contrary, they pick challenging tasks, work together (maybe using pair programming) to get their commitment done by the end of the sprint. You use demos (sprint review) so they can proudly show what they have created and built!
Not only the team is going to help create the product and build it: they are defining what “built” means and they improve what “built” means. They define their standard of excellence: their definition of Done! RallyDev is providing some very good guidelines how to engage the team to create it, get them to commit to it (they are defining it) and put it on the wall. “Cult of Quality”, building great products, motivates teams as explained in PeopleWare!
Mastery with Scrum is mastery of the product building process and also mastery as a team to work effectively together against standards set by themselves!
A fundamental mistake I have seen is around what self-organizing means: this is “self-organizing around the Scrum framework”, not “just self-organizing”. Hence the importance of the Scrum master in getting teams self-organizing should not be minimized. Believing you don’t need a Scrum master, or need a Scrum master temporarily could be a fatal mistake: teams are humans and they need a shepherd, somebody not only there to remove impediment but also to inject energy into the team (a great video from Mike Cohn on Self-Organizing teams: link)!
Scrum empowers and gives responsibility to the team to deliver the product. Of course, “with great power comes great responsibility!” (Spiderman or Voltaire) e.g. responsibility to deliver their commitment is critical, getting a sense of their velocity, Attending 15 minutes daily stand up on time, reporting release burn down chart, number of defects etc
Of course a challenge is for management to trust the team and the team has to give confidence to management.
At the sprint planning, team is responsible to work out how they will deliver the sprint backlog. During the sprint, based on their commitment, the team has to work together to deliver the sprint backlog
There are far more tools using Scrum that helps teams engage, get a sense of purpose and remain motivated to deliver a product that delights customers: sprint goal, story mapping and learning new skills such as Test Driven Development and Acceptance Test Driven Development.
Agile set of values based on empirical facts and experience, full of common sense as well as agile principles believes in people over anything else… I recently read that “What matters is the quality of people. The rest is just an optimisation!”. Scrum is not the solution. Scrum helps make teams more effective: keep people engage, motivating and learning while, as a team, deliver products. It helps keep good people, make them great and make teams hyper-productive!
Last words: think of your people e.g. engineers and Scrum masters as “creators, not builders”!