Reflections on Clean Code: Team's Performance

XP-agra for flaccid Scrum teams (Doctor's Choice)

Keep reading if you find yourself or your team in one of the following situations:

1. You no longer have confidence in your estimates (time, effort, risks)
2. You have 'owners' for certain software components
3. Your regression test takes more than half a day
4. A very high rate of bugs (defects) are discovered in production by your users
5. In order to find the piece of code to change or the place to add a few new lines you need to spend hours digging the code base
6. Sometimes you touch Component A and the change affects Components B to Z, and you discover that on late test cycles or live in production
7. With every iteration you feel that the time to perform minor changes is growing exponentially
8. Everybody fears the release date, and stay alert the next week or two expecting the next bomb coming from production
9. Your team is doing Scrum (or so you believe)

If any of the described situations is happening to you be advised: your team is suffering from the disease called "Flaccid Scrum" (FlaccidScrum). This illness causes your performance to, gradually, decrease until you reach the zero productivity (velocity) point. By that time the only possible solution is to dump the code base (put the product in the trashcan), and start over with a greenfield project.

But, fear no more, you can be cured with a simple solution: just take XP-agra the Doctor's Choice for flaccid scrum implementations. You need to start with solid engineering practices as proposed by eXtreme Programming.

The basic problem is that a flaccid scrum team is constantly neglecting the need for internal quality (not just functional quality) in the code base. A team with such a problem is compromising (1) the quality vertex from the following triangle:

Solid Scrum (with XP) mindset

Let's examine each vertex, in the context of "normal" Agile team:

• The time one is the easiest, it is fixed by one of the core concepts of agile methodologies "Time Boxing"
• The scope vertex must be flexible in order have really time boxed iterations, and
• The quality vertex must be fixed in order to maintain a sustainable velocity (performance) by the team.

Flaccid Scrum mindset 

This is the mindset, respecting each vertex, for a "flaccid" Scrum team:

• The time one remains fixed (time boxed)
• The scope vertex is fixed giving a false sense of commitment and "performance" to the Product Owner and the customer, and
• The quality vertex, by necessity, becomes flexible in order to allocate all committed scope inside the time boxed iteration.

The Jenga Tower

By compromising the internal quality the team is shooting himself in the foot because the performance will be gradually degraded. A poor quality code base is difficult to maintain, a headache for the team and for the customers. It becomes very fragile, with each change a new crack arise. With each crack a quick patch is added. After a few iterations the code base has too many patches and becomes extremely hard to touch without breaking it: this is the final stage of a Jenga Tower before collapsing. Something like this: 

"Each block removed is then balanced on top of the tower, creating a progressively taller but less stable structure." (https://en.wikipedia.org/wiki/Jenga)

Practical steps towards solving the problem

Just to be crystal clear,  XP is not a pill, we really can just "take it" and the problem will be gone. In order to solve the underlying quality problem we need to take small, but solid actions. Here I'm only listing the suggested steps but details on each one will be left for upcoming posts:

• First, we need to build awareness around the issue for all stakeholders:
• Your team (complete): developers, testers, leaders, ...
• Your product owner
• Your customers: both inside and outside the organization
• Capital investors / business owners
• Second, improve the knowledge level of the people actually doing the work, because they need to change their bad habits and may require some sort of education / coaching / etc.
• Finally, devise a plan covering short, mid, and large term actions for team to undertake. 
• One of the first steps of this plan is to measure the current situation
• Then, you need to define the KPIs that will be observed as process and quality improvement indicators
• Pick the smallest steps possible, because you don't want to completely stop the team and you need each new practice to be assimilated by the team shifting the mindset a little bit each time. 

---

(FlaccidScrum) The first time I saw the term was in a Martin Fowler's posts

FlaccidScrum (2009)

Five years of Flaccid Scrum (2014)

(1) Compromising is used in the following sense: "a change that makes something worse and that is not done for a good reason". See merriam-webster.com