Software Engineering Research in Product Development Flow


Good research is critical to building the body of knowledge of software engineering, and understanding the principles on which our industry is built. Even more, without the solid foundation of theory that comes from research, it is difficult to scale the practices we use in industry beyond a limited context. Lero, the Irish Software Engineering Research Centre, hosted an Industry Research Day today, to highlight and share some of the great software engineering research work that goes on at the Centre.

There are some great talks from partner companies including IBM, Intel, and St. James’s Hospital, Dublin. There are keynotes by Máire Geoghegan-Quinn, the current European European Commissioner for Research, Innovation and Science, and Seán Sherlock, the current Minister of State for Research and Innovation. It is great to see the richness and variety of software engineering research going on in Ireland, and the support available at both an EU and national government level.

My talk is a short summary of my ongoing PhD research work. I talk about learning and feedback cycles, learning to see impediments to flow, and some examples of how to see impediments in your team and organisation. I also talked about some preliminary research results, including how to tell who is really influencing flow and impediments in your organisation, what reaction time can tell us about threats and opportunities, and how to empower teams and engage management through an impediment removal process.

Slides from my talk are available here:

Portfolio Management and Organization Flow

I’ll be speaking at RallyON Europe this September on the topic of Portfolio Management and Organization Flow.

Complexity of product development increases as we move from a single team or product focus to a cross-organisation portfolio focus. Organisation Flow is about achieving the Lean concept of flow at an organisation level, not just at the level of a single product or product line.

This session will look at an approach to portfolio backlog management, and describe how to manage the flow of work through a portfolio of multiple products delivered by 50 teams in 6 locations across the US, Europe, India and China.

We will include examples of some core metrics that help understand throughput and flow in the organisation. These metrics tell a story about what is happening in the organisation. Lessons from these stories include understanding impediments to flow, and understanding who and what in the organisation is influencing flow.

I did an interview last week with Hannah Shain from Rally. The recording from the interview is here:

There’s a great lineup of content for the conference. If you’re in London I hope to see you there!

Update: Here is the slide deck I used at the conference:

Lean Startup in Large Organizations

I gave a talk today at a Lean Startup event organized by Enterprise Ireland and ITAG.

The topic of my talk was Lean Startup in large organizations, and specifically talking about lessons learned from applying Lean Product Development and Lean Startup principles at Cisco.

The three specific lessons I talked about are:

  1. Learning to manage batch sizes and limit Work in Process (WIP)
  2. Customer Development
  3. Learning to see and manage waste

The slide deck is available via Slideshare:

Lean Systems Society

Lean Systems Society

As of May 2012, the Lean Software and Systems Society has officially re-branded as the Lean Systems Society. As part of the launch, a number of founding Fellows have been named. I am honored and delighted to have been invited to be a founding Fellow of the Lean Systems Society.


The purpose of the Lean Systems Society is:

to improve the world by improving its systems. The Society organization will be modeled on the United Kingdom’s Royal Society and its “Fellowship of the world’s most eminent scientists.” The Royal Society was created to actively encourage thought leadership in the sciences by honoring original thinkers as Fellows, and encouraging their collaboration and debate. It has succeeded in this mission for over 300 years, and is an ideal model to emulate.

The Lean Systems Society Credo

From the Lean Systems Society Web site:

The Lean Systems Society believes that excellence in managing complexity requires accepting that complexity and uncertainty are natural to social systems and knowledge work. Effective systems must produce both better economic and sociological outcomes. Their development requires a holistic approach that incorporates the human condition. The Society is committed to exploring valuable ideas from all disciplines, and fostering a community that derives solutions from a common set of values and principles, while embracing specific context and avoiding dogma.

Fellowship of the Lean Systems Society

You can see the full list of current LSS Fellows at the LSS site. As of May 2012, the founding fellows are:

David J. Anderson Jeff Anderson Markus Andrezak
Jim Benson Barry Boehm Bjarte Bognes
Bob Charette Alan Chedalawada Steve Denning
Israel Gat Hillel Glazer Siddharta Govindaraj
Russell Healy Chris Hefley Richard Hensley
Curtis Hibbs Kenji Hiranabe Greg Howell
David Joyce Michael Kennedy Liz Keogh
Corey Ladas Janice Linden-Reed Hal Macomber
Ryan Martens Peter Middleton Benjamin Mitchell
Frode Odegard Greg Parnell Ken Power ( me!! 🙂 )
Don Reinertsen Chet Richards Karl Scotland
Alan Shalloway Sarah Sheard Chris Shinkle
David Snowden James Sutton Jean Tabaka
Richard Turner Alisson Vale Yuval Yeret
Greg Yezersky Jason Yip

The Fellowship was officially launched at the LSSC 2012 conference in Boston.

Press Releases

The official Lean Systems Society press release can be found here. There are additional press releases on Yahoo News, InfoQ and others.

Looking to the Future

I’m looking forward to continuing to contribute in whatever way I can to the Lean community, and to helping the Lean Systems Society to grow and flourish. The Society’s purpose of “improving the world by improving its systems” is a stirring and timely call to action for all of us.

Enjoy a Lean Coffee

What is Lean Coffee?

