True story - happened in one of my recent Professional Scrum Master workshops. I think had just mentioned that there is no "Sprint Commitment" in Scrum, only a "Sprint Forecast". The eyes of one of my students lit up with glee. Uh-Oh, I thought. This is going to be interesting. I knew the look - it was the look my students get when they feel - "Now I got you, sucker!". And I was right! He pounced on me and said...
"So what you are telling me is that Scrum is a blank check for Developers!
And if you are using Scrum, you should lower your standards!"
Wasn't the first time I heard that sentiment, and certainly not the last. If I had a penny for every time I heard someone say something similar, I would be a millionaire. And so, many months later, here we are - me doing some Public Service by sharing how you can stop them pesky developers from emptying your bank account...
MENTAL MODELS
But first, let's take a scenic detour through the land of mental models...
I recently learned about the term "Mental Models" when I listened to a mind-blowing audio book called The Fifth Discipline by Peter Senge, a Senior Lecturer in Leadership and Sustainability at the MIT Sloan School of Management. Here's how Wikipedia describes Mental Models...
A mental model is an explanation of someone's thought process about how something works in the real world. It is a representation of the surrounding world, the relationships between its various parts and a person's intuitive perception about his or her own acts and their consequences. Mental models can help shape behaviour and set an approach to solving problems (similar to a personal algorithm) and doing tasks.
A mental model is a kind of internal symbol or representation of external reality, hypothesized to play a major role in cognition, reasoning and decision-making. Kenneth Craik suggested in 1943 that the mind constructs "small-scale models" of reality that it uses to anticipate events.
AGILE MENTAL MODEL
As I read the Agile Manifesto & Agile Principles, it feels like the authors may have a different mental model about Developers and all members of Agile Organizations. Here's my interpretation of their mental model...
Developers have a fundamental need to satisfy the customer through early and continuous delivery of valuable software. They like to collaborate and welcome changing requirements as a powerful force that can be harnessed to give the customer a competitive advantage. Given a supportive and trusting environment, Developers self-organize to come up with the best architectures, requirements, and designs that can help them frequently deliver excellent and valuable software. And finally, Developers regularly reflect & tune their behavior to become more effective.
SCRUM MENTAL MODEL
As I read the section on the Scrum Values in the Scrum Guide, my interpretation is that the creators of Scrum may have had a similar mental model about Developers...
Developers have a high sense of personal commitment to achieving the goals of the Scrum Team. They have courage to do the right thing and work on tough problems. Developers want to focus on the work of the Sprint and the goals of the Scrum Team. They are open and transparent open about their work and the challenges with performing the work. And most importantly, they are capable, respectable, independent people who self-organize to deliver a "done", potentially shippable increment that realizes the Sprint Goal at least once every sprint.
BLANK CHECK MENTAL MODEL
In contrast, those who are concerned that Scrum may become a blank check for the Development Team may have a different mental model about Developers...
Developers are fundamentally untrustworthy and their goals are mis-aligned with the company. That they will exploit every chance they get to slack-off, play pokemon and start food-fights. If we don't keep the Development Team on a really short leash using fixed-date, fixed-price, fixed-cost contracts, the inmates will start running the asylum and there will be a swift, rapid, painful and irreversible descent into the bowels of hell.
This mental model may be more compatible with the Sabotagile Manifesto and Sabotagile Principles. If you haven't read either of them, please take another scenic de-tour and read this blog - Agile or Sabotagile: Help Your Management Understand The Difference.
PROTECTING YOUR BANK ACCOUNT FROM THEM PESKY DEVELOPERS
OK, so now let's get back to the original reason you are probably reading this blog. You fear that Scrum is a blank check for them pesky developers, and you want to figure out how we can stop them from emptying your bank account. Let me share 7 ways...
#1 - 90 DAY SUSPENSION WITH FULL SALARY & BENEFITS
The first option is very high risk and dangerous. Can you suspend your Blank Check Mental Model for 90 days with full salary and benefits? If it helps, write it down on a piece of paper and store it in a safe deposit box outside your work-place. Your Blank Check Mental Model will likely rebel and make all kinds of threats when you try to do this. Please be kind and compassionate to it and assure it that you will come to meet it in 90 days.
If you are unable to suspend your Blank Check Mental Model, and try hanging on to it while using Scrum, it may act like a Saboteur and create self-fulfilling prophecies. You may not realize the extent to which it is influencing your thoughts and action and creating unintended consequences that confirm your belief systems. You must choose one - Blank Check Mental Model or Scrum. You cannot have both.
If this thought is too scary for you to try out for 90 days, go back to using Waterfall and stop reading this blog.
#2 - 90 DAY RENTAL & INSTALLATION
Now that you have created a vacuum in your mind where your Blank Check Mental used to reside, rent and install the Scrum Mental only for 90 Days. This may be challenging. It certainly was for me, many years ago, as I made the very reluctant transition from Waterfall to Agile. If you need some help in doing this, read-on...
#3 - SCRUM MASTER
Explore whether you have a Professional Scrum Master. Getting a Scrum Master certification is easy. Becoming a Professional Scrum Master is not. Either enable your existing Scrum Master to progress on the path of a Professional Scrum Master or hire an inspiring and Professional Scrum Master. A Professional Scrum Master will help you try out the Scrum Mental Model for 90 Days and support you every time your Blank Check Mental Model escapes from the off-site Safe Deposit Box and tries to sneak back into your mind.
#4 - SCRUM GUIDE
Sit down with your Professional Scrum Master and revisit the Scrum Guide to explore if it really gives the Development Team a blank check. As I scanned the guide, I found 18 distinct accountabilities that they Scrum Guide seems to assign to the Development Team. Many of them are accountabilities shared with the Product Owner and Scrum Master.
- Members of the Development Team (& Scrum Master & PO) must personally commit to achieving the goals of the Scrum Team.
- Development Team (& Scrum Master & PO) must have courage to do the right thing and work on tough problems.
- Development Team (& Scrum Master & PO) must focus on the work of the Sprint and the goals of the Scrum Team.
- Development Team (& Scrum Master & PO) must agree to be open about all the work and the challenges with performing the work.
- Development Team (& Scrum Master & PO) must respect each other to be capable, independent people.
- Development Team (& Scrum Master & PO) must take shared accountability to self-organize to deliver a potentially releasable Increment of “Done” product that realizes the Sprint Goal at least once each Sprint.
- Development Team must self-organize to be cross-functional and acquire with all of the skills as a team necessary to create a product Increment. Sprint.
- Development Team must give up any titles other than Developer, regardless of their areas of specialization, salary or salary band.
- Development Team members must not form any cliques or sub-teams.
- Development Team must work as a team to forecast the functionality that will be developed during the Sprint.
- Development Team must collaborate with the Product Owner & Scrum Master to craft a Sprint Goal.
- Development Team must decide how they will build the functionality needed to realize the Sprint Goal into a “Done” product Increment during the Sprint and must explain to the Product Owner and Scrum Master how they will work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.
- Development Team must implement functionality and technology In order to satisfy the Sprint Goal. If the work turns out to be different than expected, they must collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.
- Each day, the Development Team should understand how they intend to work together as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment by the end of the Sprint. If needed, they must meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the Sprint’s work.
- Development Team must modify the Sprint Backlog throughout the Sprint, and ensure that at any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed-up, tracked, managed and used to project the likelihood of achieving the Sprint Goal.
- By the end of a Sprint, the Development Team must create a new, "Done" Increment of Product Functionality that realizes the Sprint Goal, that is additive to all prior Increments, that is thoroughly tested, that works with all previous Increments, and is in useable condition so a Product Owner may choose to immediately release it.
- At Sprint Review, the Development Team must demonstrate the work that they have “Done” and answer any questions about the Increment;
- At the Sprint Retrospective, the Development Team must collaborate with the Product Owner and Scrum Master to identify improvements they will make in the next Sprint so it is more effective and enjoyable. They must identify ways in which they can adapt the definition of “Done” and increase product quality by as appropriate.
Does this look like a blank check to you...?
#5 - HIRING PRACTICES
If you genuinely believe that Developers in other companies and the rest of the world are awesome, it's just that the Developers in your company are losers, partner with your Scrum Master to explore your hiring practices. Have you perfected the art and science of hiring Developers who just don't want to be in your company and are un-inspired with your company mission? Could you run some experiments to adapt your hiring practices to attract some of those awesome Developers in other companies your heart is yearning for?
#6 - CULTURE
If you believe that you hired awesome Developers, but something happened and they became un-inspired after they joined your company, partner with your Professional Scrum Master to figure out what strange alchemy your company culture is performing on these Developers? Could your Professional Scrum Master help you run some experiments to improve company culture such that it enables and unleashes the natural God-given ingenuity every human is blessed with?
#7 - BLACK MAGIC
Last, but not the least, try some black magic. Purchase a mirror, gaze into it longingly can utter this magic spell three times...
"Mirror Mirror on the wall, who is the most responsible of them all...?"
And now imagine the mirror replies...
"You are, my dear!"
At this point, resist the urge to break the mirror and try that scary thing called Personal Responsibility. In his book The Fifth Discipline, Peter Senge explains how it is human nature to switch to blame mode whenever something undesirable happens in life. We blame someone else or we blame ourselves whenever our current reality is not as beautiful as our desired reality.
Peter Senge invites us to consider the possibility that the events unfolding in our lives may be a by-product of our own actions displaced in space and time. Because the consequences are displaced in space and time, it may not be obvious to associate the consequence from the action we took to cause it.
Responsibility is different from blame. It can be scary and liberating.
Scary because when our current reality is ugly, it means we have to face the possibility that whatever is manifesting in our life is a by-product of our own thoughts and actions. Liberating because now we have the power to change our own thoughts and actions and create a more beautiful current reality.
WHAT NEXT
Try out these experiments, let me know what you discover and until our next conversation - Keep Calm and Scrum On!