“The possession of tools, techniques, and technology is not the competitive advantage…it’s the learning you wrap around them before anyone else.”
– Steven J. Spear, Senior Lecturer – MIT Sloan School of Management & Engineering Systems Division – May, LSSC 2012, Boston
“Specifications should come more toward the end of the project not the start…capture knowledge for future use – both successes and failures.”
– Michael Kennedy, author of “Ready, Set, Dominate”, retired Senior Member, Technical Staff after 31 years at Texas Instruments Defense Electronics – May, LSSC 2012, Boston
“I’ll probably annoy a few system thinkers as well as proponents for self-organizing teams, but that means I’m doing my job…extremes of centralization and de-centralization are sub-optimal.”
– Don Reinertsen, educator at California Institute of Technology , author of “Product Development Flow” – May, LSSC 2012, Boston
“Today, I’d like to be provocative, not obnoxious because I think that is the place to be…pushing people to work faster is not as effective as working on the interfaces (the handoffs).”
– Gregory A. Howell, educator, author, and co-founder & managing director of the Lean Construction Institute (LCI) – May, LSSC 2012, Boston
“Experience is not the same as knowledge (remember from which you are answering a question).”
– Yochai Benkler, Professor of Entrepreneurial Legal Studies at Harvard, and faculty co-director of the Berkman Center for Internet and Society – May, LSSC 2012, Boston
If you missed the Lean Software and Systems Consortium 2012 (LSSC 2012) conference in Boston and you’re looking for an overview of the keys from the keynotes, highlights from the presentations, or a taste of the pre and post conference happenings, I can point you to several posts that do that very well here, here, here, and here. (Note too, going forward the LSSC is now the LSS, the Lean Systems Society, which you can find more about here).
Here’s My Take on the Lean Software Systems Consortium 2012 Conference
An alternative perspective of LSSC 2012 that I’ll offer you orbits more narrowly around my single biggest takeaway. It wasn’t a single keynote talk or individual track presentation, it wasn’t some succinct brilliant message appearing in the titles for any of the keynote talks or track presentations, nor was it overtly offered as “the main point” for any of the keynote talks or the track presentations that I saw. It was, for me, an unmistakable message noticeably and repeatedly threaded, as the underlying (core) lesson, into the themes of the keynote talks and several of the presentations I attended. “Focus on Learning to Learn” emerged as my “un-official theme” for the conference and was the key takeaway from LSSC 2012.
On the surface that sounds a bit obvious doesn’t it? Learning is the focus or purpose of most any conference, right? Okay, I do wonder about some that occur year after year in the same resort places, but that’s for another time and place. Yes, of course, “learning” is the focus of most any conference. To be clear though, I’m specifically saying, “learning to learn” here, not just “learning.” What’s the difference? 1
My Early Days – Some Context and Framing
I attended few conferences for professional development early in my career because I found them more often great for breadth but not much in the way of depth. Instead I mainly attended class-type seminars or courses and focused my learning on IT/IS technologies, technical software development practices, software architectures, and the current business domain I was in at that time. That’s plenty, but there were still other problems to solve! I also observed these problems could often marginalize the best efforts put forth from hard-earned learning and lessons in implementing technologies or technical practices.
In 2004 these types of problems led me to learning and applying lean-agile principles and XP practices in my software development environments. They also helped me begin seeing the need to learn even more about the processes governing the environments I worked in as well. This led me to learning and applying more explicit principles of flow, queueing theory, and pull/kanban methods starting in late 2007. It was then I became even further interested in learning more about processes in the software development context and in the concepts broadly related to learning.
Another Try: The First Lean & Kanban Conference (L&K 2009)
These new interests in processes and learning, in particular related to the software development context, led me some three years ago to attend the first ever Lean & Kanban conference in Miami (Lean & Kanban 2009, before the name change to LSSC). I followed that by attending LSSC 2010 in Atlanta, LSSC 2011 in Long Beach, and most recently LSSC 2012 in Boston. In this time I’ve seen this conference grow in number, but more importantly it has grown in quality and learning value. While I think Miami in 2009 will remain my most unique LSSC conference experience, Boston in 2012 is now the high watermark for me personally. In large part I think it is because of the type of thinkers I’m able to meet and talk with in the LSSC community and the message I hear from them, Learning is great, but “learning to learn” is a much more powerful ability to pursue and possess.
Think about this for a second. The attendees of the LSSC 2012 conference are principally from the software development context, yet the three keynote speakers and two of the “featured” 90-minute presenters (see quotes above) are all distinguished individuals outside of the software development field. Still, all of their messages were quite valuable, applicable, and useful to me (and I believe most who attended as well). Why?
For me, it’s this focus on learning to learn! It’s this focus that has made the LSSC conference and this community more valuable to me over this time, and in particular LSSC 2012!
Where can you literally turn around in your seat while your waiting for a keynote to start and find Don Reinertsen ready and willing to chat with you one-to-one for 15 minutes about your questions related to what you think are misconceptions in the use of CFDs in the software development context?
Where can you find the likes of Greg Howell (co-founder of the Lean Construction Institute) standing a “safe” distance from the pre-dinner reception chatter for the Brickell Key award willing to answer your questions one-to-one for 30 minutes about his project management experiences in the construction field and how what he learned could help you in a software development context?
Where could you attend a conference, then catch “the T” to M.I.T. 10 minutes away, and discuss one-to-one for 45 minutes with Dr. Stephen C. Graves (author of Ch. 5 Little’s Law, and Professor of Mechanical Engineering and Engineering Systems at M.I.T.) some about his work in operations management, and his work with John D. Little?
The answer for me to all of these questions was LSSC 2012 Boston!
Connections -Big K Kanban and little k kanban (meta-process)
This focus on learning to learn I believe too is why over the last few years many in the LSSC community now more often refer to the Kanban Method as a meta-process, what is often called “big K” to distinguish it from the “small k” when talking more specifically about a “pull” system. That is, a meta-process layered on top of your current software development workflow process, not something to “replace” your current process. This meta-process is really more about identifying properties that focus on learning to learn about your underlying process, not prescriptive steps for a process. It is this focus on learning to learn that contributes to what is often described as the “catalyst for change” to your process. Yes, as you learn to learn more about your underlying process, it should result in changes, real and effective changes based on validated learning, to your underlying process.
I see this focus on learning to learn too at the core of several other practices found in our software development context. For example, in the Test-driven Development (TDD) cycle, in the different forms of set-based planning, set-based design, and set-based engineering, and in pull-scheduling systems. So, as I continue to reflect on my LSSC 2012 experience, I’m pretty sure there is a post or two coming from me in the near future that will be inspired by what I learned at this conference. I can tell from notes I captured during the keynote talks and presentations for any one of those listed above, along with several follow-up conversations I had with some of them since the conference (and not to mention from reading, and re-reading now some of their books), the greater challenge will be narrowing it down to a post or two.
My last two months were pretty full with helping organize and put on our local Mile High Agile 2012 Conference, developing and delivering several training tutorials on the road, and attending LSSC 2012 in Boston as well as co-presenting a tutorial there. So, now, I’m working to get a little slack back into my personal kanban board, including time to revisit my “blog post seed material” folder. I hope you’ll stay tuned!
1 For a reasonably short but still usefully in-depth paper as a starting point on understanding how teaching, learning, and learning to learn, might differ, check out “Learning to Learn” by Karl R. Wirth and Dexter Perkins.