This post is from the Collabnet VersionOne blog and has not been updated since the original publish date.
Thoughts From the LSSC 2012 Conference – Boston, MA
I just recently returned from LSSC 2012 Conference in Boston, MA. Besides getting my iPhone stolen, it was a great conference. The keynote speakers were both thought provoking and entertaining. I especially enjoyed the fact that the presentations demonstrated interdisciplinary thinking. There was a good balance of reports on the continued successful application of Kanban and Lean, as well as extensions to the thinking. In this blog post I will share a few of the presentations I attended which I found most useful. First, there was David Anderson's presentation on a systems/thinking approach to introducing Kanban. In his talk, David approached the concept of introducing Kanban into an organization through a brief, six/step process: 1. Understand the sources of dissatisfaction within the organization
- Consider viewpoints of both internal and external stakeholders
- Identify the source of variability that cause dissatisfaction
2. Conduct Demand and Capability Analysis / ideally by work item type and class of service 3. Model the Workflow
- Understand the knowledge discovery process by type of workflow
4. Design the Kanban System
- Be prepared to negotiate on classes of service
- Let the business folks believe they designed the Kanban system
5. Visualize the work 6. Roll Out the Plan / craft a rollout plan that is appropriate and reasonable for the organizational context
- Consider how to 'sell' the new system internally
This process tends to be iterative in an environment/culture that values learning and enjoys continuous improvement. I was also able to pick up a pre/release copy of David Anderson's new book, Lessons in Agile Management / On the Road to Kanban, and from my inital perusal of the book, it looks to be chock full of applied lessons, as well as value/added perspectives on current thinking in the agile and Lean space. The book is almost certain to educate and amuse its readers. I would recommend it to those looking to develop organizational agility and what I like to call 'lean/ility.' The second talk from the LSSC 2012 Conference that I'd like to mention was the one given by Michael Kennedy on 'Set Based Decision Making / Taming System Complexity.' This was the second time I had heard this talk, but this time I was listening from a different perspective. There was a great deal of focus at this year's LSSC Conference on learning in systems and organizations; this was what got me listening to Michael's talk from a learning perspective. In listening to Michael's talk, it became quite apparent that one of the significant weaknesses we have in software development processes, including agile and Lean ones, when compared to the hardware product world is that we don't do a good job preserving learning. Michael Kennedy used the example of how Toyota preserves the learning, 'how to build cars' within the company's workers. This has been a key to Toyota's ability to produce new vehicles so quickly. In software development, there is little to no effort to preserve within a team, let alone an organization, the lessons it has learned over the years. The mythology of the organization is lost because of reorgs and the view that humans are interchangeable on teams. There is so much focus on the short/term, the next quarter, that there isn't a longer/term perspective where improvement can occur; therefore, the short/term learning in most organizations doesn't accumulate much beyond a project. This is something that needs to change if agility is to progress in software development organizations. The last talk I want to mention was the one given by Mary Poppendieck entitled, "Continuous Feedback: Process Control for Developing Software/Intensive Systems." The particular part of Mary's presentation that got me thinking was on the idea of "whole team / whole problem." It really does seem that many organizations have taken the concept of 'product owner' from Scrum and recreated a situation where product development as a whole has gotten dumbed down in that the development team now understands less about the domain which they serve, and the customers within it. They have become more focused on the 'how.' A by/product of this in such organizations is that there also tends to be less ownership of the backlog and commitment to what's delivered. A 'that's/not/my/problem' mentality can be seen. This is a topic I plan on thinking about further and will have additional blog posts. If you're interested in Lean and Kanban, I highly recommend attending the Lean Systems Society (formally the Lean Software and Systems Consortium) conferences. I know I'll be at next year's event.