The battle of re-factoring, The two towers

During the Agile Team Development Canvas 4th iteration experiment, I was looking for ideas to help the team to deal with what I’ve called:

The battle of re-factoring, The two towers

So I decided to explore different ways to answer these questions:

– What exactly the issue was?

– What was the root cause?

– What is the pattern? if any

– How much aware was the team about it?

and what I considered the most important thing,

– Did the team considered the issue as an impediment to their work?

Tricky questions, don’t you think?

Here is what I found during the experience, but first, I’ll give you some context about the team and its attributes.

Context

I worked with a Scrum team composed by seven (7) developers and its Product Owner. The team does support (operational stuff) and develop new features at the same time, and deal with both type of requirements within the sprint. The team’s mission is to provide the platform to process payments and transactions to the company’s web site affiliates.

EXTREMELY IMPORTANT:

85% of the code is considered as legacy code => bad debt.

This team seems at the beginning of the performing stage of Tuckman’s group development model, as I could verify after completing the assessment that I’ll share in my twitter account once this post get published.

Facts

– The team was having conflicts about when re-factoring or not, at different stages of the sprint. I found that happening when the team was deciding which coding strategy to take.

– There were two ways of thinking in the team room, what I’d called the two towers:

1. The tower of full debt payment, stubborn personality, always in, for code re-factoring of all pieces within and around the scope of the story discussed and negotiated during the sprint planning.
2. The tower of the just enough debt payment, strong personality always in, for code re-factoring but only those pieces of code within the scope of the story discussed and negotiated with the Product Owner at the beginning of the sprint.

– The Product Owner wasn’t involved on this technical discussions, the team didn’t considered his presence required, given that they though they were just talking about code.

– The Scrum Master was absent when conflicts arisen.

At this point of the sprint, It was really difficult to make things happen, because I didn’t want to interrupt the team when they were working together. But I was sure that something was happening, I saw it on their faces, they weren’t happy as usual, the mood in the room wasn’t the same, I felt it and them too that something was wrong.

So here some tools that, in my own experience, had helped me with answering the questions that I mentioned above:

1)What exactly the issue was?

Observe how the team is behaving, listen carefully to what they are saying, look for signs and change on habits. Spend time with the team without saying anything. Take notes about what you observe and in what circumstances, then match your notes and look for patterns on actions and behaviors.

2)What was the root cause?

One on One meetings, If not sure about what’s going on, but your gut feeling says the contrary, trust your instincts and ask team members to spend 10 or 15 minutes with you to help you validate your perception. Share openly what you think is happening, in order to get concrete examples. Use the 5 why’s to get to the root cause of the situation, if confirmed. Do the same, with discretion with at least 60% of the team.

3)What is the pattern? if any.

Mind mapping, and process identification to help the team design the steps that lead them to the issue, once that you’d gathered everything related to the situation. In this particular case, what is still happening and is in the way to be resolved is this:

Life cycle of a User Story, within the team

-A user story is estimated in conjunction with the Product Owner during the sprint planning.

– Part of the effort estimated by the team, relies on the fact that the team will deal with some legacy code, that should be re-factored to make the new code testable, but the team doesn’t know up-front how much this changes could impact their original estimation.

– Code strategy isn’t discussed enough when planning the user story, so the effort related is not visible for the whole team. Product Owner is not aware.

– Once in the sprint, when the team face code, then the two towers start discussing about both approaches, to re-factor only was is related to the user story to make it testable, then identify the technical debt and make it visible in the Product Backlog to further discussion with the Product Owner or re-factor everything that I find on the way, when developing the user story, which implies paying today the bad debt.

– This discussion could take up to 45 minutes, and the Product Owners is not involved. At some point, the people ask the two towers to stop fighting about it, and then the two towers start the fight for the people’s votes.

– Once there, tired after a long discussion without a winner, the people, willing to move on, accept to vote for one of the towers.

– Results, one of the tower’s position has won, the other one gets frustrated, but the whole team has lost.

4) How much aware was the team about it?

The team is aware that this is insane, and they don’t know how to avoid the problem.

5) Did the team considered the issue as an impediment to their work?

Not at this point, but given that the issue was time consuming, and it was getting on the way of the team to to reach the sprint goals, It became an impediment, so then I could jump in and deal with it as the owner and Shepard of the Scrum process.

Results

I did an intervention after a fight, once the team asked me to intervene and we took and hour to discuss about the situation. The only thing that I was able to do was, to start the conversation, once that we were all aware of it.

The team has proposed to discuss about it, within the next sprint retrospective, and in the mean time they are dealing with the conflicts by time boxing this kind of discussions.

Reflections

In my side as Scrum Master:

– I’m trying to be there more often.

– I’m coaching the Product Owner and the team when refining the Product Backlog, in order to get them to use spikes to mitigate risks associated with the unknown caused by the amount of legacy code untested in the system.

– Continue observing, listening and being present for them.

During this 4th Iteration of the Agile Team Development Canvas experience, I’d used these models to support everything that was shared above:

1) The Arc of the Coaching Conversation-> Powerful questioning, exploring and looking for options, What, Yes/And, What else

2) Hersey and Blanchard Situational Leadership -> S3-Supporting

 

 

 

 

 

 

 

3) Tuckman’s Group Development Model

What’s next?

As you can see, the issue is still there, but I think that we are in the way to solved.

In my next post, I’ll be exploring with a new scrum team, ways to build the relationship of trust.

See you soon.

Jesus