Tag Archives: lean thinking

When Local Optimization Won’t Make a Difference

Posted by on 2012/05/21 No comments

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)

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

Posted by on 2012/04/17 No comments

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)

Visualize the Flow on the Highest Possible Level

Posted by on 2012/03/19 2 comments

I gave an internal workshop about Kanban a couple of days ago, and the colleagues who were there looked enlightened when I mentioned that Kanban should visualize the whole process, because this is the place where it can help the most. Don’t get me wrong, it is also fine to have Kanban on the team level, but the real optimization and improvement should happen on the highest possible level. Since their reaction surprised me – I thought the goal of Kanban was clear to them – I decided to write a bit about the reasons. A little repetition won’t hurt.

The first core principle of Kanban says: “visualize the workflow” which means that we should make the steps of our processes visible so that we have a clear picture of what happens after the customer sent us a request and we deliver a product. In case of a small company where there’s a direct contact to the customer, and delivering the product does not involve a third party, the [work]flow can be visualized quite simply:

However, large companies tend to have complicated processes, and several teams are participating in the whole flow:

Read more »

VN:F [1.9.17_1161]
Rating: 10.0/10 (2 votes cast)

Daily Stand-up is About the Future not the Past

Posted by on 2012/02/28 No comments

In the last couple of weeks, I was thinking a lot about daily stand-up meetings for two particular reasons: first of all, the meeting I was attending was inefficient, and second, something bugged me with the whole concept. We were following the structure introduced by the Scrum framework: every member talks about what she did yesterday, what she’ll do today and what is blocking her from achieving her plans.
What really bothered me was the first question: “what did you do yesterday?“. If one works with a co-located small sized team why should one talk about the past? Talking about the past is a waste of time, or if it is necessary then something is wrong with the organization: people work together and they have no idea what the others are doing. Unfortunately, we talked a lot about the past. Management was interested in the past, so during the last months the whole meeting turned into a sync meeting, where we gave a report about our activities.

The sad thing is that we are always one day behind. Quite recently during a stand-up, a colleague of mine talked about an interesting database change. He implemented a workaround and gave us the highlights during the daily stand-up. I remember clearly that he got very good and usable feedback on a real implementation, not a workaround, but since the change happened in the past and it would have taken too much time to change it back, nothing happened and the workaround stayed. If he had mentioned this before, we wouldn’t have had to live with a workaround which will cause a lot of trouble later. This is the price we’ll pay later for living in the past. Read more »

VN:F [1.9.17_1161]
Rating: 10.0/10 (7 votes cast)

Visit at Cluj Napoca

Posted by on 2011/10/30 No comments

My old friend Victor invited me to Cluj Napoca, Romania to talk about software development in practice. There were three talks in the morning at his company evoline and a fourth talk late afternoon at the local meetup group.

We started the day with an introduction to Kanban, because the audience knew about Agile, but Kanban was something new, and additionally we needed it for the maintenance-related presentation:

After a short break we continued with a longer talk about maintenance and how to use Agile, Lean, Kanban and leadership techniques in order to stabilise a maintenance situation:

The last presentation was about how to use Agile techniques without saying Agile:

My talk at the meetup became a bit longer than I expected, but we had – at least I felt like that – a great discussion how the software development process evolved at Digital Natives – my current company – and, uniquely, we talked about what we were doing right and where we failed:

I promised a list of books worth reading. So here are they in a recommended reading order:

  1. Taiichi Ohno – Toyota Production System
  2. Henrik Kniberg – Lean from the Trenches
  3. Daniel H. Pink – Drive
  4. 37 signals – Rework
  5. David J. Anderson – Kanban

Even though it was a long journey and an even longer day, I enjoyed it very much. The audiences were great, and I got some very usable feedback on the style and content of the presentation (I’d like to specially thank Dragos, Cătălin and Victor for the detailed and more personal feedback), so I can improve my future talks. My next talk will be at my former employer Ericsson, and I’m going to talk about leadership and measurements.

Thank you folks for the possibility, it was my pleasure!

VN:F [1.9.17_1161]
Rating: 9.5/10 (2 votes cast)