I’ve recently given a teaser talk about software development at the Budapest University of Technology and Economics. The audience was great and thank you for coming folks, I really appreciate it!
When I met Mary and Tom Poppendieck we not only talked about flow efficiency but about the entity that actually flows through the system. According to Mary it can only be a deriverable: a customer request, a feature or a product, but not a patch or a bug fix. The more I think about it and the more I look at my current and previous projects, the more certain I am that she is wrong. My point is that we cannot focus only on deliverables in case of a flow: if we do, we won’t be able to see the big picture. I still believe that a value stream mapping should contain all kinds of things that appear in the flow, and therefore I’d say that the entity that flows and shall be mapped in value stream mapping exercises is the information.
Yesterday, I met Mary and Tom Poppendieck and over a nice beer we were talking about various topics but we spent most of our time talking about flow efficiency (ratio of the value added activities to waiting). When I was riding my bicycle home I was still thinking about our conversation and presented examples. Despite the fact that I think the current right move is to favour flow efficiency over resource efficiency, I think it only works in the simple domain of Dave Snowden’s cynefin framework, where the connection between cause and effect is obvious to all. Here, simple means that the process is clear to everybody who is involved even if it is a long process. If you think about car manufacturing from where the concept of flow efficiency originates, you can see that it’s in the simple domain: every detail of the process is well known to all workers involved. However, in knowledge work and in software development, that is not necessarily true.
As a project manager one of my current tasks is risk management, and I have to focus especially on schedule risk. Therefore I was looking for something that can show me quickly the current status of the project and this kind of risk. I started to use a portfolio Kanban board that covers the whole project, but my board is different from Pawel Brodzinski’s resource oriented board:
I’m using an old idea from Chris Matts - a work item is put into a column that tells us when the it is supposed to be ready -, and the idea of organisational level Kanban boards. If this is week 13, team yellow is doing fine, whereas teams red and blue are in trouble.
I just realised that I rarely define attributes in my classes (the dependency injection references are exceptions) and I’m passing everything as a parameter. So instead of this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
I have this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17