When it comes to big new life changes, I am as guilty as anyone in my need for premature optimization, meaning my first instinct is to not start before all is ‘perfectly’ planned… sometimes so that I never actually start.
Paralyzed, I want to change in a big WATERFALL kind of way where everything is planned out and all items implemented at once.
But then I shake myself a little, say a few choice words in the mirror, and step forward in an agile, iterative, and most importantly, reflective way.
Because the first step is the most important.
Not HOW you do it. But JUST the fact you do it.
So, the first step for transforming your business towards agile is … ?
The same goes for transforming your business, project, team, etc. to begin using ‘agile’ methodologies. It is a big company culture change! You must resist implementing all at once. When I am ranting on about how much I adore agile, I am quite often asked :
Okay, but how do I implement it? Where to start?
There is a glimmer of fear in their eye as they reach for their coffee or beer (Yes, I ramble on about agile outside of work… often.)
This question is hard to answer without meeting the team and knowing the particular intricacies of the project and the overall production needs. In addition, it is best not to prescribe too much as it really depends on the team’s unique DNA and what THEY want to do first (Yay, autoorganization!)… as top down rarely works with these kinds of changes.
The first step I often recommend and one of the easiest to implement (once the team is convinced) is putting into place: “Retrospectives” or “Retros”.
What is a Retro?
A retrospective can take many forms and often should change and adapt with the team over time (if not to add some spice). The overall idea is the team gets together to reflect upon:
Since the last retro…
- What went well?
- What could improve?
- What are some solutions?
Then two or three of the solutions are collectively chosen and teammates volunteer to follow these points until next retrospective. After all, we can not change Rome in a day! Here are some ideas for retro formats.
How often and who?
Depends on your team! Typically retrospectives are at the end of the development cycle for development Scrum teams. I suggest conducting retrospectives at least once a month for non-development teams, especially in the beginning.
Oh, that is right. I suggest retrospectives on all levels. It is not just the developers that produce, so why not spend that valuable time improving on all levels?
You have multiple product owners? Do a scrum to scrum retrospective! Do a company wide one! Marketing team one! All levels will profit from regular introspection, though the time intervals and format will vary depending on the scope.
The key is though to not turn retrospectives into ‘diss’ fests against people or teams not present. This should be watched for and any point involving those not present should be noted and taken up in the next retrospective including them or by their manager in private. If it is solely a personal conflict then it is best discussed between the two people involved.
In addition, I am a big advocate for having mixed profiles in the retrospectives including managers. BUT it is important that the managers exercise listening and letting each person, especially those naturally timid, feel free and safe to express themselves.
Much like brainstorming sessions, the participants must freely be able to communicate their ideas and thoughts. Only later when you vote on the most important solution upon which to work , should there be a HEALTHY debate on the pertinence.
Here is the kicker: You have to actually do it for it to work
Now over the years of seeing various companies/projects/teams transition to agile, one of the biggest stifling factors has been cutting off open communication or not prioritizing it. For example: just filing away retros as “another meeting”. This I have found especially true for non-sprint organized teams.
“Ahh… well I have so many meetings… so much to do. Do we REALLY have to have our retro? Didn’t we just have one? I would appreciate it if we could push it off… I have this [INSERT DEADLINE] coming up.”
Respond, “No, sorry. It is important.”
Hey, secretly, you may even want to cancel it! It takes time and energy to communicate openly and establish healthy channels to do so. But giving that loving push to yourself and others to keep to the retro routine is important.
Trust me; of all the times my teams have wanted to cancel the retrospective… Where people grumbled, “Well, what do we really have to say to each other? We talk a lot already.”… those OFTEN turn out to be the best retrospectives. People leave smiling and feeling loved because they took the time to improve themselves and their team, vent their frustrations and find solutions.
Pro tip: Bring candy. People love candy. Or ask people to volunteer taking turns cooking or purchasing food to bring. Food = love, commitment and yumminess. Plus, it gives the team a sense of ownership. They will want to be at that retro so that they did not bring food for nothing!
But why?
Well other than the free candy… In your agile transition or project life you may not always make the right decisions. The first steps may be off path, BUT if you bake in moments of reflection, you can easily fix these mis-steps and learn from them. Turn them into an investment and not a loss.
So no crazy long, overly optimized roadmap of how to transition to agile is necessary.
Just start by talking with each other.
Just take that first step and keep at it and the rest will eventually fall in line.
Want to lear more about retrospectives ? Read this article : https://weblog.wemanity.com/at-scale-retrospective/
Comments 1