Impressions of LESS 2011 and thoughts on helping those new to Lean, Kanban or Agile

November 11, 2011 — Posted by Cory Foy

I must say I was very pleasantly surprised at how good the Conference on Lean Enterprise Software and Systems, 2011 in Stockholm was. I thought it would be good: while last year's LESS conference was a bit academic for my tastes, LESS 2011 offered a great blend of good speakers, consultants, and participants. I looked forward to the Beyond Budgeting track and Steve Denning.

I was not disappointed. In fact, I was very much surprised with the overall value the conference provided me. Much of this was due to the great conversations I had with folks like Steve Denning, Torbjorn Gyllegrin, Frode Odegard, Claudio Perrone, Ari Tikka, Ken Power, David Anderson, Bob Marshall, Jim Sutton, and Jurgen Appelo. My only regret was some of these discussions made me want to modify my own talk – which I did – and that made me miss a few sessions! Every session I went to offered great value and every slot had some session of interest.

Several things about this conference were very important to me. I have been active in the Agile community for almost 13 years now and have been a great supporter of it. Net Objectives was one of the first (if not the first) corporate sponsors of the Scrum Gatherings years ago. I helped found the Lean Software and Systems Consortium and continue as a board member and sponsor.

A lot of progress, and yet…

Over the years, we in the Agile community have made a lot of progress. Yet in this progress, I fear there has been too much focus on Agile team adoption and not enough attention to how Agile can work better across the enterprise.

For example, at the Agile Alliance conference, I heard a lot of talk about crossing the chasm, delight in the adoption of Agile methods by the early majority. But what is often neglected is the vastly different challenges these "early majority" folks are facing. At many companies, early adopters brought in Scrum and stand back in wonder at why the rest of the organization is having so much trouble following suit. The reason is that it is individuals who are the early adopters / early majority, not companies. What's being ignored is that when the chasm is crossed in a company, those now taking on Agile are of a different mindset than those who made it initially successful. This is further complicated by the fact that many pilot projects were undertaken to be successful instead of focusing on identifying the challenges the enterprise (not the teams) needed to address for Agile success. In many cases these pilots made these challenges worse, not better. For more on this, see How Successful Pilots Often Actually Hurt an Organization.

The reality is that Agile doesn't just run rampant through the streets of a company. It's not simply a case of individual teams springing up doing Scrum. Large organizations have a different dynamic and organization than individual teams. I have seen this for years – and our company has had mostly good success helping our clients overcome their challenges.

I was delighted to see how well this was being addressed at LESS 2011, a healthy awareness and acknowledgement of the challenges that companies face when adopting Agile methods – Scrum and Kanban alike. There was no disdain for these folks like I've heard in other camps. Instead of comments about how those who can't get Agile to work just don't have the discipline or motivation to do it, I heard conversations lamenting the misunderstandings while asking how we can correct them. The concern was for the folks having troubles, not an attempt to keep "our brand" clean.

Good Conferences are about Good Conversations

Topics at LESS 2011 ranged from business, to teams, to transition methods, to storytelling, product portfolio backlogs, to experience reports amongst others. It seemed like any topic was open for discussion. Disagreement was not held in disdain but taken as an opening for conversation and discussion.

For example, I held a "bird of a feather" talk on non-linear (that is, non-sequential) Kanban boards. We ended up having 20 folks there at one point. It was a good session and I may write up my own thoughts on it later, but for now I would point you to to Jurgen Appelo's blog, Networked Kanban, Jørn Hunskaar's blog, Kanban in a non_linear flow, and Pawel Brodzinski's blog, Don't Stick to Standard Kanban Board Designs.

As good as the session was, what I most valued was the chance to co-lead this with Jurgen Appelo. It represented a coming full circle for Jurgen and me since we didn't see eye-to-eye at the last conference – and I'm not sure we still do – but we have good conversations now. And this is the hallmark of good communities and good conferences. They are not about promotion or limitations, they are about discussion, disagreement, reconciliation and, hopefully, integration.

A Mature Alternative to Scrum-of-Scrums

The conference represented a kind of coming full-circle for me in another way. I was presenting, for the first time in one talk, a collection of four case studies that dealt with our, now mature alternative to Scrum-of-Scrums. Each of these case studies dealt with the issue of how teams should be organized and work together. Our experience has shown that by attending to structure and the flow of work assigned to the teams, the amount of collaboration required was greatly lowered.

Over a decade ago I had tried Scrum-of-Scrums for a couple of years. Although it seemed plausible in theory, it never seemed to work out in practice, either for us or for most anybody I talked to. Sure, it worked for telling people what was done but it didn't help teams much when it came to guiding collaboration. Most frustrating (for me) was I didn't know why.

