Diane Zajac (@agilesquirrel) has spent the last six years redefining the business analyst role as more than a requirements dictator. Through open and honest conversations, Diane guides her business partners toward creative solutions that solve problems and eliminate waste. She shares this same approach with her technical teams, facilitating communication, cooperation, and continuous learning to ensure success. Diane craves knowledge almost as much as chocolate and would make question-asking an Olympic sport. Her recent passion is to free those mired in the status quo even if she has to pull them out one at a time. Diane’s alter ego makes her thoughts transparent on her blog. While I am a huge proponent of stable teams, I do understand the reality of acquiring or losing team members. There will always be some amount of on-boarding and assimilation to a new team and their spoken and unspoken working agreements.

Some feel that standardizing practices would help this transition. But with a healthy, self-organizing team, I don’t think formal definitions or supporting structures are needed. Instead, we should focus on creating a shared understanding of WHY we follow certain practices.

This suggestion for standardizing agile practices has been around for years. Some managers argue that if we all did things the same way, then they could more easily shift & shuffle us around teams. I will steal my response from Google and say to them, “Don’t be evil.” I can deal with the deeper dysfunctions of these folks in another post.

Then there are managers who genuinely think it would help their employees to have continuity between teams. They aren’t advocates of shuffling, but know the reality is that people will be moved from team to team. Even good intentioned, creating standards is not the answer.

Most agile practices already have common definitions or commonly acceptable components. So creating standards would be wasteful. Why do we think we need to create new standards for our company? Are we that unique? Why don’t we just follow what’s already established?

Asking this uncovers the disconnect – our lack of awareness and acceptance of those common definitions.

Each practice was created to solve some repeating problem. So it has, at its root, a kernel of intention behind the suggested behavior. For example, let’s look at stand ups. How can we, as a team, stay connected to each other and what we are working on, as well as raise issues and ask for help, on a regular basis? Solution: Let’s take 5 minutes every day to intentionally check in as a team.

The implementation can vary from team to team but the intent is the same. So one team with several verbose members decides to use a talking bowling ball – you must hold the ball when it’s your turn to speak. Another team feels bored with going around a circle, so they throw a hacky sack randomly at the next person. Because they understand the intent, these teams experiment with rituals that work for their specific needs.

The problem at many companies is that the original intent of a practice is missing.

For example, your “stand ups” are actually status updates for your PM. They last from 10-30 minutes because your team members are spread among different projects. The time is spent reporting to the PM what you are doing. The original intent is completely lost.

Or maybe it was never there in the first place. When we teach practices, the WHY is so much more important than the WHAT. Because without the WHY, any practice can, and will be bastardized to fit the current dysfunction. And no amount of standardization will help that.

 

Share This Story, Choose Your Platform!

About the Author: Women In Agile

The Women in Agile community drives toward equality and inclusion of diverse representation, expertise, and involvement in the agile community. We value the representation of diverse ideas and perspectives within the agile community, and believe everyone is better off when more ideas are openly shared.