Smarter ideas worth writing about.

Prioritizing People Over Process

Most people want to have the freedom to shape their day-to-day existence and have a positive impact on their world and workplaces.  Scrum offers an opportunity to do so, but it also takes work to accomplish these goals.  A centerpiece of the Scrum framework and one of the most fundamental aspects to creating a high performing team, and inspiring organizational and personal change, is the concept of team self-organization.   

Why Self-Organize?

The Team has been brought together because they represent all the skills necessary to deliver working software.  No one is more qualified to determine what it takes to accomplish this than they are.  The team must be allowed to commit to Sprint tasks, delegate the work amongst the team, and adjust their process as needed from within.   Some team members may not like the idea of working within a Scrum Team, which prioritizes a collective approach to work that not everyone may want to attempt.  They may feel as though they just “work better by themselves.”  The self-organizing team will be able to identify these instances and work together to bring about an agreeable work environment or deal with this situation as is organizationally appropriate.  

If self-organization is not allowed to happen, the team cannot be expected to take ownership for their work and process.  This represents a failure for an Agile Transformation.  Top-down influence in a command and control environment will stifle this process completely, block the team from developing the internal trust necessary for success and as a result, miss the benefits of the Scrum framework altogether.  If Management’s goal is to empower the team to travel the path to Agility they should co-locate the team, give them the autonomy to self-organize and move out of the way to allow the teams to develop naturally.  

Do not allow the Scrum Master to become a task master.  

While having great intentions, the Scrum Master may also become a roadblock to team self-organization if too much reliance is placed on her expertise.  The Team will look to the Scrum Master as an expert in the process, but can easily begin to rely on her as the new person in charge.  As a Scrum Master, steer your Team away from this behavior back to self-organization through coaching ownership and facilitating learning opportunities when available.  

It is not uncommon to encounter a team that has been practicing Scrum for years, but falters when a strong Product Owner, Manager or Scrum Master leaves.  The cause of this situation can usually be identified with one question.  Has the team been taught Scrum values and been empowered to self-organize, or have they been managed and driven by a strong leader?  Self-organization must be coached and reinforced to position the team to not look to leaders, but to look within for their direction.            

One of the most effective principles of the Agile Manifesto that we can use to support the transition to self organization is to “value individuals and interactions over processes and tools.” (Manifesto for Agile Software Development, 2001)  How does this apply to a Scrum team and how do we leverage it within our own teams?  I’d like to share a few thoughts.

Stop looking for a leader and rely on each other.  

In society, being a citizen is based on the idea that the destiny of a citizen is directly linked to the destiny of the community.  We are taught to know right from wrong, help people in need, protect the rights of each other and work to make our communities safe.  If we look at the concept of citizenship within a Scrum team, we are taught to accept ownership of our actions and decisions and to work together to do what is best for each other and for the product.  We agree to Product Vision, select Sprint Goals and Tasks, and create Retrospective Action Items together for the good of the team.  If a team member identifies an opportunity for improvement or a roadblock to success, they can and should bring it up for discussion with teammates for a collective solution.   Sprint work is not owned by one person, but is available to be picked up by anyone who is available to complete that work in order to meet the team’s sprint goals.  The Scrum team ideally becomes a community of teammates working towards a common goal while looking after the well being of each other.    

Tobias Mayer has written a fantastic article on his blog “Business Craftsmanship” entitled “Citizenship over Leadership,” in which he discusses citizenship and relates it to the dynamics of organizations and teams.  He states that  “The expectations of the worker in the corporation should be the same as the expectations for a citizen: that she will be responsible for the well-being of self and others, that she will take an interest in community and politics, and that she will raise her voice at injustice. This is leadership.” We need to feel ownership of our work and support the well-being of our team.  Trust your collective experience and judgment, value the opinions of each other and use this collective approach to make decisions as a team.       

Build confidence in the team and the individual.  

