There is an interesting post called Agile: Does Technical Debt Exist?. It’s already one and half years old but I’ve just noticed it. It claims that there is no such thing as technical debt in an agile development environments. Even though it does contain some good arguments and actually points at some common mistakes made when defining technical debt, it comes to the wrong conclusion.

First, there is always a trade off between short term features and time to market versus long term goals. This is still a sort of technical debt even though it is a conscious business decision to focus on short term customer satisfaction and not address long term goals. Technical debt is not only about the trade off between bad code and reaching a release date. It’s very often a conscious decision, very often not only a technical decision but a business decision.
Similarly, taking a loan to buy a house when your kids can still enjoy living in a house has nothing to do with poor financial judgement. It just means you accept the fact that you’ll have to repay the loan with interest in the future but it is more important to you to live in a nice house while the kids are still kids. From a purely financial point of view, you’re of course better off just saving money for 20 years and then buy a house without loan. It’s the cheapest option. But maybe you do not need a house in 20 years from now… So although the term debt often has a negative aftertaste, it doesn’t have to be bad.

Bad code on the other hand, code which will ‘bite you in the ass’, is something completely different. It is not technical debt though. If it will bite you in the ass in the future but not now, then you are simply balancing future velocity against current velocity as long as velocity is measuring something relevant (end user features).

I think this quote shows that the author as a certain idea of what technical debt is and assumes that technical debt is just the result of stupid decision involving not doing something now without getting any advantage now. It is really the case. I think technical debt is created in most cases based on a conscious decision because the short term effect is more valuable than the long term cost. Of course there are cases where technical debt is created because of a lack of knowledge or understanding of your own tools and products. But I really think it’s not the 80% case.

No debt is incurred, just choices made.

Well, in most cases debt is incurred because of conscious decisions, choices. Making choices doesn’t mean, no debt is incurred.

Technical debt is a dangerous notion because it achieves nothing apart from making everyone pissed off with everyone else.

I guess it does happen very often that the notion of technical debt creates a circle of finger pointing. But I do not think that the technical debt metaphor is always the cause for this. I think it’s mostly related to the culture in the organization. With measurements of the technical debt, you make things apparent which would otherwise only come to the surface when you have to implement a feature affected by the debt and it takes more time than expected. If there is a finger pointing culture in the organization, it will happen latest at this point in time. Whether the technical debt metaphor is used or not…

Technical debt can be a mean to argue for meaningful clean up activities which do not bring immediately visible results but represent a mid to long term huge benefit. But like all weapons it can be used in a wrong way. You need to be careful how you use it and make sure it is not used as a trigger to discuss how bad developers are. The author is right when he says that these shortcuts taken in development projects are very often not only decided by the developers themselves but are often decisions made by the whole organization based on the benefits to the end user / customer.

I’ve just read an interesting article called Why Scrum can not scale and Scrum of Scrums can not work. It’s been written by a former colleague of mine.

Basically, the thesis of the article is that (Roman: if you read this, please feel free to correct me):
1) for Scrum to work you need a team, empathy and a common goal.
2) Scrums of Scrums fail to create this team dynamic.

Though I feel Scrum can scale further than the 7 team members Jeff Sutherland recommends, I do also feel that Scrums of Scrums are actually defeating the very nature of Scrums and I feel is responsible for the success of a project using Scrum.

Let’s consider a few important Scrum values (it’s the way I understand Scrum, so feel free to comment on it).

Commitment

What actually makes commitment very important is that it’s a team commitment. Not each team members individually committing on a part of the job but a commitment of the team with each team member:

1. Commits to do his best so that the team can reach the goal.
2. Believes that the team will reach the goal.
3. Believes other team members will also do their best to reach the goal.

The first aspect of the commitment scales better than the two others. But this commitment only has value if you are not forced to give your best but readily do it. It’s a matter of motivation. It’s also a matter of identification with the task, the project and the people involved. This last one is actually the issue. Yes, we are expected to do our best in whatever project we’re working on, that’s what we’re getting paid for after all. But let’s be honest, I will probably rather go the extra mile when working with people I know and trust and when working on something which scope is not so huge that I can’t fully see it or grasp it. So individuals will give their commitment to do their best in both smaller projects and larger distributed projects but I do feel it’s not the same quality of commitment.

The second aspect of the commitment does not scale so good. I can assume that team or teams will reach the goal. I can even think that knowing that we have good people in all teams it should be possible. But this neither involves faith in people you personally know and trust nor an objective analysis of the situation which requires knowing the people in the team well enough to be able to estimate how much we can really achieve together.

