Where does the need to micro-manage and control come from? In a system there may be many causes for that pattern. In this episode Leonardo shares a story with us, where the system was stuck in this command-and-control anti-pattern. We discuss the reasons for that, as well as how that may look like in some companies.
About Leonardo Bittencourt
Currently Leonardo is a Scrum Master at Equifax Ireland. Focused on building high performance teams through Agile and/or Lean adoption, he is an enthusiastic about Lean and Agile mindset in the Software Development industry as the transformation agent to create great working environment as well as products that matters.
The system around us (policies, rules, culture, etc.) influences the teams we work with. But how can we detect those influences so as to be able to react to them? Ryan suggests we start by looking at the team setup and shares examples how a simple change in team setup (from module/component to cross-functional teams), can lead to major changes. Team setup is one of the first system conditions we should analyse and act on!
About Ryan McCann
Ryan is a former waiter, car detailer, line worker, cemetery worker, intern, financial analyst, tech support rep, team lead, QA manager, Scrum Master and Product Owner. Current husband, father, school board member, community volunteer and agile coach. He believes in building trust and social capital, which is not easy for any of us (himself included)…Ryan does his best everyday to help teams make this happen.
The role of the Product Owner is critical for the success of a Scrum team. However, that’s also one of the roles that is the most affected by company policies and culture. Product Owners are not usually shielded from management, and in fact sometimes they are management. In this episode we talk about a Product Owner that was also the CEO of the company. What can we do when the Product Owner is so hard to reach? Listen to what Natalie has learned about engaging absent Product Owners.
About Natalie Cervantes
Natalie is a Certified Scrum Master and Agile Coach with over 12 years experience working with both veteran and new agile teams. Her experience spans everything from mobile and embedded systems to enterprise scale website projects with a client base that includes Microsoft, Amazon, Coca-Cola and many others.
Tanner’s military background has taught him that team members need to help cover for each other. And they can’t do that by seating on their own silos and working only on one type of tasks. Tanner explains how he got trained in multiple skills in his military career and how that can help us as Scrum Masters.
www.SpikesAndStories.com. He’s helped many organizations in their journey toward agility. He’s been accused that his military training would mold him into a rigid, unmoving Scrum Master, but nothing could be further from the truth. What civilians call agile, the Corps calls leading Marines, and it’s through his experiences as a Marine that he derives most of his insight as a Scrum Master.
If something worked in the past, it must work with new teams in the future. Or must it? In this episode we explore how the system around the team significantly affect what works in practice. The same daily meeting format may have worked in some teams before, but how is this new team’s context affecting the format of the daily meeting? As Scrum Masters we must be aware of the team culture, the management culture, the technical tools and other critical system conditions. Only then can we know what might work, and what will not work in that team’s context.
About Miguel Santos
Miguel is a Brazilian living in Germany and currently Scrum Master for two teams at NewStore. He believes that there is no single methodology (agile or not) to lead projects and teams to success. Because of that, he would like Scrum Masters to be less biased when working with their teams.
When looking at the systemic causes for problems we see in the team, we need to take into account many aspects: trust, metrics, conversations, relationships. Where to start? Richard suggests that we look at the Comparative Agile diagnostic and the Agile Fluency model and diagnostic. But of course, those are just starting points. A lot of the work needed to identify systemic problems is to listen to the conversations happening in the team, and with stakeholders. In this episode, Richard describes the process he uses to observe and analyze the conversations happening in the team, so that he can pinpoint systemic problems.
About Richard Kasperowski
Richard is a speaker, trainer, coach, and author focused on high-performance teams. Richard is the author of The Core Protocols: A Guide to Greatness. He leads clients in building great teams that get great results using the Core Protocols, Agile, and Open Space Technology. Richard created and teaches the class Agile Software Development at Harvard University. Learn more and subscribe to Richard’s newsletter at www.kasperowski.com.