I have been part of many agile teams and over time I believe that teams can get into a rut and lose the Why behind the practices and rituals they go through each week.
Once a team loses their way, they should revisit Why they are working in their specific way and evaluate if they still have the same values.
Daily Standups are too long
Let’s say that a team has been doing daily standups for the past year and these meetings have become long and not effective for getting the work day started and team focused.
It’s easy to quickly rattle off 10 different solutions in your head and start thinking of ways to get the team back on track and more productive.
But wait…
Clearly we haven’t asked enough questions to understand more of the problem and why standups are not as effective as they once were.
Maybe it’s because the team has doubled in size, maybe it’s because one member of the team goes into way too much detail on their work, instead of keeping it high level.
Our first reaction to any issue is to dig down further into why the problem is happening and gather a better understanding and a larger context of where the problem resides.
If we continue down to finding the root cause and what is happening on the team then we can hold that up against Why we have standup each day.
Generally speaking, standup allows all team members to align and stay clear on the goals of the team, celebrate accomplishments, tackle blockers and determine what needs to happen next.
The Why of standup is to work as a team and collaborate with one another. Not to report status to your boss each day.
If you skip standup to “let the team be heads down” then you are missing the point of standup and you have an issue with having a sustainable work pace for your team.
Refocusing on the Why of standup can shed some light on where changes can be made to tackle the root cause of the problem you are experiencing.
Maybe the team should be split because there are multiple competing priorities, maybe reframing conversations to “what is most useful to the entire team to make progress on the highest priority” is enough to stop the excessive sharing.
Can we do retrospectives every 2 weeks?
Let’s say that the team is feeling crunched for time or that some members of the team are unable to consistently join retrospectives each week.
Where do we start?
Again, we could start with applying an inadequate solution to the problem we don’t yet understand and say “Let’s do retrospectives less, how about every 2 weeks?”.
If you go down this path, you will end up with people not remembering what they worked on the previous week and having less time to talk about it. Feels unwise to me.
Why is the team feeling crunched for time? Could be that they have too many in-flight items or there are delays or blockers on the work being done. Maybe they need to coordinate with other teams to make progress.
Starting with questions to identify what the root cause of the problem is will reveal much richer information so that you can fix the REAL issue instead of wasting time on trying bad solutions.
Why do we have retrospectives anyways? Turns out the iteration for the team is weekly and retrospectives are a good bookend to the week to evaluate how that iteration went and talk about where
processes helped or hurt and where we can adjust them. Retrospectives are one of the most important meetings as an agile team because without reflection, you can not iterate and improve as
a team. Problems will fester and the teams spirit will slowly diminish into not caring at all.
Maybe retrospectives are dominated by technical conversation that doesn’t result in process changes or improvements, if thats the case then we aren’t focusing on the process as a whole and that can be adjusted.
Understanding the Why behind retrospectives and then identifying the root cause of your problems will allow you to apply a better solution.
Can we split this story?
Now let’s say that we are in our weekly planning meeting and we come to a story and someone asks “Can we split this story? It feels like two stories.”
Why split stories?
Faster feedback. We can have QA or another team review our work and test and verify we built something to solve their problem. Best case, we get feedback from our actual customer.
Where can we have our actual customer review our work?
Most times, this is in Production.
So story splitting should be used to get faster feedback and optimistically get that feedback by delivering software to Production.
Once we understand the Why of story splitting, we can see whether splitting the story allows us to get feedback faster or just adds additional work.
XP Values
As a previous consultant for installing agile practices at companies, I will admit I am HEAVILY biased towards Extreme Programming and utilizing those practices in any team I work on.
Extreme Programming Explained: Embrace Change, 2nd Edition (The XP Series)
Extreme Programming Explained: Embrace Change, 2nd Edition (The XP Series) [Beck, Kent, Andres, Cynthia] on Amazon.com…amzn.to
Part of why I love XP is because of the values.
Communication: Talk to one another and communicate effectively.
Simplicity: Start with something simple and try to keep it simple. It’s easy to build complex software.
Feedback: Feedback to one another and in our processes.
Respect: Everyone treats each other with respect and values their input and opinions.
Courage: Team members can speak up and point out when the team or process is going off track.
I find it a fun exercise to talk about these values as a team and see which are the favorite of each team member. Everyone has a different background and perspective and I always learn something new.
These values give you the Why to build your practices around and allows your team to have deep and meaningful conversations on how best to work together to build novel software solutions.
If you feel like your team is playing whack-a-mole on trying to figure out how to work better together, it may be time to revisit your Why as a team and figure out what you value together.
Thanks for reading!