Welcome to the opening post in the "ScrumAnd" series. This time about Scrum and motivation.
Before we dive into the two, let's take a look at something called ScrumBut - a set of reasons why teams cannot use Scrum as it is supposed to and take full advantage of it. It's been said that by modifying Scrum, teams hide dysfunctions and real change does not happen. For example: we do Scrum, but we do daily scrum once a week.
The reason I am mentioning above is not to talk about dysfunctions that are being hidden. Behind everything is a motivation, even behind hiding dysfunctions. And we will dive into that shortly. I am mentioning the "ScrumBut" because of the word "but". It turns out that using "but" in our language makes the communication more negative and judgmental. Switching to using "and" instead significantly changes the effect of our communication. It makes it more positive. One article with examples about it is here.
So let's rewrite the previous sentence about doing Scrum with "and":
we do Scrum and we do daily scrum once a week.
How does that sound now? Isn't it a bit more open and positive? Isn't it saying that we are doing Scrum (not a simple thing at all) and we do daily scrum once a week. Sounds more complementary than exclusively. First part deserves appreciation, the second one - a non-judgmental curiosity.
I am not aware who invented ScrumBut, but :) intentions were definitely not the most positive ones. It probably was about judging the teams not using Scrum properly. That the Scrum is not bringing the full set of advantages to business because of that.
The thing is that Scrum does not bring anything nor it does solve anything - people do! If daily scrum is used once a week - what is the motivation behind that? What makes the team do so? These questions accompanied with extreme curiosity and zero level judging should be asked in the first place.
I assume you have heard about Daniel Pink. Specifically his book DRIVE about what really motivates us. I invite you to look at Scrum's human part (roles) through Daniel's book. In my view, the three elements of Scrum exactly in this order: roles, artifacts, events represent Scrum framework's ability to help well. No framework can function without people and role clarity. No matter the artifacts and events - roles are played by humans acting unpredictably. It has always been the most complex part in Scrum - the roles! And humans playing roles are always motivated by something. Let's look at Scrum and motivation finally.
The three Scrum roles can be very well connected to the DRIVE's three elements of human motivation:
Product Owner - Purpose
Scrum Master - Mastery
Development Team (Developers) - Autonomy
Let's look at this when every Scrum role plays a significant part in Scrum Team's overall motivation.
Product Owner - brings the vision and purpose to the developers. We know very well what happens when this is absent or is not happening at a good level. Don't blame developers if they are not enthusiastic and happy to contribute if purpose is not clear to them. This is so needed act of leadership by the Product Owner - give the Purpose to the developers.
Scrum Master - it's been always cutting my eye and ear when I read/see/hear that Scrum Masters lead developers, drive development, manage projects and so on. This is so wrong. The main responsibility of a Scrum Master is to make sure the Scrum Team and its closest stakeholders understand and practice Scrum properly so that it brings the maximum benefit to the organization. Mastery of oneself and helping other roles improve their mastery is the key focus of a Scrum Master. Don't blame Scrum if a Scrum Master is expected to solve all impediments alone, act as manager's and PO's secretary and most importantly - is not given access to anyone beyond the team.
Development Team (Developers) - create the actual value in autonomous way. Leave these valuable people alone. Make sure they understand the purpose and continually improve mastery of their craft, that's all there is. Get lost by increasing their autonomy. Don't blame developers for not delivering good enough if you micro-manage them, override their decisions, enter their space without permission, interrupt them, ask to explain what a compiler does and so on. "... trust them to get the job done" /Manifesto for Agile Software development, 2001/.
It turns out that the Scrum framework has addressed the three elements of human motivation with its three roles quite nicely. Hope this connection helps you with your current and future Scrum implementations and team motivation.
And if we do Scrum and daily scrum happens once a week, what could be the motivation behind that? What do you think?
Yours,
Ivo