My team’s journey on becoming High Performance Team
For a long time my team wasn’t arranged with some sort of management methodology.
In order to improve this problem, I took a course about Project Management with emphasis on — Agile, Scrum and Kanban, and tried to implement it in my team, this is OUR journey
The Question
When you want to make a change, and especially something big like changing the way that we work, in my perspective it shouldn’t come from above, it should come from the people themselves because by doing this you make a commitment from them
So we had a team meeting and I asked them “What do you think that keeps us away from progressing?”
And we started to talk about what we think, about cooperation between us, about different knowledge that some have, about doing the same project for a long period of time and more, from those points we chose one action item to solve, and it was Definition of Done.
What that was good about our DOD is testing, CR and DR that we now must do, and by this to “force” ourselves for team work
Visualize The Workflow
One thing that Kanban really emphasizes is the workflow - Visualize and Measure the flow
We always used some sort of Task and Workflow manager, but it felt like a burden, so we build a big physical board of TODO, In Progress and Done and where? Right in front our door, so every client or colleague could see what we do and our progress
And another board of “Help” for me, each and every team member that needs my help as a “Scrum Master” can write there, those are my tasks as a servant leader
This board has evolved also after couple of days, we added another column of CR which is limited to 4 tasks at a time
Why limit the number of tasks per columns? limiting is a powerful tool, if a column doesn’t have limit it means that it is not managed,
before we had 20 “In Progress” tasks for 8 team members which actually meant — non is in progress, and another effect is members MUST help each other in order to open the jam or you as the team leader need to intervene
Daily
Before I took the course Daily was more like task status for me, and less for the team in order to synchronize, I wrote the Daily and sent to my costumers, and tried to understand why each and every mission is stuck and what is the new Due Date etc.. the problem with this method is that Daily isn’t Daily, its Status
Now, after I understood the meaning of Daily — time in the day for the team to synchronize about tasks
we talk about the missions in front of the physical board, moving tasks and update each other about setbacks we encountered
We managed to reduce the Daily from 30 min meeting that we hate, to 10 min meeting that we feel that we need
Weekly
The next thing we tried was we started to do weeklies — 30–45 minutes meeting in which we plan the next week, breaking down tasks, and choosing what tasks we are focusing on in the next week — like sprint planning but for a one week
For me as the Team Leader, it was a game changer! from big and bulky missions to small and manageable missions, now we can split the entire release to different members and by this — minimize the cycle time and delivering less tasks but faster — and in the end more tasks for the same time
The first weekly was “monthly” like, we thought that we could do 25 user stories in a week, and it was way too much, and in the next weekly we didn’t add tasks, only arranged them more, and in the next one we took on ourselves only the relevant user stories, and after that we added new user stories but took way less, we took the exact amount for a week
Measurement
How will you know that you are making a progress? measurement is the only way to know that,
After you and your team can split your tasks, you can choose duration between what dates you are measuring, you can now start checking your progress, and after finishing one “sprint” of measurement, choose with your team what you should do now in order to keep improving, does your Definition of Done need some changes? do you want to limit the WIP? take 1–2 action items, and now try to measure your throughput of tasks, and see how it affects your team.
Retrospective
We try to do Retrospective after couple of deployments and think about what was good and what was bad and how to get better,
Retrospective is a very powerful meeting, because it can be very good and productive, or useless
We write all the points we talked about and try to make them happen until the next Retro meeting.
One of my responsibility as a team leader team is to find the weak spots, to figure out how to become better
In order to sum up, it is very easy to say “Agile is nice but…” if you really want to have a better team, and more productive team, just ask them the next question each couple of weeks “ What do you think that keeps us away from progressing?”
Like this post?
Support me via Patreon
Subscribe to my YouTube Channel
Top comments (3)
I love that you learn about different agile methodologies and then applied what made sense to your particular circumstances. Your process is now your own, and it will evolve along with your team. Well done!
Thank you!
Nice article, thanks! Building a team and deciding about different routines and tasks division is hard and worth thinking it through many times. When one of my first teams started using kanban board, they weren't happy and satisfied from this solution until I asked them the question you mention - what is the thing in this tool that doesn't work for you well. And yes, their answer made me come back to kanbantool.com/kanban-guide/kanban... and even the most basic stuff about kanban boards but it was totally worth it. We changed some every-day aspects and we use kanbans till now. Happily ;)