Tag Archives: lssc11

Learnings from Lean 2011 #lssc11

Where to start.  There are so many thoughts swirling in my head so I’ll try to be as brief as possible.  This was my first Lean conference, I’ve been to many Agile-related conferences and open spaces and my first observation was that the ‘feel‘ of this conference was much different.   It’s hard to describe but the sessions and discussions at LSSC seemed to be more connected to what is actually going on in the software industry.  There seemed to be less talk about values and principles (other than the first keynote) and more about leadership, people and practices that business today use and how businesses that are not using these practices can benefit from them.

Let me explain.

Agile events tend to be more ‘fluffy’ feeling in my opinion, which is great, I learn a lot at those events but often they don’t dive deep into how to apply the techniques.  Lean seemed to be more rational and fact based and talks about explicit processes and practices that you can use while Agile is more about just letting the people figure it out.  Perhaps Agile and Lean can converge at some point, which is largely what I think is starting to happen now.

Some of the things I learned that stuck out the most:

Leadership Matters….a lot: Well isn’t this the obvious statement.  The success case studies about Corbis from David Anderson’s book (session hosted by Dominica DeGrandis) and Alan Shalloway’s talk both had wildcard factors.  In the case of Corbis, David joined as Director.  While, according to his book (which is brilliant by the way), he didn’t impose his will onto the teams, his leadership and deep subject matter knowledge clearly allowed Corbis to transform.  Same for one of Alan’s case studies from his talk about having dynamic feature teams.  All of the people in this department (50+ from memory, likely more), rolled up into one Director so there wasn’t a need to cross organizational boundaries which is quite difficult.

Again, this sounds obvious, however from my experience most organizations don’t have strong enough leaders to take the risk of Lean transformation.  Organizational politics and functional silos are extremely difficult to navigate without support from strong leaders with clout.

Organizations are Complex Adaptive Systems: Simply stated, organizations are too complex to think you can define a process once and stick with it forever.   Organizations that can embrace change and understand that people are not linear have a greater chance for success.  You don’t want chaos (no process) or strict control (rigid rules and processes that don’t change), you want a balance of the two.  Create a system, with contraints, that empower your people and understand that people will behave based on these constraints.  Also understand that your system will evolve and a process that may have worked 3 months ago might not make sense now.

Targets are Helpful, Metrics are Not-So-Much Helpful: I am biased against all metrics.  Give me a metric and I’ll find out a way to game it, as I’m sure most people can.  I am in favour of targets that help influence the right behaviour and I had many conversations with people about this and many speakers talked about this same thing.  A quote that stuck out was “once a target becomes a metric it fails to be useful“.   Trying to figure out black and white metrics in complex adaptive systems (or more plainly stated, in today’s software world) is extremely difficult, if not impossible, to do.

Go to the GEMBA! The best way to improve your organizational efficiency is to make your processes explicit, monitor the progress and use that data to drive better decisions. I posted about an “Agile Maturity Model” last year stating the same thing.  Using data to drive decisions takes emotion (or most of it) out of decision making.

Kaizen takes Discipline: I find that Lean is much more explicit about how to build a Kaizen-focused culture than Agile is.  Lean provides processes, practices and tools for building a Kaizen culture whereas, IMO, Agile does not.   Agile seems to drop Kaizen into a blackbox and talks about how the people will auto-magically make it happen.  Lean talks about specific practices and processes that lead to Kaizen.  For example, most people are aware of the value of retrospectives.   In the Agile community I find there isn’t really much information about how to actually execute on the outcome of retrospectives.  It’s left to the people.  This is fine if your people have specific temperaments and your organizational culture supports this.  What I find is missing is that Agile doesn’t help managers understand that improvement work is just that.  Work.  Lean, and Kanban in particular, specifically talk about using capacity allocation for improvement work.  David Anderson’s book has some great examples about how to deal with this.

What’s it Called?  It Doesn’t Matter What it’s Called!I learned how to think in my own context”  This was a statement from Benjamin Mitchell during the “What do we mean by Lean?” panel discussion.  I find people and organizations focus on conforming to a process or set of practices and determine how effective they are by how well they are doing these practices (Nokia test, Shore graph etc).  While these are great checklists to point you in the right direction if you’re not getting the results you thought you’d get, focusing on doing the practices right is less important than focusing on outcomes and strong leadership is needed to support that line of thinking.

Alan Shalloway shared a case study about how a large department created ‘dynamic feature teams‘ .  The reader’s digest version is that multiple teams were working on products and they would pull the work from the backlog and staff the work with the people who were capable of doing the work.  Some items needed people from multiple teams, some items could only be done by specific teams.  At the end he said he didn’t know what to call that process, it’s not really Lean or Agile or Scrum or Kanban, it just seemed to work.  At the end of the day, isn’t that what matters?

