Great Scrum Team Members: Born or Developed?
By: Grant Gadomski
Tags: Scrum Master, Agile Scrum Methodology, Agile, Scrum, Scrum Agile

In software architecture, there exists the idea of the golden hammer. Basically it’s a term for any hip new architecture movement (microservices, SOA, RESTful architectures, etc.) that overzealous architects attempt to apply to any situation, regardless of whether it actually solves the problem gracefully. In today’s software process world, Scrum is in grave danger of being that golden hammer. Companies big and small see Scrum successfully used at Google and Facebook, and blindly apply it to their IT organizations, hoping for immediate and dramatic increases in revenue and productivity. As you may expect oh savants of Scrum, these bolted-on efforts often don’t return the gains desired. One reason is that Scrum requires a certain type of team member. Self-directing, motivated, creative, a true team player, willing to experiment, and driven to deliver business value by any means necessary. Scrum succeeds through individuals who shudder at the words “because that’s how we’ve always done it”, and are relentless in their pursuit to make things better. The question I propose is: Does a company have to replace its workforce with Scrum-minded individuals, or can people morph into not only following Scrum’s practices, but internalizing and embodying its fundamental principals?

Why is Scrum Scary?

There’s no way around it, true Scrum demands a fair amount from the team.

When first introducing Scrum to a group of lifelong waterfall practitioners, one would expect some confusion (you expect us to deliver in how long???), and hopefully a little curiosity. Another emotion you see is fear.

If you’re someone who’s just in it for the paycheck, waterfall can feel safe during development. The team’s true progress is hidden for months at a time, meaning that numbers can be easily fudged in status reports (of course it all comes back to bite you when the due date comes and functionality’s missing, but that’s a problem for another day). Requirements are “fully” defined before architecture and development begins, meaning no ambiguity when writing code, and you can fill in the gaps with assumptions since the business is too busy to answer questions. And besides one (probably somber) post-mortem per project, there’s no impetus towards continuous improvement and self-reflection. Then Scrum comes along with it’s all new ideas and demands.

Suddenly your team needs to deliver something every 2–4 weeks, removing that safe little 6 month bubble of development time. 400 page requirements documents have been converted to “User Stories”, that are left technically-sparse and require you to communicate with the product owner to work out the implementation (you may find yourself muttering “What am I, a Business Analyst?”). And this newfangled “Scrum Master” (who does she think she is with a name like that, some great wizard of the north?) keeps asking the team to think of ways to improve and “grow” as a team. After a couple of sprints with work carrying over and stories consistently being blocked, it’s obvious that the team can’t meet the demands of Scrum, and you’re wondering which crackpot devised this whole scheme.

There’s no way around it, true Scrum demands a fair amount from the team. Not in the traditional definition of effort (long nights and weekends spent in the office), but instead by asking the team to challenge themselves, picture a high-functioning team in their environment, and find creative ways to strive towards achieve those once-thought-impossible goals. For a team to go from mediocre to great, they will always have to go through a fair bit of effort and struggle. If that wasn’t required, then every organization would be operating at Google-level. Scrum simply provides the tools and sandbox for growing and developing as a team. The team itself must build off of these tools to become better at delivering business value.

Scrum is also very effective at uncovering layers of solidified team and organizational debt, to reveal all unspoken issues and unidentified shortcomings. If a team wants to improve, not only will they need to put some thought into their practices, but they also must be willing to face their impediments, failures, and problems. The team must approach this process knowing that they’ve done the best they can given their tools and situation, and through this muck-raking they can grow towards delivering more business value, and facilitate a happier work environment for all. There will be difficult conversations, awkward silences, and the feeling of failure at times. A team should not be ashamed of their failures, instead considering them as experiments that didn’t produce the desired outcomes, and learning situations to adapt and pivot off of. This is very different from the old-school corporate mindset where failure is severely punished, and existing problems are best kept in the dark and hidden from management. The team must do the terrifying work of facing their own demons, displaying their true progress to management, and holding the tough meetings that everyone dreads. If they can follow through on this, a whole list of impediments and action items will be created that, when acted upon, will deliver a wealth of value for the team and their value-delivering capabilities.

Eliminating Fear

One of the most tried and true differentiators for top performers in any field is their ability to face and learn from failure

By considering failure in a different light, and adapting the implemented Scrum practices to always remain slightly outside of the team’s comfort zone, the fear and trepidation may drastically reduce. We’re so used to failure being this awful, confidence-shrinking, self-worth deflating concept. But one of the most tried and true differentiators for top performers in any field is their ability to face and learn from failure. Management and the Scrum Master can slowly change the team’s perception by reducing the cost of failure, and framing it in the light of experimentation and learning.

