Team Initiatives — Stop Starting and Start Finishing
Let me know if this sounds familiar: your teammate comes up with an idea to do something great with our infrastructure, a suggestion to improve some bad process, or just a question that is worth discussing with the team, however, it stops there — in the “idea” or “suggestion” phase. How about another scenario where the team actually agrees to change something in their process, but, a few weeks later, everyone forgets about it as it wasn’t fully adopted. A week later another teammate suggests a different thing, and this cycle repeats itself.
From my experience, team behavior and processes are pretty hard to change, and too often than not, we end up sticking with old habits.
It used to happen to me all the time until we decided to facilitate a process in my group to manage the different ideas and suggestions. Instead of just talking and forgetting soon after, we wanted to make sure to implement and incorporate these ideas:
First, we created a dedicated time when team members are encouraged to present new ideas or suggestions — 1 hour every other week.
We wanted to make it visible for all and since we use Jira in our day-to-day tasks and projects, we thought why not use it here?
We incorporated some Kanban principles of visualization, flow, and priority.
For a new idea to be ready, one needs to “buy-in” the team — why is this important? And why now? In Simon Sinek’s book “Start with Why”, he explains the importance of being able to articulate the reason behind an idea. The team should understand it and make sure to come prepared and “buy-in” the team. An idea that isn’t fully baked won’t fly. It’s a great experience to “buy-in” the entire team, and not only the manager or one friend. One has to do some thorough homework to increase their understanding of the problem and the suggested solution.
- Changing our on-call process to make it more explicit and documented.
- Improving our Pull Request process to include motivation and background.
- Creating a standard for the way we use and write python3 code.
- An idea to improve our infrastructure to become “more scalable” — this idea actually wasn’t pushed forward as it wasn’t actionable or well explained so it didn’t fly on the first attempt and allowed the person who suggested it to improve the message and the “why”.
As an advocate of “tribal leadership”, I always prefer people working in groups rather than by themselves. It shares knowledge, more perspectives, more ideas, and tightens the bond between the teams in the group. So once an idea is approved (the team agreed that this is an idea worth pursuing), an action group is formed by 2–3 people who will start the groundwork to improve the idea or begin implementing it.
Jira is an excellent tool for tracking the progress of tasks in our projects, so why not track the progress of ideas and suggestions? The relevant people are tagged with the action items or simply a call to work on the topic offline and share their insights in the next session.
In my opinion, this is the core of “stop starting and start finishing”. Sometimes, when we agree on a certain new process or introduce a new tool and decide to use it, it doesn’t mean that the process was fully adopted and that the team actually incorporated it in their day-to-day. This could be because they forgot, maybe some definition is still missing, or any other reason. Without having a dedicated checkpoint, we might just leave it as is and eventually forget that great idea, and all the discussions and the invested effort was for nothing. We want to make sure that the idea or the suggestion was really incorporated in our day to day and became a standard. So in every meeting, we start from the checkpoint column, and we go through the items and decide whether we are ready to move it to “Done” or if something else is missing. The Jira comments make it easy to follow up from where we last stopped.
Our goal is to improve and the team’s great ideas can help us grow, but if we won’t truly adopt them, then we will not really grow and improve. Some ideas are easy and fast to adopt, others sometimes take months. Both cases are fine as some ideas are simple and easy to implement (don’t leave undeployed commits in master) while others take longer to fully adapt (create and adopt a new standard of how to write python3 code).
Only ideas that become part of our standard or are fully implemented, move to this column. The team has to agree that this is indeed done before moving the item from the “checkpoint” phase. It always amazes me to see this column grow bigger and bigger as it really means that we actually finished an idea that we started.
I’m always excited when my team members come up with new ideas. It means that they care about the team and the way we do things. I want to make sure that they are being heard and that their ideas come to life. This is how we become better.
How do you make sure to “Stop starting and start finishing?”
Do you agree with this method? have some of your own?
Feel free to share it in the comments!
And if you enjoyed this post, help me spread the word by:
- 🌐 Sharing it with your team
- 👁 Following me on Medium
- 👏 Oh! And don’t forget those claps 🤓 👏👏👏