What is the hardest part of working with a brand-new scrum team?
It’s an interesting question and I’m going to view this through the lens of being an agile coach contracted to work with a new scrum team, as well as from the perspective of a scrum master who joins an existing scrum team for the first time.
It’s what we think we know.
In my experience, the hardest part of working with a new scrum team is to work around the existing beliefs about what scrum is. It’s what the team think they know about agile and scrum, and how they interpret the events, artefacts, and processes in scrum.
It’s true of any group of people, or a team, that you work with for the first time.
One of my primary tests when working with a new team is to ask them how they think they are doing, in the context of their purpose as a team, and how well they think they are performing with regards to the team’s goals and objectives.
If they tell me that they are awesome at it, be it scrum or agile, I know it’s going to be a train smash.
If they tell me that they don’t think they are performing well, that they are trying different things but consistently coming up against roadblocks, and that they value help and coaching to get it right, then I know it’s going to be awesome working with the team.
This matters because in the latter scenario, the team have come to recognize and acknowledge what they don’t know, and their goal is to master the basics as effectively as they can before progressing to intermediate and advanced levels of capability.
That is always a big inflection point for teams.
So, when you are working with teams, the biggest gap lies in what they think they know versus how a great scrum team operates.
They think that they need to be creating user stories.
They think that they need to use planning poker to estimate stories.
They think that they should be doing burndown charts.
They think that they should be focusing on tracking velocity.
And so forth.
Their focus is on the mechanics of scrum rather than becoming a high-performing product development team that uses scrum as a lightweight agile framework to achieve their objectives.
None of those elements are important, and they barely get a mention in the scrum guide, and so my role as an agile coach is to help the team master the basics and evolve with each iteration.
A shift to the core focus of agile and scrum.
Things like planning poker and burndown charts are examples of things that a scrum might try to help them increase transparency and track their effectiveness. It’s valuable in certain applications and worthless in others. It’s fluff. These are minor details that don’t impact the success of a team.
Instead, I work with teams to understand the core philosophy of empiricism.
Empirical Process Control.
It’s a scientific method for navigating complexity where the team decide on something small, developing a hypothesis, and then designing an experiment to validate or disprove that hypothesis, and then inspecting the work that has been done and using the data and evidence gathered to inform what they should do next.
Is our hypothesis true?
How do we know it’s true?
Based on what we have learned, what new hypothesis can we develop?
If it’s false, do we know why it’s false?
What does the evidence suggest that we do next?
Based on what we have learned, do we persist, do we pivot, do we abandon?
And so forth.
Its about creating rapid feedback loops that allow us to test whether the thing that we are building is of value to the people we are building it for.
That’s where a sprint review comes into play.
We take the thing that we built in the sprint, we give it to customers and stakeholders to play with, we analyze how they are playing with the product or feature, and we get feedback from those people on how valuable the product or feature is.
Does it serve the purpose we intended?
Does it solve the problem effectively?
Is this a prototype that we can iterate on, or do we need to go back to the drawing board?
What elements work for customers?
What elements don’t work for customers?
What have we learned through the process of creating this product or feature?
What obstacles and impediments did we encounter in building this solution?
And so forth.
In my experience, this knowledge of empirical loops and how they inform product development seems to be missing from most scrum teams I work with.
It is the absolute foundation of agile and scrum, and yet so few teams have a deep understanding of this process, nor do they know how to leverage it to become high-performing product development teams.
So, to summarize, the hardest part of working with new scrum teams is their lack of knowledge and expertise with core, foundational elements of scrum. It’s their tendency to focus on the mechanics of scrum, the fluff, rather than mastering the elements that will help them become an effective team.
About NKD Agility
Naked Agility is an #agile consultancy that specializes in #scrumtraining, #agilecoaching and #agileconsulting to help teams evolve, integrate, and continuously improve.
We recognize the positive impact that a happy AND inspired workforce can have on customer experience, and we actively help organizations to tap into the power of creative, collaborative, and high-performing teams that is unique to #agile and #scrum environments.
If you are interested in #agiletraining, visit https://nkdagility.com/training/
If you have identified the need for #agilecoaching and #agileconsulting, visit https://nkdagility.com/agile-consulting-coaching/
We would love to work with you.
#scrum #agile #scrumteam #agileprojectmanagement #agileproductdevelopment #projectmanagement #productdevelopment #agilecoach #agileconsultant #agiletraining #scrumtraining #scrumorg