The second aspect is a question of trust. And except if you have actually worked will all the persons in the other Scrum teams, I think achieving this level of trust over team boundaries is very difficult.

Open communication

Openness in the communication is a prerequisite for an efficient communication and reduces unnecessary overhead and waste. For this, you also need a certain level of trust. I firmly believe this level of trust doesn’t scale that well. I do trust people I know well, people I work with on a daily basis. I can also kind of trust other people but we will never reach the same level of openness.

That’s from my point of view the main issue with Scrums of scrum. The persons involved in a Scrum of Scrums are only representative of the different Scrum teams. So it’s some kind of indirect communication which makes the communication less effective and I believe affects the openness of the communication.

Focus

Focus on reaching a goal together is a major success factor in any endeavour. And having all team member focusing in the exact same direction is what makes a real team different from a group of people just working on the same project or product. The more you scale, the more you will notice that the different teams involved so have a common goal but focus on it a little differently.

Courage

Making a commitment requires courage. It’s easier to just say “let’s see what we achieve”. Showing courage also requires trust in the people sharing the commitment. Showing courage somehow also leaves a weak spot open. I do believe it’s easier to show courage in a small scale team than to show courage in a multi-team environment.

Respect

Mutual respect of all team members is required for achieving the kind of goal a team accepts in Scrum. Since open communication is encouraged and required by Scrum, this also requires a great deal of mutual respect. I just do not think this level of mutual respect can be achieved in a Scrum of Scrums environment.

Conclusion

I also still have to see a Scrum of Scrums work. I can imagine it could work if the members of the different Scrum teams already know each other from previous projects. But I strongly believe a lot of what makes Scrum successful gets lost in such a larger scale project.

Well, it’s not a statement from my side but rather a quote from one of our project manager, let’s call him Al. As a convinced agile and lean follower and as someone who has spend years working in a highly efficient Scrum team, I’ve needed almost two days to digest this and be able to start writing this post.

Usually, you associate Scrum with Agile, Agile with light-weight. You also associate overkill with bloated, bloated with heavy-weight. So the statement just makes no sense and we can just forget it, right ? Well, I do think the statement makes no sense but finding out where this statement comes from might teach us something useful. In general, even when someone makes a statement which obviously makes no sense, it’s often useful to go past that and understand why this statement was made.

First, I doubt Al has much experience in a real Scrum environment. Unfortunately, like many organizations around the globe, the one I’m currently working for does practice something which is called Scrum but actually has nothing to do with Scrum because:

1. Scrum is just used because of the hype
2. Noone has any experience with Scrum, not even the Scrum master
3. The team has no real power
4. The team doesn’t commit
5. The scrum master is making decisions instead of the team
6. Transparency is kept at a minimum level
7. No demo at the end of the sprint
8. Things are half done by the end of the sprint: the result of the sprint is by far not shippable

So in this environment, Scrum basically means more overhead:

1. More meetings: planning, daily scrum, review, retrospective…
2. More work managing an ever changing backlog
3. More re-planning because estimations are wrong, a lot of fire fighting happens next to the sprint, scope and priority change
4. More chaos because tasks are not broken down to fit in a sprint, so tasks start in one sprint and end sometimes 3 or 4 sprints later

Of course, all these perceived Scrum overhead are just problems arising because Scrum is simply not implemented and lived properly. As Mike Cohn (the founder of Mountain Goat Software) wrote 7 years ago in an article called “Scrum Shouldn’t Be a Burden”:

If Scrum feels too heavy or as if it has too much overhead, it likely is being done incorrectly.

So what the statement above means is basically:

1. I do not really know what Scrum is
2. What we call Scrum here doesn’t work
3. Doing Scrum the wrong way actually makes you even slower than with a non-agile process

Well, I guess all these statements are true (wish Al had actually realised that’s what he should have said).

So does it mean Scrum makes no sense in such an organization ? It might be the case. But before coming to this conclusion, this organization needs to first understand what scrum is, how it works and especially why it works. Without understanding why it works, you just end up borrowing roles, ceremonies and artifacts from Scrum but fail to implement and working and effective Scrum.

I read an article by Tobias Mayer on dzone which actually started quite promising. But after reading it, I was kind of disappointed. I usually enjoy Tobias’ articles but there a few things disturbing me in this one.