About 6 years ago we started playing with other methods to help teams work together and started getting good traction almost immediately. All of these methods, however, involved some higher level vision created by a team outside of the development team. While this was consistent with Lean's system thinking and flow, it was counter to the philosophy of team-up collaboration espoused by most Scrum thought leaders and was not something anyone in the Scrum community wanted to hear.

Others were independently developing similar approaches. Dennis Stevens and the Poppendieck's talked about a method that claimed to assist teams working together at large scale. At LESS 2011, Ken Powers and Torbjörn Gyllebring discussed something similar. It was exciting to see how our experiences at Net Objectives paralleled others.

I called it coming full-circle because I haven't forgotten it was my discussing our challenges with Scrum-of-Scrums and looking for alternatives that got me thrown off the Scrum Development group for the second (and last) time. I no longer dwell on this, but someone recently suggested that perhaps that had happened in an attempt "to protect those on the group." What a strange thought.

Learning… Not "Protecting the Brand"

Perhaps this is what was most encouraging to me at LESS 2011: We would never consider "protecting people" from outside ideas. Instead, we have been figuring out how to introduce folks to outside ideas. It's this continual never-ending thinking that keeps ideas fresh and keeps one from falling for cargo cult thinking. It is natural for people to misinterpret new ideas. However, instead of protecting people from new ideas, I find the continual introduction of new ideas helps people think for themselves to see which ones they need to use. I find the Lean-Kanban community also has this attitude, which is one thing I love about it.

I do believe providing a simplified models as a start point is fine; however, they need to be moved along as soon as possible. To me, protecting people from ideas expresses a belief that they can't handle new ideas. It is a sign of lack of respect. When one limits exposure to ideas, there is also the danger of becoming dogmatic. In my mind, when people misinterpret things, I think it's better to increase their understanding instead of limiting what they are exposed to.

It was therefore very refreshing to hear people say "what do we need to tell them?" instead of "they need to stick to Kanban until they understand."

A Community that Values Learning and Thinking

This is the best way to make progress in software development. Keep learning more and more about software development principles and then use your own judgment to decide what to do. This is much more powerful than trying to learn a set of prescriptive practices and then try to adapt them. Practices can help you get started but it is always best to learn to think for yourself.

I'm glad I have found a community that wants to learn and think together.


Share this:

About the author | Cory Foy

Cory Foy has experience in a wide variety of industries as a developer, technical leader, coach and change agent. He is a frequent speaker at and organizer of conferences and user groups around the globe.


Comments

Thanks for this post Allen. The think I've come to love with Kanban in particular is the focus on the principles and not being so rigid in the processes and methodology. I fell in love with Kanban initially because I found that I could use the principles of mapping value streams, visualizing them, and limiting WIP in many different arenas. I have separate kanban boards for my teams at my day job, for my business and blogging, and even for home between my wife and I.

And the lessons I learn from any of them can usually teach me something about the way people work and how to do things better for all areas of my life.

-Josh

Thanks Josh. We started using Kanban first in maintenance, then in places where cross-functional teams were impossible to form (at least short-term).  But I really came to love it when I saw how management could understand what was going on with the team by looking at the board.  Managing WIP makes it clear you can't just "add one more story" because the team has tuned there process. 

Alan Shalloway, CEO Net Objectives

Hi Alan,

Your reference to a mature alternative for scrum of scrums grabbed my attention. I've been looking for such alternatives and was hoping you could share more details. The only alternative I have been exposed to so far is the Short Interval Management (SIM) that is used in our Lean Manufacturing plant. It's been tremendous having such an example in our facility, but of course translating that to our software team has yet to be seen. Hoping you can shed some light on this topic for me.

Be Well
Drew

I am writing a book on this Improving Collaboration and Planning With Lean Product Development: Patterns of Success and Challenge. It's kind of in  a stall now but I should make good progress on it next week before Thanksgiving.

Alan Shalloway, CEO Net Objectives

I not only 100% agree, I believe you are touching on the most important principle of Agile....
http://blog.alvazan.com/80/the-one-most-important-agile-principle/

later,
Dean

I tend to agree with you. However. we've found something that is better than inspect and adapt. :)

See my blog at http://www.netobjectives.com/blogs/difference-btween-inspect-and-adapt-a...

Alan Shalloway, CEO Net Objectives

Free Email Updates!

Sign up for free email updates from
Net Objectives Thoughts Blog

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Software Design, Design Patterns, Technical Writing, TDD, ATDD, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, SAFe, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile