Having a chapter member in your own squad means you will be sharing scrum ceremonies, backlog and sprint. Let's go through all the activities you will be doing together in the same squad, and how all these would be handled differently with other chapter members.
1. You will groom stories together
Since you are part of the squad, you will have the bias to always stay a bit more informed about this part of the project that your squad owns.
This can hinder your colleague from formulating his/her own opinions in grooming, if every time you have some feedback to correct upon content. The colleague will eventually feel like the individual has 'no point in being active in grooming, CL always knows better'. I have seen similar things happening when architects or other representatives of "the wise one" are highly active during grooming.
Rather than correcting content, think about asking questions on approach. Ask questions like a mentor. I.e. rather than "That service is not expected to work in testing environment like this, it depends on Apple Push Notification service" ask something like "Do we need to think about development setup, anything special we need for this one in dev mode?".
For chapter members working in other squads, the grooming apparatus is mature enough to provide room for growth, in your absence. Squad members collaborate in removing the unknown, figuring out complexity, and having a critical view during the retrospective.
2. You will estimate together
Unless you're ready to take that piece of work in sprint yourself, I wouldn't participate too actively in estimations. I tend to limit myself to expressing arguments why something is more complex, but I wouldn't have the final say and ask for it to be downgraded in complexity points.
I believe in the principle "Whoever will work on it, them and only them should have the final say on estimates", similar to Roosevelt's "Man in the arena" principle. A Chapter Lead is not doing a significant amount of delivery in the squad; he or she is not the one fighting directly in the arena, but training and coaching the fighters. It's Ok to provide arguments why complexity is different, while it is not fair to overwrite estimations.
Many people reporting to you will have the tendency to please and favour your choice, rather than their own judgement. It is your job to build the required trust with your chapter fellows, so they can easily speak up when their CL is wrong.
3. You will share the same backlog
This is the easiest one: the Product Owner has the ultimate responsibility for prioritisation, while development engineers provide all the necessary feedback for sound decision making in shaping the backlog. I don't see any conflicts or side effects for having chapter members in your own squad. I assume you and your team are fully aligned in what you need to do, and the rest is just fighting for sprint quota. Planning shouldn't be any different. Stories are picked up in sprint based on priority and capacity.
4. You will participate in the same sprint retrospective
A sane retrospective should address the way of working inside the squad: in between squad members, or in between squad members and peers outside the squad. While for internal processes a chapter lead is just a squad member and should act as such, for managing relationships outside the squad, a Chapter Lead has more visibility upon the other squads and the organisation and can provide extra help.
When defining action items to improve collaboration, don't offer yourself to manage interactions with people outside the squad. Yes, it would be faster and easier, but it would prevent your chapter members from growing their skills in interacting with different stakeholders.
A good retrospective will address processes and behaviours related to the squad, and a Chapter Lead should be able to figure out which feedback should be provided during the retrospective, and which one should be kept for 1:1s.
When a Chapter Lead works in a squad with member(s) of their chapter, one actually acts as a passive Team Lead: it's much easier to observe behaviours and review the work of your team at first hand, rather than getting your info at second-hand, like you need to do with the rest of your chapter which is performing in other squads. When the chapter members perform in different teams, this places the "Chapter Lead" role closer to a "manager of managers" rather than a "manager of contributors", because you can't observe their work directly. I know, you can indeed still see and review their code and documentation contributions, but the code itself is just a small part of being an engineer. You want them to act on your behalf, in their own squad.
The squad chapter member may benefit from first class coaching from your side, but the performance review process can take a hit, depending on your biases and how much quality data you get from other squads. Watch out for:
- favouring the member(s) in your squad. You might be inclined to only see all the positive performance of your chapter inside your squad, and be more obtuse on what the rest are doing in the other squads
- penalising the member(s) in your squad. You might be too harsh on the chapter that performs in the same squad, just because you know all the details and you were there when all the difficult development unfolded. You might tend to think everything is hunky-dory in the other squads and only get to know the good stuff that's going on in there.
The antidote is simple and goes without saying it is key for any manager: get as much first hand info as you can from all the peers that interact with your chapter, for an objective review process. Use all the different sources that help you to paint an objective picture of your chapter.
Now, when asked "Should a Chapter Lead have chapter members in his/her squad?", that's complicated to answer and deserves a study on its own. Yes, a CL can have one or more partnering chapter members in their squad. I have even witnessed squads that were made up of an entire chapter. It facilitates individual growth and team cohesion, but it comes the drawback of organisational-scope limitation, which is the opposite of the desired outcome of a chapter-squad-tribe setup in the first place.
How do you cope, as a lead, having direct reports in your delivery squad? Is it easy to swap hats in between squad-colleague and manager?
What interesting situations have you run into?
Top comments (0)