Consolidation as a team leader
How I’ve embraced my role acting as a real team leader and start to drive the process.
Embrace the role
Leading a team takes full dedication. My first approach was to continue with my work as a developer and add a little extra to manage the team. I quickly understood that this had to change:
- I’d assign fewer tasks to myself so I could dedicate more time to the team;
- I’d to prioritize tasks, using something like Eisenhower Method;
- I’d set mid-term goals for the team;
I was now the best team leader on the Planet! Can you guess in which phase of the Dunning-Kruger Effect I was?
Each developer was now responsible for the full workflow of a task. When a developer submitted the task for code review, she would ask directly for feedback. The teammates responsible for the review should prioritize this request so that she had feedback as soon as possible. This way we’d prevent the developer to start another task before the first would be, at least, close to finished.
Getting the most of meetings is hard
We were taking small but steady steps towards Scrum. The easiest requirements to apply are events, but they are hard to master. This how they looked like then:
Daily meetings
Daily meetings were only a bureaucratic meeting: “I worked on task ABC; I will continue today.”
Nevertheless, these meetings were great for me; I was being informed and giving feedback on everything that was going one in a single team meeting without the need to interrupt my coding work during the day. Genius, right? Maybe I could still code after all.
Except it wasn’t a good idea.
I was transforming what should be a 15m meeting into 30m and having all the team listening to details of no interest for them.
Planning
The planning was pretty much the product manager and I explaining to the team what we should do each sprint so eventually, these could be skipped. We were only reading the product backlog after all.
Review
This is the easiest one; Prepare an environment and show what was done to the team and product manager.
Retrospectives
Retrospectives were a great excuse for the team to come together. Still, the discussion was not well oriented and was frequently diffuse and too long.
The team
One of the mid-term goals I set was that each team member should be capable of performing any product-related task. The product is very complex, and there are some abstract concepts that one must master before performing any change. Sometimes, someone asked about 1 line of code in 1 file and I would talk about 10 different files during 1h to explain the full context (we do have documentation but it only takes you so far).
Team members were improving their technical skills and maturity and I was giving them more responsibility and autonomy. These were the first seeds of a self-organized team.
Recognize what’s wrong
It was time for the second annual appraisal. One-on-one meetings are such a great tool to sense the health of the team. What beats honest feedback from the team?
After the round of meetings, I had a pretty clear idea of what was good and bad.
Good
- The team was happy working on the project;
- Wages progression were good;
- Work quality was good;
- Team interactions were very positive;
- We were dispatching code review sooner than ever before;
Bad
- Daily meetings were often too long and tedious;
- Releases velocity were still under expectations;
- Some team members mentioned the lack of a clear career plan;
Time for more interventions
More changes had to be made to keep improving the team.
We transform the daily meetings into a board-oriented meeting, read from left to right.
In our team, we use a board in which we see the progress of each task from “To do” to “Done”.
Our daily meetings discussion started looking like this: “ — This task is being tested, what’s keeping us from closing it? — I found the bug X, the developer is working on it.” Then the developer would give a short description of his work and we continued the discussion moving to the next task on the left of the board.
Takeaways
The team communication and organization improved with both the commitment to practice the Scrum events and the natural gain of maturity. Having each team member performing one task at the time had positive effects on the work pace. On the negative side, I had led the team to fell stuck on long daily meetings and I was not performing all responsibilities that managing implies.
After some reflection, I came to the conclusion that I was not the best team leader on the planet after all.
Nevertheless, the team was ready to scale.
Next
In the next post, I’ll write about how I manage when the team more than doubled its size. It was time to take one step further into having a self-organizing team.