Jim Benson and Jeremy Lightsmith founded the Lean Coffee movement in Seattle in 2009. Since then, Lean Coffee events have sprung up around the world. The basic idea is for a group of people to get together to discuss topics around which they share a common interest, specifically around agile, lean, kanban, lean startup, etc. There is also an OpenCoffee movement, founded by Saul Klein in 2007. The intent behind OpenCoffee is to provide an open forum for investors, entrepreneurs and developers to come together, meet, discuss ideas, and find opportunities to work together.

The Lean Coffee format is essentially an approach to facilitating learning and collaboration through group discussions. The ‘Lean’ part of the name has its roots in Lean Thinking, and related areas of Lean Production, Lean Software, Lean Startup, etc. The ‘Coffee’ part of the name obviously comes from that nice drink that some of us are partial to. Meetups typically take place in the morning, at a local coffee house, at the same time and place each week.

Lean Coffee events are increasingly becoming a fixture at many conferences, in a similar way that Open Space has. We had a great Lean Coffee event at LESS2011 in Stockholm last year.

How it works

The Lean Coffee format has a lot in common with Open Space, particularly in the sense that you are asking people to move away from an agenda-driven gathering to a more open, collaborative, dynamic, emergent type of gathering.

The protocol, borrowed and modified from the Sydney Lean Coffee group and Limited WIP Society, is as follows:

  1. Everyone offers topics they are interested in discussing by writing them on index cards (or sticky notes).
  2. Everyone presents his or her topic as an Elevator Pitch (max 1 minute per topic).
  3. Use dot voting to vote on each of the topics.  Each person gets two votes. You can only vote once per topic.
  4. Prepare three columns on a table or wall. Call them “Planned”, “In Progress” and “Done”. Add all topics to the “Planned” column, with those that received the highest votes at the top.
  5. Discuss each topic in turn. Move the index card for the topic into the “In Progress” column. Initially, ask the proposer to explain the topic, then go round the table to give an opportunity for everyone to provide an initial comment, then open discussion.
  6. When the topic is done, move on to the next one.  The topic proposer decides when the topic is done, and moves the index card to the “Done” column.  If someone disagrees, then s/he can raise a new topic.  Expect to discuss 3-4 topics over the space of an hour or so.
  7. Consider time boxing each topic to 15 minutes max.
  8. At the end of the overall Lean Coffee session, run a quick retrospective.  What did you like? What didn’t you like? What are ideas for improvement?

As a variation, particularly if you have a large group, consider splitting into sub-groups if people are particularly passionate about specific topics. Then get back together after the topic discussion to present highlights to, and get feedback from, the wider group.

Lean Coffee at work

The idea and format for Lean Coffee is very simple and effective. It can be used in work too. For example, consider hosting a Lean Coffee event every week in your office. It can be a great way to share experiences and challenges across teams and gather interested people who don’t normally get to discuss these topics together.

If you find your retrospectives are becoming routine, then this is a good way to break out of the rut. There is no leader or facilitator required. The team can self-organize a Lean Coffee style event without any preparation. The team decides which topics to discuss, and how long to spend on each topic.

The only prerequisites are a set of index cards or sticky notes, a set of Sharpies, and some interested and willing people.


Some sites for Lean Coffee Meetups around the world:

Writings about Lean Coffee

Refactoring the Organization Design – LESS2010

I was invited to speak at the First International Conference on Lean Enterprise Software and Systems, 2010, in Helsinki last week. I presented on the topic of organization change in engineering organisations, as part of the Scaling Agile to Lead track.

The main theme of my talk was in support of applying concepts from Stakeholder Management to support agile and lean adoption. I used the concept of refactoring to talk about some of the changes that can be made to organizations, and showed some examples of how Martin Fowler’s classic Refactorings can be re-purposed to talk about organization design rather than software design.

The main topics of my talk were:

  • Using Dan Pink’s Motivation 3.0 Type-I toolkit for intrinsic motivation as a guide for what we should be refactoring towards
  • Refactoring applied to Organization Design
  • Agile transition journeys
  • Designing a process: core framework versus toolbox
  • Refactoring toolshed
  • Stakeholder Management
  • Stakeholder Mapping applied to Scrum teams
  • Stakeholder Management and the challenges of Product Ownership for large organizations
  • Stakeholder Management and the role of manager
  • Stakeholder engagement
  • The power of metaphors for organizational learning
  • Jazz improvisation as a metaphor for organizational learning and stakeholder engagement
  • Artful Making as a metaphor for software development and stakeholder engagement
  • Organization Patterns

Paper Abstract

The following is from the abstract of my paper that was published in the conference proceedings:

Every organization has a design. As an organization grows, that design evolves. A decision to embrace agile and lean methods can expose weaknesses in the design. The concept of refactoring as applied to software design helps to improve the overall structure of the product or system. Principles of refactoring can also be applied to organization design. As with software design, the design of our organization can benefit from deliberate improvement efforts, but those efforts must have a purpose, and must serve the broad community of stakeholders that affect, or are affected by, the organization. Refactoring to agile and lean organizations demands that we have a shared vision of what the refactoring needs to achieve, and that we optimize the organization around the people doing the work.

The full conference proceedings are available form Springer.

Presentation slides

My presentation slides are here: