The battle of re-factoring, The two towers

chuzzeteAgile, Agile Coaching, Coaching teams from forming to performing, Participating-Supporting, Selling-Coaching2 Comments

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.


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.


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.


– 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.


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.


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.



2 Comments on “The battle of re-factoring, The two towers”

  1. I think there could be a perception issue here. I don’t think it’s possible to pay full debt on Legacy code. I think the issue is with the level of refactoring.

    Since there is no agreement in the team as to what level refactoring must be done then conflict will ensue. The team should agree on the minimum level of refactoring to be done.

    The other issue that we are experiencing is that the team is lacking in experience for refactoring and their past experience seems to indicate that speed, combined with inexperience, was the deciding factor for feature release. This leads to technical debt and we are seeing the effect now with problems estimating, duplicate code leading to multiple breaking point, lack of test coverage, static dependencies.

    As for the PO having a word to say in the debt repayment, I’m not sure about that one. The PO should be exposed to the amount of debt and shown the effect it will have on the development but debt repayment comes down to the feature we are building. If you want to add a feature in this big ball of mud you’ll have to refactor and it comes down to architecture PO determines the WHAT the TEAM determines the HOW.

    It would be interesting to see what an agreement on minimum level of refactoring would do to help with feature development

    1. Hi Pascal, thank you for commenting this out.
      For sure there is my perception about the issue in the post, but I think that you clearly expressed your possition about full paying technical. It make sense what you said about having the team agreed on the minimum level of refactoring to be done.
      Regarding this aspect:
      “what an agreement on minimum level of refactoring would do to help with feature development”
      I have the firm intention to investigate more about it, so then we can continue sharing impressions.

      Have a great day Pascal, and congratulations, you are the first person commenting my posts.

      See you soon.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.