Wednesday, October 30, 2013

Scrum - A framework to facilitate the creation and maintenance of trust.


What if we changed the definition of Scrum as follows? (I'm not actually advocating this, but wanted to get the idea out there). 


- Scrum -

A framework to facilitate the creation and maintenance of Trust.


With the abundance of articles out there about how this procedure works or this process works, how teams should evolve and how corporations should change for the future, trust is something I feel is missing as part of the discussion.

Many of us have seem Scrum (or Agile) adoptions fail and succeed. I don't know about you, but for me, the successful ones have been the ones where effort was put into creating and maintaining trust.

For the more "procedural" of you out there, let's talk about one specific example; The Sprint Retrospective

The team reflects on what happened in the previous Sprint, or maybe to think about how progress is being made toward a more long-term change such as improving team knowledge, or upgrading a system's testing capacity. They then contemplate a way to move in that direction. 

A team that embraces the idea of trust maintenance, will let others know what it plans and will communicate what it is trying to accomplish (or learn) as a team. The team is open and transparent and showing responsibility.

The retrospective is a continual improvement step that the team is taking toward making their lives (and the lives of their organization and customers) better.

You may think of this just as a procedure, but consider for a moment, the importance of the retrospective for building trust.

Many consider the trust between team members. But what about other forms.

Put yourself in the shoes of an executive who is wondering..  "Is this Scrum stuff working? How is it helping my business?.

Then, you'll realize, a team that takes the Retrospective seriously is building a considerable amount of corporate trust.  It shows that the team can, and is willing to be self-organizing, self-healing and does not need to be "pushed" or "controlled". If left to it's own devices, the team will always try to improve.

Why not try thinking like a business person who is making a transaction. You are doing self-improvement and letting the organization know you consider this important. In exchange, you are building up your currency of trust in the bank at the company. You are continually working to maintain the trust level.

After all, if you are on a Scrum team, you are likely working in or for a business. Showing you care about the business can't hurt your credibility. Can it?

The Scrum framework creates this as part of its' design.  It allows (facilitates) an environment where trust can be created and maintained.

Think about the different processes in Scrum and ask yourself...


 "If we do or do not do this part of the framework,
how will it change trust with our partners in our environment?".

You might find this helpful in learning why some parts of the framework exist.

Other frameworks have different approaches, but I think after consideration, you'll realize that all the noise can easily be filtered through by considering the element of trust when trying to decide if something is worth doing.

I regularly hear Agilists talk about "People and Interactions" as being the most important thing to them. How is it then, that these same people do not consider the implication of the creation (or destruction) of trust in their environment when deciding to make adjustments to what they do?  

Changes that are made at the team level will affect the level of trust in the rest of the organization or the teams' interaction with their "customer". 

Consider for a moment that if you embrace Scrum's approach, your team will be "closer" to the customer.  How can trust be ignored?

For me at least, If you filter all the hype and noise and just think of one thing, it makes learning an Agile Mindset (not just Scrum) easier.  

In the end.... When making decisions, what we really need to be considering is the creation and maintenance of trust.  

Perhaps this is something that could be discussed in a Retrospective :->

Just throwing it out there.

Comments always welcome.


Mike Caspar
Passionate About Agile