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: lyssaadkins

I believe that Agile is a brilliant, emergent response to help us thrive in our ever-increasingly complex, changeable and interconnected world. My current focus is coaching Leadership Teams to take up the Agile transformation that is theirs to do -- on both a personal and group level. For many years I have been a passionate contributor to the discipline and profession of Agile Coaching and have trained many thousands of agilists in the knowledge, skills, and mindsets needed to coach teams and organizations to get full benefits of Agile. In 2010, I authored Coaching Agile Teams which has sold 75,000+ and been translated into 10 languages.