Three Kanban Reminders

I seem to have had a number of conversations recently which have all had some common themes. The general pattern has been that someone wants to talk about Kanban and let me know how its not working for them in some way. When I enquire further, and dig into the background some more, I’ve found that there are generally 3 things missing or misunderstood.

  1. You still need discipline. I hear of teams who find traditional agile practices difficult, for various reasons, some which may be valid, and some which may not. They decide to drop those practices, which may or may not be due to a lack of discipline. Dropping those practices, and just keeping the board, does not mean they have a Kanban System. In fact, if the board doesn’t have WIP limits, its not really even a Kanban Board! Whether or not teams have the discipline to follow their original process, they do need to have the discipline to define their own process by creating explicit policies.
  2. You still need cadence. The most common instance of a dropped practice that I hear is that of the time-box. The complaint is then that the team loses their rhythm, and that they have nothing to give them short term focus. They lose their sense of capability. What they have done is gone from a tightly coupled metronomic cadence, to an asynchronous, random and imperceivable cadence. There is a middle ground of a loosely coupled, poly-rhythmic cadence which is more resilient to the nature of their work, yet provides an ability to sense. As described above, it takes discipline to define this cadence.
  3. You still need people. The last misconception is that a Kanban-based approach is removing people from the equation again by trying to simply optimise the current process. Personally, this is why I talk about increasing Potential as one of the impacts we want a Kanban System to have. The potential of a system – its ability to improve over time – is grounded in the human potential of the people who are a fundamental part of the system. Its the people, and their connections and collaborations, who are best placed to know how to change the system for the better now, and be able to continue to change the system as the landscape changes.

I believe that attendees at the recent Kanban Leadership Retreat in San Diego were having similar experiences and I saw on twitter that the phrase “there’s a lot of sh*t out there” was used! This is partly why I came up with the Kanban Thinking model. As I alluded to when I talked about Cargo Cult Kanban, the Kanban community is not copying Toyota’s Kanban implementation tool, but the thinking behind it. If you trying a Kanban-based approach and its not working, think about why, identify something to change, and run an experiment. See, its not really that different to Agile!

 

People and Process: Two Sides of the Same Coin

I wrote this short article for JAX Magazine, but it seems JAX doesn’t want to make it easy for people to access the content (you have to register to get a download link which only works once). So I’ve decided to post the article here as well. Its an evolution of some of my thinking that goes back to the new lean and agile picture I posted.

One of the value statements from the Agile Manifesto is “individuals and interactions over processes and tools”. This is often abbreviated to “people over process” with a common interpretation being that the human aspects of software development are the primary areas we should be focussing on for improvement. However, this is counter to the ideas of W. Edwards Deming, who said “a bad process will beat a good person every time”. Similarly, Don Reinertsen has said he prefers “people times process” because if either is zero, then the product is zero.

People and process are two sides of the same coin, both equally important in understanding how to improve capability to deliver valuable software.

People

This side of the coin is about taking a group of people, who form a team in order to develop a capability. Peter Senge wrote in ‘The Fifth Discipline’ that “the fundamental learning units in an organisation are working teams (people who need one another to produce an outcome)”. Creating teams in this way allows people to iteratively learn about the way that they work so that they can incrementally develop their capability in order to improve the outcomes that they produce.

This is the basis of all the popular Agile methods such as Scrum or Extreme Programming, which all recommend creating cross-functional and co-located teams, collaborating with high bandwidth communication. Thus, the people side suggests that forming outcome-focussed teams, rather than activity-focussed silos, will result in an improvement.

Process

This side of the coin is about taking a vision, which is developed into a product in order to deliver value. Mark Denne and Jane Cleland-Huang wrote in their book ‘Software by Numbers’ about “an ROI-informed approach to software development in which software is developed and delivered in carefully prioritized chunks of customer valued functionality”. Taking this approach means that a product will maximise its value through being iteratively refined piece by piece in order to incrementally deliver functionality.

This is the basis of Lean approaches such as Kanban, which focuses on creating an explicit understanding of the process in order to learn how to deliver valuable pieces of software more effectively by modelling and visualising the work and associated policies. Concepts such as Minimal Marketable Features and User Stories help break down the work into smaller pieces. Thus, the process side suggests that continuously delivering small pieces of functionality with minimal delays, rather than waiting to release large batches of features, will result in an improvement.

People and Process

It is when we put these two sides together that we can achieve significant improvement. The iterative loops of learning about both the team and the product link into each other enable product value to rapidly flow through capability teams. This is the development nirvana we are trying to reach.

This model also gives some insight into why the “Waterfall” model, described by Winston Royce in his 1970 paper ‘Managing the Development of Large Software Systems’, has proved to be unsuccessful. It is not because the simple work-flow described was inherently wrong, but because the work-flow has typically been implemented with specialist silos rather than capability teams, and with large rather than small batches. It is both these two sides of the coin that should be the focus of learning and improvement in order to help us on our journey to the nirvana of product development flow.

Balanced Software Development

Agile2009 provided me with 3 sources of ideas which all complemented each other, and which I think make an important point that I want to repeat.

Firstly, on the flight over, I read John Shook’s blog post about his work with Starbucks. In it, he responds to the suggestion that by advising Starbucks on using Lean methods, he is transforming them into a robotic fast food joint like McDonalds. That suggestion sounds similarly like the common claim that Kanban transforms software development back into a robotic process. The piece that stood out for me was this:

Toyota combined old IE Scientific Management principles and techniques with social dimensions appropriate for the modern world. Even workers who do “manual labor” with their hands are knowledge workers. Front-line employees become the scientists.
By redefining roles, Toyota changed the answer to the question of who is the scientist in scientific management.

In other words, Scientific Management is still relevant for knowledge work, when the workers are the scientists. That keeps the balance between the Process and the People.

Secondly, Alistair Cockburn talked about three pillars of Effective Software Development in the 21st Century in his Agile2009 keynote. The 3 pillars are:

  • Cooperative Game
  • Craft
  • Lean Processes

Again, this to me demonstrated the need for a balance between the People and Process focussed elements.

Finally, I attended Jon Dahl’s talk on Aristotle and the Art of Software Development. This focussed on the differing ethical philosophies of Kant, and Mill and Aristotle:

  • Kant looked at the Acts, known as Deontology. This can be equated to looking at Process.
  • Mill looked at the Effect, known as Utilitarianism. This can be equated to looking at Outcome.
  • Aristotle looked a the Actor, known as Virtue. This can be equated to looking at the Participant.

Chatting with Matt Wynne after the talk, we both had the same thought. While individuals will probably sway to one form of these philosophies, there is room for all of them, and again, a balance is good. I would even go so far as mapping the three philosophies on to Alistair’s three pillars.

  • Deontology is Lean Processes
  • Utilitarianism is Craft
  • Virtue is the Cooperative Game

In many of the recent discussion I have seen and been involved in on Lean and Agile, and Kanban in particular, it seems to me that most of the debate is because the various participants are talking from the perspective of one of these pillars or philosophies. We should remember that they are all important, and that achieving the right balance is what is going to help us be successful in delivering valuable software.