Collaborate and communicate with each other.  Work to solve problems and request assistance as a team when the need presents itself.  Know that you have everything you need to make the right decisions at your disposal and that your experience and skill has led you to where you are today.  Make sure everyone has the chance to have a voice and look for opportunities to demonstrate that everyone on the team has something to contribute.  Try allowing a different teammate to facilitate the daily scrum or team retrospectives.  As a Scrum Master, be sure to encourage everyone to share their ideas with the team.  If they come to you directly and the idea or discussion should be shared, pull others into the conversation.  This will help to foster the community mentality that we touched on earlier.  Creating an environment where we all feel comfortable to communicate can help to open up team mates that may not be as comfortable sharing their ideas, so work to build a mutual trust in the team.  The inspiration, insight and ideas that can be gleaned from the quietest person in the room can blow your mind, so above all help everyone learn to LISTEN.    

The tools do not make the team.  

Racing fans will say that when it comes to winning trophies, it’s the driver, not the car.  The same principle can hold true when discussing the tools of organizational change that come with an Agile Transformation.  The sales pitch for a high end iteration management system may look great, but is it the right solution for the team at the time?  Does it make more sense to start simply by using real cards and talking to each other about what we worked on yesterday, today and our roadblocks?  Using a simple, tactile board that shows the team only what it needs to see to get work done helps the team to get comfortable with communication, absorb the basic concepts of Scrum, and goes a long way to demonstrating the value of conversation over process.    

If planning poker is typically the accepted practice for estimation sessions, is it a good option for your team?  The game can be great, but it may not be right for every team.  If you see distracted or bored faces during planning sessions, try taking poker cards out of the mix for the next few meetings.  Draw your estimation scale on a white board, choose a different teammate per session to read each card, and let the team discuss and offer suggestions on where the card should be placed on the estimation scale board.  This solves two issues.  First, it takes away the cards as a barrier to conversation.  Instead of just holding up a card to be counted, we create an opportunity for each person to offer their take on an estimate.  Second, we create a visual record of our team’s estimation scale every two weeks and develop a group understanding of the team’s estimation methods.

One of my favorite features of Scrum is its simplicity.  Start from the simplest tools and add more complexity only when there is value to be gained from it.  We have to be able to talk to and trust each other first, share ideas and viewpoints freely and often, and provide constructive, truthful feedback in a supportive environment in order to be at our most effective.    

Above all else, don’t forget to have fun.  

Foster the type of environment that you want to work in.  A few effective ways to accomplish this are:

  • Play learning games like Spaghetti, Anchors or Delegation Poker to show what changes are possible when working with Scrum (check out these great games and more at It will give the team a bit of break time and allow them to take a step back and look at how they are working, not just at the development task at hand.  

  • Stop using projectors and slide deck presentations to train your team on Scrum methods. Facilitate informal open conversations about what you are trying to accomplish and allow everyone to weigh in.  Everyone gets a turn to speak.  

  • Pass around an item during meetings that signals when it is a team member’s turn to talk - I’ve seen people use everything from a rubber duck to a boomerang.  

  • Let your team come up with creative names and logos for different releases during planning meetings (a favorite is choosing a color and an animal, such as “Plum Puffin.”) It builds a feeling of ownership and becomes a fun story to share with others.  
  • Set up a weekly Lunch and Learn to let team members teach/share with their team something new they have learned in the last sprint.  

Constantly reinforce the idea of “individuals and interactions over processes and tools” and use it as a guiding mantra while you travel the Scrum path.  Every one of you has the ability to shape your work experience and make a difference in the way your team works and the products you deliver.  Always continue to inspect, adapt and improve on what you do, and don’t be afraid to learn from and with others.   You and your team will reap the benefits.   Every day is an opportunity to positively influence your team culture, evolve your role and have a voice in what you do.  In simpler terms, “Be excellent to each other, and party on dudes.”  (Bill and Ted’s Excellent Adventure, 1989)  



About The Author

Agile Coach
Paul is an Agile coach in the Columbus office. His focus is to educate and guide teams to contextualize and apply the Scrum, Kanban and XP frameworks in a way that can be embraced by the entire organization.