Team huddle

The Softer Side of Scrum

Many of the folks reading this blog are already familiar with Agile Software Development (a.k.a. Agile). Maybe your organization already uses Agile methodology, or maybe you’re considering adopting one of its many variations into your company’s workflow.

There are myriad reasons to do so, well-documented by the Agile community, but the general consensus is that adopting Agile leads to better productivity. You get buy-in, teach the method, adopt the ceremonies and artifacts of your chosen variant, and you’ll see efficiencies throughout your production pipeline. I believe wholeheartedly in this assertion. I’ve witnessed Agile work in just this way through three different teams in three very different industries. I’m a true believer.
But there is something special underneath all that enhanced throughput and margin-expanding efficiency: the team. Agile, particularly Scrum, is all about the people. It’s no secret that happy people are productive people no matter what project management methodology you adopt. What sets Agile apart, however, is how ingrained team building and personal empowerment is within the methodology.

You can find examples of this people-first mentality in many facets of Agile, but nowhere is that warmth better represented than in its four guiding principles.


Individuals and interactions over processes and tools

Scrum’s fuzzy underbelly starts with Agile principle #1: individuals and interactions over processes and tools. Looking at a typical Scrum team’s calendar, you might see the following ceremonies:

  • Daily stand-up
  • Sprint planning
  • Sizing and estimation
  • Retrospective
  • Review
  • Demos/pre-flights

All of these ceremonies is designed to foster communication, identify opportunities to partner and problem solve, increase transparency, provide greater agency to individual team members, and celebrate the team’s accomplishments.
These aren’t meetings. They’re gatherings, huddles, celebrations, and hang-outs. The time the team spends in each other’s presence builds a culture and a vernacular all its own. No one is alone on a Scrum team. The trust and support that comes out of this structure can be incredibly gratifying for everyone involved.


Working software over comprehensive documentation

This principle sounds like it’s speaking only about deliverables, but that’s not entirely true. Teams grow closer as a result of their shared victories. That daily grind of problem-solving and heads down work doesn’t just end up in a black hole of indefinite progress. In Agile, that shared burden culminates in a tangible artifact with real value, which is intrinsically rewarding.
There’s a solid body of research that suggests that an individual who experiences small frequent successes has greater overall happiness than an individual who experiences one big infrequent success. Agile intuitively understands this psychological framework. It’s woven into the story and sprint structure, the way team members report on their progress at stand-up, the celebration baked into reviews and demos, the goal of team retrospectives, and more.


Customer collaboration over contract negotiation

My first experience implementing Scrum was as an account manager for a small marketing team consisting of other account managers, designers, and copywriters. In that instance, I wasn’t necessarily trying to solve a productivity issue. Transparency was the problem. My team suffered from work being thrown over the wall with no warning, context, or a clear sense of priorities. This all-too-common one-sided transaction severed only to erode trust and destroy morale.
Agile solves this problem in several ways, not the least of which is establishing roles: product owner, scrummaster, and team. It’s such a simple structure, but what’s buried in those titles is a clear workflow from vision to actionable work that provides a level of transparency and clarity that is often missing in other methodologies. As the scrummaster and product owner for that marketing team, I spent my time looking ahead and creating clarity. Agile provided me with a process to document and prioritize the work that reduced my team’s confusion, minimized costly context switching, and eliminated the frustration of never knowing what to expect.
Teams that work with that level of visibility gain far more agency both as a collective and as individuals. Work isn’t foisted upon the team; the team commits to it in a very intentional and shared manner. What results from that commitment is ownership, support, and a real sense of accomplishment. This approach also stops the us-versus-them mentality that plagues many organizations where the “planners” are separated from the “doers”. Are we all in this together? Hell yes we are!


Responding to change over following a plan

One of Agile’s towering strengths is its malleability. The more uncertain a project is (e.g.,  a changing scope or an undefined budget), the better Agile fits as a process methodology. That adaptability extends to the team as well.

Scrum, in particular, creates a culture of support. Individual team members might work on different projects, but they have the team to lean on when they’re blocked or just need to get away from their desks for a while. They also have the benefit of scrummasters and product owners as part of the team who spend their time clearing blockers and answering questions quickly.
There’s no jockeying for power in this structure. Everyone on the team is equal and contributing fully to the team’s success. And when change occurs because someone takes a sick day or a client has a red alert issue, it’s the team that agrees and recommits, not an individual dictating authority.


The genius of Agile is that ultimately all this touchy-feely team stuff leads to greater productivity. The progression of teams through Tuckman’s developmental stages (forming, storming, norming, and performing) is enhanced by Agile’s emphasis on team empowerment. I’d argue that Agile shortens the journey from forming to performing significantly, reducing overhead, increasing morale, and creating a more sustainable and collaborative environment.

Date posted: April 15, 2016


Arthur, this is beautiful.

Add new comment

Restricted HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>, <cpp>, <java>, <php>. The supported tag styles are: <foo>, [foo].
  • Web page addresses and email addresses turn into links automatically.
  • Lines and paragraphs break automatically.

Metal Toad is an Advanced AWS Consulting Partner. Learn more about our AWS Managed Services

Schedule a Free Consultation

Speak with our team to understand how Metal Toad can help you drive innovation, growth, and success.