CBSoft Salvador

Last Monday I was at CBSoft Salvador. I had the pleasure to close the Industry track for the Brazilian Symposium on Software Engineering (SBES).

It was great to be part of this great conference.

Below are the slides (in Portuguese) for the presentation I gave there:

A linha de montagem de SW - Paulo Caroli - CBSoft 2010 Salvador

Throughput over backlog

Last week I wanted to share the cool photo form the banana peel technique. When I was writing the blog post, I created the following sentence (following the Agile manifesto style):

Latency and throughput over estimation and velocity

Paul Hammant suggested a better sentence:

Throughput over backlog

I totally agree with him. There is a subtle, but important difference. In his own words: Throughput (as a higher number) is better than backlog (as a high number). In other words you want throughput to be high and backlog to be low.

latency and banana

Following the same convention from the Agile manifesto, I have came up with a new one:

Latency and throughput over estimation and velocity

Basically I want to emphasize the importance to measure and to act upon reducing latency and improving throughput for the work we do.

All Agile teams I worked with have used some sort of card wall. Cards on the wall typically represent User Stories. The cards move accordingly to the development workflow. For example, the following would be stages for a typical workflow: Next Stories -> In Dev -> In UAT -> Ready to Deploy.

I measure latency quite easily. I write dates at the back of the cards. I calculate latency by doing a simple math: date the story finished minus the date the story started. But text on the back of the cards was not very visible.

But I needed something more visible. That is when my current team came up with the following technique. It is definitely very visible!

I presented this at the Qcon Sao Paulo conference. Folks at the audience really enjoyed it. The best tweet defined it as the banana peel technique. Someone else told me that similarly to code smell, I would get a Story smell for high latency.

Now, I am looking for suggestions for making throughput visible at the wall.

Qcon Sao Paulo and @paulocaroli slides

Qcon Sao Paulo was excellent!

Congratulations to the organizers and the community. It was really amazing.

Here are the slides for my session.

A linha de montagem de SW -n paulo caroli - q con sp 2010

Once the video is out I will also provide the link here.

Dreyfus Model and Communication

It is amazing, you can talk to someone, use words that make perfect sense to both parties and still, they don’t communicate at all. I had this experience last week. The Scrum Teams I have been coaching for some time now were scheduled for a meeting with a manager. It was about certain company standards in the area of reporting. The different Scrum Teams were doing the same thing in slightly different ways, no big differences but enough to be visible. Those differences had a good reason: Different preferences how each team wanted to work. Since the teams are self organizing, there is nothing wrong with this approach and either solution makes perfect sense in their given context.

However, in that meeting the POs and SMs of the two teams were told that having different reports was not acceptable – that they could be confusing; which they weren’t because we had already moved people around – and that the company would mandate a specific tool enabling anyone to work anywhere without having to get any introduction. This might work if all the teams would do the same kind of work, however, in this setting the different teams do a different kind of work using different technologies.

I knew that that specific meeting was scheduled to address that very topic. So, on purpose I did not mention this beforehand to neither of the SMs and POs. I was curious to see how they would react and how they would argue. I wanted to see if I was doing a good job as a coach. It was a textbook show. They simply said: ‘No way! We have delivered working software on time since we started with Scrum, this is how we agreed to work in our Scrum Team and it works great for us. We had people moved around and nobody was confused. Last, there are more pressing issues than how certain reports should look like!’. Of course, the manager was not pleased. He argued that this had to be done in order to align the whole company and lay a foundation for future improvements. The Scrum Teams replied by explaining some principles and practices of Scrum. They also described how it makes sense to keep on working the same way and that they would be open for some changes when both teams would see the need for it – however, right now they do not welcome it.

This went on for the best part of the hour. Sadly at the end we were told that we would have to obey with whatever decision the management would come up with. Our reasoning was not understood – we had failed.

What had happened? Each party was perfectly able to follow and understand each word of the discussion. However, the management side did not extract the same kind of information. We had a semantics disaccord. They understood each single word but did not get the meaning of what we were trying to communicate.

I’ve come to the conclusion that this could be explained with the Dreyfus model of skill acquisition.

• Expert
• Proficient
• Competent
• Advanced Beginner
• Novice

The Scrum Teams each had about 6 months of hands-on Scrum experience and discovered first hand what it really means to walk the agile walk. They learned a lot about agile and enhanced their theoretical knowledge with hands-on practical experience. Their limited explicit Scrum knowledge became tacit and abundant. Tacit knowledge is knowledge that is difficult to transfer to another person by means of writing it down or verbalising it. It was exactly this tacit knowledge that was missing on the managers’ side to really understand what we were trying to explain. Same words, total different meaning.

The Scrum Teams have moved up the Dreyfus model and are around the competent or even proficient level, whereas the management is still novice, advanced beginner at best. We had an interfacing problem and did not communicate on the same skill level. The risk with that is that you think you understand, but don't understand without realizing it.

I am convinced that this is one of the main challenges when communicating certain topics. You cannot assume that everyone has the same tacit knowledge and thereby the same skill level then you. You need to find a way to describe matters to a novice as tangible as possible. Not an easy feat but a necessity.

Consider the Dreyfus Model whenever you head to a meeting where you have to do a lot of explaining. If you are too far apart on the Dreyfus model, the others won’t be able to understand even if they think they do!!!