Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

How to Combat the Mental Model of Scrum as a Blank Check

DZone's Guide to

How to Combat the Mental Model of Scrum as a Blank Check

A Scrum Master looks at how teams can implement a Scrum Mental Model in order to get the most out of their Scrum methods.

· Agile Zone
Free Resource

Download this white paper to learn about the ways to make a Scrum Team great, brought to you in partnership with Scrum.org

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:

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 behavior 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 cognitionreasoning, and decision-makingKenneth 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 and 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 the 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 and 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 the 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 misaligned 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 detour 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 of Your Mental Model

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 safety deposit box outside your workplace. 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 to hang 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 actions 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 and 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 Model 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 Safety 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.

  1. Members of the Development Team (and Scrum Master and PO) must personally commit to achieving the goals of the Scrum Team.
  2. The development team (and Scrum Master and PO) must have the courage to do the right thing and work on tough problems.
  3. The development team (and Scrum Master and PO) must focus on the work of the Sprint and the goals of the Scrum team.
  4. The development team (and Scrum Master and PO) must agree to be open about all the work and the challenges with performing the work.
  5. The development team (and Scrum Master and PO) must respect each other to be capable, independent people.
  6. The development team (and Scrum Master and PO) must take shared accountability to self-organize to deliver a potentially releasable Increment of a “Done” product that realizes the Sprint goal at least once each Sprint.
  7. The development team must self-organize to be cross-functional and acquire all of the skills necessary to create a product Increment. 
  8. The development team must give up any titles other than Developer, regardless of their areas of specialization, salary, or salary band.
  9. Development team members must not form any cliques or sub-teams.
  10. The development team must work as a team to forecast the functionality that will be developed during the Sprint.
  11. The development team must collaborate with the Product Owner and Scrum Master to craft a Sprint goal.
  12. The development team must decide how they will build the functionality needed to realize the Sprint Goal and create 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.
  13. The 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 the Sprint Backlog within the Sprint.
  14. 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.
  15. The 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.
  16. 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.
  17. At the Sprint Review, the development team must demonstrate the work that they have “Done” and answer any questions about the Increment.
  18. 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 as appropriate.

Does this look like a blank check to you?

 #5 – Hiring Practices

Partner with your Scrum Master to explore your hiring practices. Have you perfected the art and science of hiring developers who don’t just want to be in your company and are uninspired 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 at it longingly, and 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.

Try out these experiments, let me know what you discover and until our next conversation – Keep Calm and Scrum On!

Learn more about the myths about Scrum and DevOps. Download the whitepaper now brought to you in partnership with Scrum.org.

Topics:
agile ,scrum ,scrum teams ,scrum master

Published at DZone with permission of Ravi Verma, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}