A coaching friend of mine came to me the other day asking for coaching advice about a team she was coaching. I’ll try to get the story right…
She was coaching a fairly new Scrum team. They were refining a story and decided to implement it in the front-end. Even though the “proper” solution was a backend one. It seems they’d done this before so there was a precedent.
The primary reason for this technical decision was speed. It would take them 5x longer to do a backend implementation and they felt the need to get this feature done quickly. They would then defer any technical debt clean-up to a future sprint.
The Product Owner weighed in on the side of the team but really didn’t have a strong opinion either way. They simply wanted the feature delivered as soon as possible.
The Scrum Master, as they were new, also sided with the team. So, the leanage was unanimous.
One of the functional managers in the organization, realizing that the team was making a mistake and implementing a hack or work-around, stepped in and tried to influence the team to make a better call, the right call, by implementing it in the backend.
The coach asked me about defending the team from the manager and how I might go about it…
My Reaction
This scenario brought to mind a very similar story in my past. So, I shared that story with the coach. Here’s a short version of it…
I was attending a backlog refinement session for one of my teams. I was the senior technical leader and agile champion within the organization. But I was also their coach. My stance in this meeting was one of a coach.
A story came up for discussion and I remember it centered on making a choice. I’ll use story points to make the point –
The team said that they could hack the story in 5-points;
Or they could implement it properly in 10-points;
Or they could implement it properly and refactor some serious technical debt around the story and do a great job for the future in 20-points.
Then they did something I found quite interesting. They asked the Product Owner which solution they wanted.
Obviously, the PO chose the 5-point approach.
Then a visiting Architect chimed in that he thought a 10-point approach was the right one. But he wasn’t on the team and his opinion, while valuable, wasn’t relevant for this team’s decision.
So, they stopped, chose the 5-point solution and wanted to move on.
This is when I stepped out of my coaching role and paused the meeting. I explained to everyone that we (the leadership team, the culture, and the agile principles) wanted the team to make solid engineering choices. That speed, while interesting, didn’t hold a candle to doing the right thing for our clients.
We wanted solid engineering choices in every story we implemented.
So, I asked everyone, given that – who thought the hack was the right answer? In other words, who felt proud of that decision? Nobody raised their hands.
Then I moved onto the 10-point vs. 20-point solutions. Again, I spoke about the need for refactoring to be a team decision. Reminding them that we wanted to always leave the codebase better than we’d found it. For every sprint. That quality was our prime directive over speed.
This was a much harder decision for the team as it was more situational and nuanced. Some wanted to refactor and pay the 20-points now. Others felt that this approach was wasteful and that 10-points was a sufficient investment.
I made it their decision, telling them that they were the “general manager” of the application and that they had to make a solid and balanced decision. One that factored in the now AND the future.
To be honest, I wanted them to invest the 20-points and I told them that. That sounded like the correct call to me. But it had to come from the Scrum team (including the Product Owner).
In the end, they selected the 20-point solution and moved on. I was incredibly proud of their decision.
Back to the current situation
After telling the coach this story, I think it helped her clarify the principles that needed to be amplified to the team –
Principles around:
Quality first
Doing it right the first time
No hacking allowed
Quality over speed
Support of the Definition of Done
Engineers doing work they’re ultimately proud of
Teams taking ownership of their decision-making
Doing the right thing for our customers
All were ideas I wanted them to embrace as a team.
Wrapping Up
One of the coach’s ‘ final reactions to me was that – the manager (and you/me) finally won in the end. That hierarchy trumped the team.
I explained that I didn’t see it that way. I wasn’t speaking from a management perspective or a position of authority within a hierarchy. I was speaking as a voice of and reminder of the agile principles.
To me, I need to emphasize to the team that they were empowered to make the right decision. Regardless of how much time it took. That quality needed to trump speed.
Anyway, that’s how I was thinking of it at the time.
What do you think of this conversation? How would you have handled it differently?
Stay agile my friends,
Bob.