Well I am now a whole conference behind in my blogging, so I will try and make this a lot shorter than the previous one.
Day Two started off with a keynote from David Anderson called “Creating a Limited WIP Society in your Organization”. Much of it was fairly familiar to anyone following the mailing list, and I assume to anyone who has read his latest book, which I unfortunately haven’t yet. For me there were quite a few nuggets of wisdom, and things I wasn’t aware of. Interesting was his observation that approaching lean from an angle of waste reduction is difficult as it tends to point the finger at traditional project management activities as being waste, which naturally leads to resistance from project managers. His preferred motivation for lean is encouraging an evolutionary approach to change and the emergence of lean software development behaviours, and to enable this by utilising a pull system that limits WIP, which will catalyze the other pillars of lean. He listed his seed conditions, of which most were already known to me. The interesting one for me was the use of models (such as variability, Deming’s system of profound knowledge, real options etc) to evaluate improvement opportunities. Having a toolkit of models is something I really have to look into, and something I intend to discuss on the mailing list, once I have read the book at least. It really underscores that Kanban, like Scrum, is not a software development or project management process, but a system, I guess is an acceptable word, for managing change, that relies on other ideas not pat of it. I really do see Kanban and Scrum as occupying the same place in the spectrum of ideas, with the fundamental difference being that Scrum (when done properly at least, even though the scrum guide considers the use of scrum as a fairly static tool for planning tasks within the development phase of a waterfall project as perfectly valid, I don’t even consider it scrum-but) requires radical revolutionary change, and Kanban allowing a slower more gradual change. I hope Kanban manages to avoid some of the same mistakes that the Scrum community have made, falling into the static task planning tool hole, and recent messages on the kanbandev mailing list have shown that this danger has been perceived to exist, and attempts are being made to reinforce the nature of what Kanban is, and avoid such misunderstandings. Another idea that was new to me, that I found interesting is the use of Process Control Charts. It seems like a great tool for discovering the natural, or common-cause, variability in a system, and being able distinguish it from special-cause variability. Probably the most important thing he said was that leadership is the magic ingredient. Seems obvious, but I am sure most of the time when these modern ideas like Scrum and Kanban are implemented, a consultant comes in and sets it up, at least to the extent at which people accept, and then developers focus on developing software, analysts concentrate on talking to the customers about requirements, managers revert to operating the system in a mechanical way but no-one takes a leadership role in the kaizen effort, and only a small fraction of the true potential for improvement is realized. Without a passionate change agent, who reads the books, and the mailing lists, and goes to the conferences, and actively builds up a collection of models for improvement who has some level of acceptance in the organization and some sort of authority, preferably of a “tribal” nature, but in most cases at least a minimum of official authority, then why bother? It is just going to seem like another buzzword, sold to the organization by a consultant, as a way to assist managers in commanding and controlling the workers. Anyway, I should make an effort to digress less. A good first step, according to Anderson is demand analysis, which is like what John Seddon said the previous day. Look at the types of work, their arrival rate, the expectations for delivery, the nature of the variability. After that you can begin to map and visualize the workflow. And of course, limit that WIP!
The second session I attended on day two was “A Kanban Multiverse” by Karl Scotland. It was all about better visualization, and more visual forms of communication, but he also covered some other interesting things. He started off by asking us to imagine how the battle of Britain would have gone if it were managed using a sharepoint site with a wiki and by mailing around change requests. He said visualizations can be used as augmented memory. To be honest though, and this is perhaps because I am not such a visual thinker, I felt a lot of what he showed us reminded me of Gantt charts. I just thought how wasteful is that, why not just all sit together, and talk, and use as little tooling as possible, perhaps a task board, a CFD and a process control chart. I see visualization as being a bit like documentation. Sure, do as much as required, but no more, after that you are being wasteful. But my mind could be changed on that. He talked about boundary objects, and how they represent something that is interpreted by different roles in different ways, that visualizations are one example of boundary objects, but so are acceptance tests, according to Brian Marick. Then he started talking a bit about Dan Pink’s ideas on motivation. He linked the Purpose aspect of motivation to visualization by saying that that is how teams can see where they fit into the value stream. He talked about chart junk, and mentioned a few other things that I made a note of to read more about such as Story Mapping, “Yes with Consequences” and the work of Tom Wujec.
The third session was “Seeing What Matters – Using the right vision to manage transition” by Alan Shalloway. It was a fairly densely packed talk, so I won’t give a point by point rundown here, particularly as it was a few days ago now. He talked about Pareto curves, and finding the right balance between new projects and improving old ones. He went into some nice detail on value stream mapping, and working out the process cycle efficiency etc, most of which wasn’t that new to me. He talked about not just getting better at what we do, but eliminating delays between the things we do. He said the Kanban board should replace the initial VSM as there is no point in maintaining two versions of the same thing. This was interesting, as I always see VSMs with things like “prioritise initial objectives”, “get funding” and “submit quote to client”, yet the Kanban boards I always see are more like “Selected”, “In Development” and “Testing”. I think Kanban (and Scrum for that matter, why not?) boards in general should visualize a much wider scope than they typically do now, particularly they should address the upstream business and customer related activities as being part of the process as the same level as the technical activities. He talked about the relationship between queues and delays, visualizing the feedback cycles, and he discussed some anti-patterns, like component, or layer, teams. He suggested looking at whether the team understands why they do what they do. Can they link the tasks they do back to the business objectives? Can the manager link the business goals to the tasks that the developers do? And lastly he talked about using silver cards to expedite, and making it a business decision, with consequences.
After that we had an “open space” track, it didn’t seem that well organized as an open space thing, or at least the participants didn’t seem to embrace the concept. Most people wanted to play the Get Kanban game, and the Dot Game. The Get Kanban game was fun. My job was to maintain the CFD and process control charts, unfortunately this meant I didn’t perceive what was going on in the actual Kanban bit itself as well as if I had another role like manager, tester or developer. But it was still a great experience to take part in. I didn’t play the Dot Game but I observed. The main point is in observing how a system based on single piece flow, pull, tight feedback, optimizing the whole and swarming is superior to one based on batching, pushing, and local optimization. They do this by building up a card with coloured stickers on it according to a pattern specified by a template. Particularly interesting is how, without being told, people naturally communicated when using the lean approach, but were too busy to communicate when using the traditional approach. And of course, the throughput and error rate were much better when using the lean approach.
The closing keynote, from David Joyce, was an excellent finish to the conference. He really brought it all together and related it to his practical experience at the BBC. He drew heavily on Systems Thinking, and the ideas of Ohno and Deming to present a view of lean different to what I was familiar with, as well as a summary of the ideas presented in other sessions. One new idea that I found interesting was that of Double Loop Learning. It is actually something that I had approached in my own thoughts myself when thinking of how principles and values can be used as a decision making rather than far off goals, so I will definitely be interested in looking further at that.
Anyway, that will do for now. In the meantime I have been to another conference, so I will try to blog about that in the next few days.