Ok, this was a bit longer than I had hoped and I really only touched on the more important things I learned.  As far as feedback on the actual conference itself (in case any LSSC co-ordinators are reading this), here goes:

  • the keynotes were all fantastic.
  • the venue was fantastic, I liked the food so I dunno what people were complaining about!  Lots to see and do around the hotel.
  • the “visibility track” wasn’t very visible since it was on the first floor away from the rest of the tracks.  I had about 50 or so people in mine but there wasn’t much visibility into those tracks compared to others.
  • the program book, website, mobile version of the website made it hard to know which talks were in which tracks and where they were happening.  It would be helpful to just have a big VISIBLE list in the main conference area with all talks and what room they are in.   Maybe there were just too many different ways of viewing the schedule, especially since  the Crowdvine site used colours which were different from the colours in the program book.  Maybe it’s just user error on my part.
  • not many leaders (organizational leaders) were there.  Next year’s proposed Management Track may help.

All in all I learned a lot, met some brilliant people and was happy to get my first major speaking event under my belt.  I hope folks that attended thought it was valuable and I am looking forward to seeing you in Boston next year!

Special thank you to everyone involved in the planning, volunteering and execution of the event!

What Does Lean, Agile or Scrum Really Mean?

A couple of years ago I posted about “process labels” and why I don’t think they matter. I suppose you could interpret “labels” as “brand” and you can call those brands Scrum, Kanban, Lean or what-have-you.  I had a light-bulb moment (re-affirming moment?) tonight when Benjamin Mitchell articulated this statement when describing his interpretation of “Lean”:

I have learned to think in my own context”  Of course he admitted that the marketing of that term isn’t so great when you’re a consultant, however, the heart of that statement is what really matters over trying to put a label on what process discipline you’re using.

What I’ve seemed to notice more is that people inside the “community” (whether that be agile, lean, scrum or whatever) spend a great deal of time trying to refine their brands and labels and I am wondering if people outside these communities really care about (or even understand) the brand or label.  We in the community make assumptions about how our customers feel about our brand and worry about language, marketing and other stuff that sounds an aweful lot like making product decisions from an ivory tower without getting fast feedback from our customers to me.

Let me  explain that a bit more.

Organizations may look to “Agile” to help them with a problem.  They might not understand the problem, but they know enough to know that they want or need something to change.  So people in the organization will talk to colleagues or friends or other industry people they know.  These people they talk to may say things like “hey, we started Agile-ing a couple of years ago and wow, the magic I tells ya! We started Scrumming our products and holy cow is it awesome!”  Ok, maybe that was not exactly how the conversation would go, but I think you get the idea.  The organization looking for help sees that a certain process worked in another company from a trusted source of information so naturally, it’ll work for them.

So this organization will start doing Scrum.  Then they’ll realize it didn’t work, or at least it didn’t get them the outcomes they thought it would.  Then they’ll wonder if they’re doing Scrum right.  Then they’ll find out they are doing Scrum-but.  Then they’ll be confused.  All the while the focus has shifted from trying to figure out why they needed to change something and the focus will be put on how to execute the process (in this case Scrum) the right way so it’ll work.

They may try Kanban and see how that goes or they may try Lean or Crystal or <insert process here> or they may chose to just give up and go back to the status quo or do nothing.

I am going to tell you the only guaranteed, sure-fire way to get better results within your business.

  1. Start trolling the Yahoo or Google message boards of various process disciplines.  Linked In is a good place to start too. Post thoughts about your problems and get some free advice.
  2. Filter that information and decide on which process discipline makes the most sense to start with
  3. Get involved in that process discipline’s community.  That means find local user groups, go to conferences and spend some time and effort to make a well-informed choice.  Of course balance how long it takes to make the choice.  Chances are you’ll get analysis paralysis if you spend too much time.
  4. Hire a consultant (and I’m not one anymore so I’m not plugging myself!)
  5. Give’er!  Get started while understanding that the focus is NOT on the process but instead the outcomes you expect to get.  Use what you learned in the first 3 steps to teach yourself and your organization how to learn within your context.

While I did use numbering for these steps, they’re not really linear.  My point is, educate yourself through the massive amounts of information and channels before you decide to make a change.  Understand what problems you think you’re trying to solve, understand there’s probably more problems than you originally imagined and gather information and feedback from various sources to help you make a more informed decision.

So for the amount of time and effort people within the community spend on defining brands and putting labels on processes, are our customers finding any value in that or are we just confusing them with a bunch of BS that doesn’t matter to them?  Are we the reason that focus seems to shift from solving business problems to following a process?

Seems simple to me, the organizations and people who are content with mediocrity will pursue quick fixes and focus on doing a <insert process discipline here> right.

The organizations and people that want to improve will actively seek out solutions and labels won’t matter to them.  They ‘ll look at multiple process disciplines and they’ll get actively involved in one or many communities and they’ll learn how to think in their own context for how best to apply the right practice(s).

Learn how to think in your own context” – It doesn’t get much simpler than that.