Making Processes Explicit in Scrum
I work in a scrum context, but I like to include elements of Kanban, lean, and systems thinking into my work.
One of the things we can do as a Scrum Master is to help teams understand when rules of the team are changing. We do this by clearly stating what we heard and making sure the entire team is agreeing to that change.
This is called "making processes explicit" and it is one of the properties of Kanban.
Here are some examples of things that I have seen teams mutually agree on:
- No code gets pushed until it has been reviewed by another team member
- Acceptance criteria should be demoable
- No code gets pushed unless it fits done(x) criteria
- Code will include corresponding unit tests
- The team should finish started work before pulling in new work
- If the conversation is losing focus, someone can declare "rabbit hole" and the conversation will be tabled until after the meeting
- Instead of asking the three questions at stand up, the team will 'walk the board'
- Stories that cannot be completed in less than 5 days should be broken down
- Scrum Master will be assigned to all JIRA tickets as a proxy for the team
I won't get into the merits of these decisions or whether there is a better agile practice that could replace them. A lot of decisions were made to bring clarity to the process for the team in their given context.
Acknowledging Our Social Contracts
We have social contracts all around us. Some are explicit (it's illegal to steal or murder), some are implicit (cover your mouth when you cough or sneeze). They exist with roommates, spouses, co-workers, family, neighborhoods, and in our place of worship. They are everywhere.
Conflicts can arise when one group or person believes there was a contract breach, but the other person wasn't aware of expectations.
Two things we can do to avoid this:
- Set clear expectations for what we know now and can define (current)
- As conflicts arise, identify the breach of contract and make the newly agreed upon contract explicit (evolving)
The simple act of acknowledging it brings clarity and accountability of expectations. As a Scrum Master it is our job to be a mirror so that the system can learn and improve. Making processes explicit is a great way to acknowledge that learning into something tangible and practical. Sprint Retrospectives are a great place to start this process, but it can happen at anytime.
What are some unspoken social contracts in your life?