The point of the article is basically that many people put the blame for their failures on time-boxing although the real issues are other factors in their time-boxed environment. I fully agree with this. What I actually didn’t like at first was that Tobias basically presents things like: “Do you like your cool, funny, generous and nice uncle X or your lame, boring, stingy and rude uncle Y better ?”. I really think that presenting an extreme picture like this actually hurts the argument.

Of course on second thought, after reading this article, I did start thinking and eventually decided to write a post about it. So even though the article describes the greatest and the ugliest although in most organizations a much lesser level of good or ugly can be found, it did trigger a thought process. So maybe Tobias did reach his goal with the article after all.

So now the thought process has been started, let me share what I think about this time box and commitment topic and how they are related to failure.

First, what’s time boxing ? It just means you divide your project in many smaller fixed-length periods of time. Each of these periods are a full cycle and produce deliverables. It’s important that the length of a period is fixed and will not be changed if you see you cannot deliver what you had planned.

One advantage of time boxing is that you get at the end of each period of time a picture of where you stand. You know what you got until now. You can see whether you are still on track. If something goes horribly wrong, you’ll know latest at the end of the current period. And of course a big advantage is also that big things aren’t easy to manage and smaller ones are easier. So extrapolating, it’s easier to manage many small cycles than a large one.

OK, so it sounds great, where’s the problem ? Well now comes the commitment part… Usually, the customer, its representative, management are all interesting in knowing what they will get for the money. So they want the team to tell them before they start the period. And of course this only makes sense to tell them something if you first think you can achieve it and second actually aim at achieving it. So the team commits something before the start or at the start of the time boxed period of time.

Now what happens if because of unforeseen circumstances you see half way that you will probably not make it ? Well, you have different possibilities:

1. You communicate that and say sorry we won’t make it.
2. You do what you can and just present it in the end.
3. You work even harder until late in the night, on weekends to achieve the goal.

Number 1 is fine depending on how the customers and management reacts. If this means the period is extended or aborted than… well… its then not time boxed, is it ?

Number 2 is also fine although combining it with number 1 is probably best. Since we work in a time boxed project, we basically fix time and costs and accept the fact that the scope in the end might not be what we initially expected. Of course, you’ll see the disappointed faces of customers and management. But since you really love seeing these guys happy, next time you’ll probably commit less. Or you’re make sure you commit on things which are really clear. Overall, it will probably make the commitment better and more reliable and everybody will be happier.

Number 3 is what Tobias described so nicely. Well, if you have to work a few hours overtime and make it, it’s not so bad. But you have to also keep in mind that when you make a commitment and achieve the target, people will expect you to commit at least as much next time. Actually, since you’re also expected to get better at it over time being more and more experienced, you should actually be in a position to commit more next time. So next time, you won’t sleep at all. You will not only work on Saturdays but also on Sunday and as Tobias states, you’ll probably die. But it is kind of a worst case scenario, right ?

Sometimes the pressure to do everything in your power to achieve committed goals does not come from others (customers, managers…) but from the team itself. we all want to achieve what we’ve committed to. But to honestly say that something cannot be done as planned is the better honest way to go around with it. If you try till the end to work overtime to achieve it and succeed, nobody will see a need to improve anything since we made it. On the other hand, if you eventually fail anyway, you’ve just wasted a lot of energy but also time.

Sticking to the plan no matter what is not going to save you. But adapting the plan as soon as a delay occurs will make sure that you have a realistic and feasible plan which is more useful than having a plan looks better but is disconnected from reality.

So the message is basically:

1. Customers and management need to accept that working time boxed means you might not be able to achieve 100% of the goal but it’s OK, since you have a short cycle and soon a chance to mitigate this.
2. You have to accept that it’s OK not to achieve 100% of the goal if new issues pop up or if things are more difficult to implement than expected.
3. Customers, management and the team need to understand that working overtime to mitigate delays due to unexpected difficulties is not a good long term solution. Make sure you implement the most important features first so that even if after the planned X cycles you haven’t implemented 100% of what was planned, you’ll still have the most critical features.

So does it mean commitment is bad and you should just work time boxed without any commitment ? Well, even though you should stretch it too much with hard commitments which you want to fulfill no matter what, I feel that giving a commitment is important. I personally feel motivated when I’ve committed to something. Second, giving commitments, being wrong about them and trying to better assess what you can achieve during the next cycles, does help you better access what you can deliver in the future.

So the main issue is neither the time box or the fact that commitments are delivered but how you handle change in the project.