The statement above may be a tough pill for management to swallow. In the business world, failure means millions of dollars lost. But unfortunately failure is and may forever be the ugly step-sister of innovation. If an organization wants to be first to market, stay ahead of its competitors, and drive the future of its industry, said organization must be wiling to write off a few failures. One may find that the cost of failures hasn’t increased with the new Scrum framework (it‘s probably even decreased), but the frequency of them has. By “failing fast” and keeping the impact limited, the organization may be able to better save itself from death-march projects and drawn out financial disasters.

What About Lack of Motivation?

The vast majority of developers entered the field with a love of programming and interest in creating high-quality software

What about the folks who just don’t feel like working, God bless ‘em? There will always be some members of our field who, from the first time they opened an IDE (Integrated Development Environment, where code’s written) were only in it for the money and job security. Luckily these people are rare in this demanding field. In my college major’s first core class you could usually tell which students would graduate with a Software Engineering degree, and which students would switch majors after two semesters. The ones with a love of learning and genuine passion for software would survive the long nights, tough projects, and high expectations. The ones who signed up for the average salary or because their parents didn’t want them to move back in would be looking at other options after a few classes. The same story holds true in the professional world. The vast majority of developers still writing code today entered the field with a love of programming and interest in creating high-quality software.

If most developers entered this field with bright eyes and curious ears, why does it seem like so many of them just do it for the paycheck? The experience of playing around with code can feel drastically different from doing it for a living. In an old-school corporate/waterfall environment, programmers may feel unrelenting pressure to deliver without fail, while under the constant threat of the managerial “stick” (to use the old carrots and sticks analogy). Sometimes punishments are handed down to developers for failures that were out of their control (unreasonable schedules, dependency incompatibilities, artificial restrictions). This breeds a culture of both fear, and eventually withdrawal. Creating software goes from a creative endeavor that challenges the individual, flexing both their “right” and “left” brains and facilitating the flow state, to one of resentment for management, disgust at the field, and a general feeling of helplessness. After years of this developers stop entering projects with a creative mind and thirst for learning, and instead think and act like drones, collecting paychecks and counting down the days before retirement.

Scrum is fundamentally incompatible with this mindset.

So Can People Become Great Scrum Team Members?

I say yes they can. If implemented correctly with the full faith of management behind it, Scrum can drastically change how developers feel about their jobs, due to the following factors.

Daniel Pink’s Model of Motivation: Throw Out Your Carrots & Break Your Sticks

In Daniel Pink’s 2009 book Drive: The Surprising Truth About What Motivates Us, he debunks the 20th century model of motivation, and instead proposes a new one for our modern times.

The Carrot & Stick motivational model has been around since the dawn of work, and on the surface it makes sense. People want rewards and don’t want to be punished, so they’ll work harder to achieve rewards (the carrot), and avoid punishment (the stick). According to Mr. Pink this model worked up through the 20th century, when most jobs were manual & repetitive. Producing more in these jobs was just a matter of trying harder and working longer.

In the 21st century, we’ve seen the rapid decrease of manual & repetitive jobs at the hands of technology & improved automation. As a result, our jobs have become more creative, and our tasks more novel. And if Don’t Hug Me I’m Scared has taught us anything, it’s that you can’t just “be more creative”. In our modern work environment, the carrot and stick model often creates more pressure and less outside-the-box thinking.

Instead Mr. Pink suggests focusing on three intrinsic forms of motivation: Autonomy, Mastery, and Purpose. Scrum promotes autonomy by allowing the team to select the tasks they’re committing to each sprint. Once the commitment is made and agreed upon by both the team and product owner, the team is left to their own devices to deliver on their promises. Frequent communication with the product owner is necessary, but should be prevented from falling into micromanagement territory. Scrum promotes mastery through high-level user stories. The team is allowed to come up with their own (legal) solution to delivering each story, making development feel less like completing requirements checklists and more like a craft to hone and master. Finally, by delivering concrete functionality every sprint and working closely with the product owner, the team can see the product come together before their very eyes, and understand the impact that it’ll have on their end users and the organization, promoting a sense of purpose.

Power to the People: The Development Team Now Sits at the Planning Table

As mentioned above, Scrum provides a much greater level of autonomy for the team, compared to common waterfall. As opposed to schedules being set by management behind closed doors, the development team plays an active role in what will be expected when. The sprint planning meeting requires the product owner and development team to attend, and although the product owner prioritizes the backlog, the development team has the final say on which stories they’ll commit to and what their sprint goal will be. Instead of feeling helpless in the face of management’s impossible timelines and iron-clad requirements, the developers now get to provide genuine input and help shape the schedule and vision of the product. Instead of being relegated to their cubicles, the development team now sits at the planning table alongside management.

Conclusion

So should an organization making the leap to Scrum fire all its developers and start only hiring 20-somethings in flip flops? Although I have some fresh-out-of-college friends who would like this, it’s probably not necessary. Some people may not make the leap to the Agile/Scrum mindset, but the vast majority of developers will see the increased autonomy, improved sense of mastery, and greater feeling of purpose as a welcome change, so long as Scrum is implemented fully with an eye toward everyone involved.