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.
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.
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.
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.
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."
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.