When Local Optimization Won’t Make a Difference

A couple of weeks ago, I mentioned at the office during my measure and manage flow in practice talk that we should invest more in optimizing the whole flow and reduce the efforts spend on local optimizations. In retrospect, I didn’t spent too much time on explaining why, because it had a very loose connection to the subject of the talk, and I assumed that the audience would understand what I meant anyway. Well, I have to admit I was wrong. Since the talk, I’ve participated in several discussions were we just stated that local optimization is bad and I met only one guy who was able to give me an example, why was it harmful in his environment. However, I think it is not too late to make this right. Local optimization is not a bad thing, but it won’t make any difference - or will make it worse - when it is not part of the global improvement initiative.

This is is what I think about local optimization:

First of all, optimization means that an organization does certain improvements, and as a result, its lead time (the time the whole organization needs to finish the whole process) gets shorter. Second, local optimization means that a team, which is in connection with at least one other team, reduces its cycle time (the time needed to finish a certain phase in the whole process). Most probably, this improvement won’t have any affect on the lead time when the other teams have different goals.

This is a common flow in a software development process:

The blue rectangles are the phases in the process. For example, analysis (1), development (2),  testing (3), and integration (4). The width of the rectangle represents the cycle time. Team 1 is working in Phase 1, Team 2 in Phase 2 etc.

Read more »

VN:F [1.9.17_1161]
Rating: 0.0/10 (0 votes cast)

Happy Birthday!

Another great year has passed and my blog has become two years old. Happy birthday!

Dear Readers and Friends, thank you for reading my posts and listening to my talks. I really appreciate it!

I’d like to give my special thanks to my friend Zoltán Mészáros for his continuous and excellent help and my girlfriend Zsófi for her endless patient and support.

VN:F [1.9.17_1161]
Rating: 0.0/10 (0 votes cast)

ACCU 2012

The last weeks were a bit busy and I didn’t have the chance to share my slides from ACCU2012, but now I have some time, so here they are:

The whole journey and the event was really good, I learnt a lot. Thank you very much for coming and listening, you were a great audience!

PS: I’d like to give my special thanks to @vbsmeza for the coach and the good evening discussions.

VN:F [1.9.17_1161]
Rating: 10.0/10 (1 vote cast)

See the Whole Flow – An Exercise for Managers to Start a Transition

Last week, I got an interesting assignment from my boss: find a way to introduce Agile/Lean to a management group in the form of a retrospective meeting so that they can start their Agile/Lean transition by finding gaps in their organization.
When I started to prepare for this meeting I thought that this particular group should do their work according to the Lean principles and forget about Agile for a while. I could write another blog post about the reasoning – I don’t want to go into too much detail now -, but in a nutshell, I wanted them to do a real top to bottom transition and I felt that the Lean approach is more suitable for this than Agile, because Lean builds from the top and Agile raises issues from the bottom.
I also felt that we’d be able to start with a more complicated exercise right away, so I decided not to bring any well known ones and put together a Lean exercise for them. The exercise consisted of four different tasks:

  1. Do the value stream mapping of your organization
  2. Show how the information flows through the organization
  3. Find out which phase is the most valuable and which generates most of the waste
  4. Generate an improvement queue based on the findings

I have to mention that we did the original exercise a bit differently than I’m describing below. This is because I learnt a lot while doing the exercise and have since made changes to the original idea as a result. Read more »

VN:F [1.9.17_1161]
Rating: 10.0/10 (1 vote cast)

We Need Realistic Coding Dojos

I’m not sure about your experience with coding dojos, but this is what happens to me every time I attend a series of coding dojos or organize one: the event is great, we have a lot of people there, do the exercises and schedule the next session. At the next event we have less people, but the atmosphere is still great, the next session is scheduled. The third event is different: only a few people show up, and even they only show up because it was scheduled. Something has changed, it is pretty obvious. In most of the cases developers complain that the exercises aren’t real.

One half of the complainers say that the simple exercises of the dojo aren’t real the knowledge they may gain, is not beneficial for their daily work. They want to work on the production code and not on a silly “fizz buzz” game. The other half kind of understands the concept, but they say that the setup is artificial. During the day they don’t really use TDD, they don’t work in pairs, they communicate differently and they have more time to finish the assignment. These techniques are supposed to show them a new way of working, but the change is too big and instead of cooperation they decide to resist. What about making this change a bit smaller and have a more realistic setup? 

The original idea of the coding dojos come from The Pragmatic Programmer book by David Thomas: developers should practice on small, not job related code base repeatedly so that they can master their profession like a musician. I’m a great fan of David’s work, so I don’t have any problems with the concept, but software developers aren’t musicians, at least not in an Agile/Lean environment: they are football players – the European ones. They have to practice and work together. At least this is what we teach them. Of course, musicians practice together too, but they learn their part alone and then they practice together. Read more »

VN:F [1.9.17_1161]
Rating: 9.2/10 (5 votes cast)