On Thursday and Friday of this week, I had the pleasure of attending the Lean & Kanban 2010 Europe in Antwerp, Belgium. A few days before it I found out my dissertation had to be related to, and ideally useful for my current place of work, so as I was attending the presentations and making notes, I was thinking about everything in that context, relating it back to my work, and planning how I could apply all that knowledge and wisdom to my presentation, especially the initial high level plan that I should be presenting the boss with over the next few days. I think I have come up with something ideal, but more on that later. As I mentioned I was taking notes while attending the presentations, but I decided rather than just copy down the slides, I would be better off writing down some of the many directions my mind was racing in. So often I heard something and then combined it with some other idea, and went off on some tangent and wrote that down, so apologies if this blog post ends up representing what I made of the content more than the content itself.
The first event was the opening keynote by Alan Shalloway titled “What is next in the Agile world: Why Lean / Kanban matters”. Someone who I have been following on twitter for a while now, and retweeting a lot, as well as being familiar with his ideas through various mailing lists that we are both on. In fact one of the most retweeted tweets inspired by his keynote was something like “Why you need management commitment in agile? Most impediments are located outside of your dev team”. He also mentioned that Agile hadn’t managed to solve the problem of team rule vs management micromanagement. I feel like the subtitle for my dissertation could be drawn directly from that idea, as at my work, agility and scrum really are just development specific local optimizations within a larger more traditionally managed process at the project and organizational level, and one of the first things you learn about lean is to “optimize the whole”, as local optimizations tend to reduce throughput, and compromise the system, yet still manage to appear good in metrics etc. He also mentioned that many problems tend to get blamed on development, as that is where they become apparent but are in fact caused by management. He talked about the difference between productive work versus waste, and removing delays can be an effective way to remove a lot of waste. He mentioned that the nature of people means that teams working together is a hard problem to solve, as teams tend to take care of themselves before other teams. A fool’s errand he called it, and avoiding the problem should be more effective than trying to work around it via a scrum-of-scrums or similar. He talked about recognizing pipelines in the system, such as the business value pipeline, and looking at the distance between those who choose what to work on and those who actually do the work. He presented lean, or one aspect of lean at least, as a kind of science with rules, like gravity, that should be accepted and worked with, rather than denied. One of the most interesting points for me, as I am particularly interested in workplace culture, is that you can’t change culture directly, it is a consequence of the management system. It is no wonder that in our company we haven’t yet seen a strong agile culture emerge despite using scrum in the development department, as the management system is still decidedly un-agile! Shalloway mentioned the importance of making the management system explicit, and the role of management in teaching teams about lean science, and how doing so builds trust. The topic of lean learning and continuous process improvement was presented, emphasising improving all processes all the time, the necessity of visual controls and team involvement. It was also mentioned that learning is the result of dynamic interplay between theory and application, which I guess is the constructivist theory of learning, and something I feel I need to keep in mind, as it is easy for me to read the theory about something, but I know I don’t truly learn something until I get a chance to try it out in a real world situation. I really have to push at work for chances to allow my practical experience to catch up with what I have been exposed to through book learning. Lean science was described as one of the parts of Shalloway’s Lean Enterprise Model along with Lean Management and Lean Knowledge Stewardship. He reiterated that lean science consists of the rules of software development, business and management, and understanding that part of the model is a good place for smaller organizations to start. He then talked about the differences between Kanban and Scrum. (This is something that everyone seems to view differently depending on their bias though. See for example how Dave Anderson compares the two. Personally I think they are comparable. You can misuse either one as a simple planning and scheduling tool, and set it up to prevent organizational change and self-organization, as a local optimization in the development department, and adjust it to hide problems and make it a better fit for existing anti-patterns. Or you can use either as a change management tool to empower teams to make problems and anti-patterns more visible and help solve them wherever they are in the value stream. I guess it just turns out that Scrum is more visible to less engaged people so tends to get misapplied more often in a cargo-cult fashion than truly leveraged as it was intended, whereas Kanban has less of a presence amongst the cargo-cult method-buyers, and tends to get used by people who actually understand it.) Toyota Kata was recommended as a book, which I just discovered was already on my Amazon wishlist. He talked about the differences between Scaling Agility, and Agility at Scale. Whereas Scaling Agility is basically trying to get teams to work together, which doesn’t work, and Agility at Scale consists of focusing on the entire value stream, shortening the cycle time, and avoiding excess WIP at the product level. He then discussed another favourite topic of mine, the nature of software development as a profession. His opinion is that it is not yet a profession but he would like it to be.
There will definitely be a chapter in my dissertation titled “Lean Science”, so I shall be seeking more knowledge on that topic over the coming months.
The next session I attended was “The Road to Continuous Improvement” by Sandrine Olivencia. She presented a view of lean, strongly based on the Deming Cycle, featuring many ideas and concepts that I was unfamiliar with, which served as a good reminder that there are a lot of lean ideas out there other than the software specific takes on lean that I am aware of through the work of the Poppendiecks and systems such as Kanban. It appears there are many more paths to applying lean concepts from manufacturing to the software development world than I was aware of. She presented a client-focused approach to problem solving, emphasizing observation, low cost solutions, learning (the hardest and most important bit) and evaluation. She said, “don’t just mention change, write it down, train people, break the old mental model and build a new one”. She went through a case study of a team she worked with to improve production, customer satisfaction and quality. Her toolbox includes a 3-day kaizen workshop with a “voice of the client” exercise, where the teams perception of the client’s needs is compared with the client’s true needs, the waste hunt where examples of each of the seven type of waste according to the TPS are identified. She discussed the four types, or causes of variability: Men, Machine, Method and Material. She presented her Lean Method consisting of visualizing production to reveal problems, reacting immediately so problems don’t get out of control, resolving problems one by one and improving work and management practices. She described the “Obeya Room”, something I had not heard of before, and emphasized that her approach to lean focuses on developing people rather than merely implementing tools. To conclude she mentioned that the hard part is finding the right problem quickly and resolving it with the true solution, and that senseis such as those that she learned from can do this quickly and set a high bar for her to live up to. Her final point, which underscores the one made by Shalloway in his keynote, was the importance of management involvement. My initial thoughts when attending this presentation were that it just seemed to be a do-it-yourself agile method, and seemed rather tool focused. I wondered where is the lean? But by the end I realised that there are many paths or approaches one can take towards lean software development, other than what I had been exposed to, and although she really did try and emphasize the importance of team learning rather than just the tools used to enable that learning, I guess the tools are easier to convey in a presentation because for me the main takeaway for me was a set of interesting tools that I would be interested in trying at work.
The third session for me was “The IT Portfolio as a Form of Waste” from Dave Nicolette, whose blog I have been reading for a while now. He mentioned right at the beginning that the talk related to companies that offer non-software products, and use IT in a supporting role, rather than software companies like the ones I tend to work for. I almost left and went to another presentation, but I thought it might be an interesting thought experiment to look at our software development department as if it were an IT department in a non-software company and see if it offered any insight. It wasn’t a perfect model, but definitely helped me get more out of the presentation and I was glad to attend it. A central theme was the separate planning between “the business” and “IT” that creates waste. This was perfectly familiar, as even in our software company there is a wasteful mismatch between the scrum-like approach to planning that we use in the software development department and the more phased approach to projects used in the rest of the organization. I can only imagine that this separation must be even more nonsensical in an actual software vendor than in the non-software organizations that Nicolette was talking about. He discussed how this structure creates examples of the muda, mura and muri. He mentioned the book Beyond Budgeting, which I also have in my wishlist, as a source of interesting ideas, and told us how estimation is a waste as it is not what the customer buys. He talked about incremental budgeting, which is an idea that has always intrigued me since we discussed it earlier in my uni course, and how it is based on value rather than costs. He said that what IT needs should come directly out of the business strategic plan, and he expressed his preferences for the term “business needs” rather than “requirements”, as well as his interest in real options, which is another concept that I have been curious about for a while, and will hopefully learn more when I attend a presentation about it at JAOO next month.
I really think some of the beyond budgeting / incremental funding / value-rather-than cost-based accounting ideas should also find a prominent role in my dissertation.
The fourth session I attended was “The Rise of the Lean Machine: Architecting the Lean Enterprise Transformation” by Claudio Perrone. Incidentally, the slides are currently one of the day’s top presentations on slideshare, he did all the pictures himself, that combined with his obvious natural talent for doing talks and storytelling, made it a particularly enjoyable session. He started off by talking about dream organizations, or at least how rare it is to find oneself in one, and mentioned rightshifting, a term I have been hearing about on twitter recently but have not yet really investigated in much depth. He told a story based on his experience where he presented the Toyota system, consisting of two main pillars. JIT, or Just In Time, and Jidoka, with a culture of continuous improvement in-between. These pillars, support three of the four “true north” metrics: Quality Improvement, Delivery/Lead Time/Flow Improvement, Cost/Productivity Improvement and Human Development. Actually go check out the presentation on slideshare, save me repeating it all here. One thing I paid particular attention to was his picture of a Kanban board shared by two teams. Up until now I had the idea that implementing Kanban at work would involve either combining all the (currently “scrum”) teams together, or giving each team a separate Kanban board, both of which have disadvantages. His Kanban board with swimlanes for each team would suit us well I think. Each team could have their own columns for selected, development, but all teams could share columns for things like analysis, validate and quality gate, which currently happen either outside the teams (in the case of analysis and validation), or across teams (in the case of quality gates). Another thing I found interesting was his use of the ArchiMate visual modelling language for doing value stream maps. I made a note that I must try it out, as I see a definite need for creating value stream maps in the near future. One slide that is worth reiterating here is his vision of a possible future:
Embrace lean concepts at the management level (the level that reports to the CEO)
Appoint value stream managers
Pull value at all levels
Align business and IT around value streams
Expect people to continuously improve their own process
The fifth session I attended was Ryan Shriver’s “Value Over Velocity – From Feature Building to Value Delivery”. This was material that I was already familiar with through my course, as we studied both the original Tom Gilb Evo approach as written about in Competitive Engineering, and we had an assignment based on Shriver’s paper, “Measurable Value with Agile”. His agenda consisted of three points. Identifying the Right Goals, Quantify for Clarity, and especially interesting for me, Integration with Scrum and Kanban. He presented his approach as being the next thing to attempt after learning effective agile delivery. Teams that haven’t yet made that work should concentrate on the basics first. His approach involves three transitions. Rather than focussing on the means, the focus shifts to the ends. Rather than planning by feature, planning occurs according to value, and instead of attempting to maximise velocity, we attempt to maximise value. (As an aside, I think this represents a misunderstanding of velocity, it is not something to be maximised, it is merely a planning tool that if anything reflects the ability of a team to estimate by its stability, rather than reflecting the ability of a team to deliver according to its magnitude, but there are people out there who view velocity as a kind of score to be maximised, so it is not that cut and dried). He reinforces the idea that the main idea of quantification is to ask the right kind of questions that lead to discovering exactly what we want, which is similar to the way Scrum planning meetings are more about learning about what needs to be done than the actual planning. For me there wasn’t much new in the first two points in the agenda, so I spent the time pondering the third point, how it could be integrated in Kanban as an explicit policy as one of the leftmost columns on a Kanban board, recognising it as a first class activity in the value stream, and a way of involving the people that do the work in helping choose what work is to be done. He didn’t really mention this though, so I asked at the end for clarification, and he said he sees it as something that occurs outside of the Kanban system itself. I am not so sure about that. I see a lot of value stream maps that include things like preparing quotes for the customer etc, but most of the Kanban boards I see seem to be restricted to the core development activities of analysis, design, implementation and test etc. I would hate to see the same mistake being made with Kanban that has been made with Scrum, reducing it to a local optimization in the development department, rather than using it to unify the entire value stream. For me Shriver’s approach of quantifying objectives, and using impact estimation to evaluate ideas absolutely belongs on the Kanban board, but I am open to being convinced otherwise. Apart from all that, the idea of rather than implementing the features our customers request, to ask them for their quantifiable objectives, and allow us to come up with the features would be pretty radical in our company I think, but not unrealistic, and something I would eventually like to look at. We aren’t there yet though.
The final session on the first day, the closing keynote by Professor John Seddon, titled “Re-thinking lean, re-thinking IT, re-thinking management” was my favourite session of the whole conference. No slides. He just stood there and talked, and talked extremely well, conveying considerable intelligence and wit, which made being there both a pleasure and a privilege. The main problem he addressed was that neither management nor IT people understand how work works. For me the main topic of interest was systems thinking in general, and specifically demand analysis. He presented a healthy mix of theory, practical tips, and real case studies. He said change doesn’t start with a plan, it starts with gathering knowledge. He talked about the differing natures of value demand and failure demand. He mentioned we shouldn’t set targets to reduce failure demand, because targets created it in the first place. As well as discovering more about the natures of both kinds of demand as they pertain to our organization, we should also attempt to understand the predictability of demand. He reinforced the comment that Shalloway made about management causing problems that are discovered in development by saying that problems are usually at the “front end”. (By now I am absolutely motivated to provoke the same sorts of changes at work at the management level, that we in the development department have attempted to undergo). One goal of this demand analysis is to match resources (I suppose he is not just talking about humans here) to demand, which means that there are always resources available, and that they may sometimes be idle, which ok, but non-intuitive for traditional Taylorist managers. He then talked about improving the design of the system, and pulling IT into the new design. He said that our tendency to attempt industrial solutions, and our obsession with costs are not appropriate for service organizations, and neither are sweating resources, splitting work into front and back offices (and no middle offices are not the solution), or standard times.
In systems design, the tradesmen make the decisions.
Some of the tidbits I picked up include: You cannot just take tools from e.g. Toyota, you have to focus on learning and improving rather than using tools. Cost is not an activity, it is in the flow, it is end to end in the service design. “People not doing it right” is not a cause of failure demand, the system usually is, and not just the process either, but the whole system. Expecting management to come up with solutions disenfranchises those who do the work. Standard work is only relevant if chosen and controlled by the worker.
Anyway, this blog post is far too long, over 3000 words already, so I will leave it there as a Day One coverage only, and post my thoughts on Day Two later in the week. The ideas for my dissertation are already starting to take shape. It will start off with demand analysis, and then go into some value stream mapping, and I will probably take it from there. It just wouldn’t be lean to build up an inventory of ideas now, and spend too much effort on a non-value activity like planning.
I noticed Dave Nicolette also blogged about the conference. You can check his post out here: Lean and Kanban Europe 2010 – Trip Report