software development

Kanban Board and Pull

These are my thoughts on Lean systems from a pull perspective, and how Kanban Boards can be used to facilitate a pull instead of a push system in software development. I don’t go into the pros and cons of pull systems in software development.

Imaging you want to order a  new from Toyota. In a push system, Toyota would try anticipate customer demand, and would produce a certain number of cars per period. These cars would then sit in a lot somewhere until they’re sold. This is wasteful. In the ideal, what should happen is that your order gets passed down the line, through successive levels in the business until the order is fulfilled. It should look something like this: The sales person passes on the order to the manufacturing plant;  the order is directed to the appropriate manufacturing line (car model) etc etc until it gets to the person making the wheels, doors etc for the car (including the suppliers).

This can be illustrated by the following conversations:

Me: “Salesperson, I want a 1.6 liter Corolla!”
Saleperson: “Factory, we need a new Corolla for this customer!”
Factory foreman: “Corolla line, we need a car with these specs for this customer!”
Corolla Line Manager: “Engine supplier, we need a new 1.6 liter engine for this car!”

Engine Supplier: “Corolla Line Manager, here’s that engine you asked for!”
Corolla Line Manager: “Factory foreman, here’s that car  you asked for!”
Factory Foreman: “Salesperson, here’s that Corolla you asked for!”
Salesperson: “Customer, here’s your car!”

Each lower level in the process is only asked for something when there is a need. It is obvious that the conversation at a specific level cannot be ‘returned’ until it is satisfied. That is, a car cannot be produced without an engine. Note also the symmetrical nature of this series of  conversations, it starts and ends with the customer.

What does not happen is that there is a pile of engines, gearboxes, doors etc waiting around to be used when an order comes through. (Obviously there may be lead times associated with each part, but this can be handled with Kanban and order points). The process to create each item is triggered or initiated only when there is a firm requirement for that part to be made. Parts are created just-in-time (JIT), only created when they are needed (and delivered to where they are needed).

The same process should be followed in software development. The conversation might be something like this:

Business (our customer): “Deployment team, give me this feature I want!”
Deployment team: “Quality assurance team, give me this feature to deploy!”
QA team: “Development, give me this feature to test!”
Development: “Business analysts, specify this feature for me to develop!”
BAs: “Business, explain this feature to me so I can specify it!”
Business thinks about it then, Business: “BAs, it needs to do this and this and  that!”
BAs specify it then, BAs: “Development, here is your specification to develop off of!”
Development develops the feature then: “QA, here is the feature to test!”
QA test then, QA: “Deployment team, here is the artifact to deploy!”
Deployment deployes then, Deployment: “Business, here is your feature in the live system!”

Each team in the process only does work if there is a request from the downstream team. The downstream team is notified when the work item is ready for their attention. If there is no request from the downstream team, no work happens. If there is a request from a downstream team, and no work needs to be done to fulfil this request, then it is simply moved downstream, and started on its return conversation journey. (If this case seems cryptic, I will explain it more in a later post.)

The term ‘Kanban’ has become invested with the meaning of a ‘visual trigger for action’. A task board becomes a Kanban board only when task cards signify some action, otherwise it serves only the purpose of tracking where in the process a task is. The typical trigger for action is the return path in the conversation above, something like: “QA, here is that feature for you to test!”. This is manifest by a developer moving a task card into the ‘Done’ or ‘Waiting for QA’ column on the task board. This is a visual trigger for someone in the QA team to pull this task into their personal queue. This can further be improved by imposing work-in-progress limits for each resource at each stage in the process.

The following occurred to me while writing this post:

At the moment, I don’t know if the forward conversation should be represented on a Kanban board, and if so, how. Perhaps with a different coloured card. I think it might add value to track this forward conversation, since it could still serve as a trigger for action. As in the case with the car and engine, a QA engineer can test a feature until it has been developed by a developers. Similarly, a developer cannot begin development on a feature until it has been specified by a BA. Perhaps it is necessary to represent this on the Kanban board. I.e. a visual trigger to a BA that he needs to do some work.

This could be achieved by having a ‘reverse’ stream on a Kanban board, representing the forward conversation. Thus, when QA is asked to present a feature to give to the deployment team to deploy, QA should put a card in the ‘waiting for development’ column on the board. This card is then passed upstream in the process until the first stage in the process (business in our case) fulfils it, then starts passing it back downstream. This could be used to discover bottlenecks in the upstream direction. I.e. our developers are sitting idle because the BAs cannot develop specification fast enough.

This can be discovered on a ‘normal’ Kanban board by the ‘to do’ column for development remaining empty for some time. Perhaps then the absence of work items in the ‘to do’ column for any stage indicates a bottleneck in the stage before.

Advertisements

8 thoughts on “Kanban Board and Pull

  1. Hi Joshua,

    Thanks for pointing me to your interesting take on the topic of visualizing pull on my blog entry about this (http://lindelauf.com/?p=60). I like your example of a very clean approach to the theoretical pull-driven conversation in software development. However, in practice, I think the first real optimization is that the deployment team does not do the “order taking”; that would be the business analyst. Just as the truck driver delivering the Toyota to the garage would not take the order for the next one; instead, there would be an order taking department to do that.

    From that perspective, the kanban board can remain the simple one-directional board it is now. You could choose to reverse it, like I suggested, depending on the type of pull you’d like to emphasize. That’s what I really like about the other blog post you pointed me to (http://kallokain.blogspot.com/2009/06/defining-kanban.html), where Henrik distinguishes between work-in-progress kanban and withdrawal kanban: in essence a kanban board has to be clearly labeled to say which of these types it represents. At least, when you’re telling the team the whole lean/kanban story, it helps to reduce the confusion, I think.

    As for introducing another type of card to visualize the opposite flow: I think that’s making things overcomplicated. It’s a nice theoretical exercise, but most team members could care less about this addition and would frown on the extra administrative overhead.

    Thanks for the great insights and pointers!

    Pascal.

    1. Hi Pascal,
      no worries on the pointers.
      For me, the withdrawal Kanban could be used like this ‘I have this card, this entitles me to ask for more work’. This could work nicely at the edge of the value stream, for example a BA asking the customer for the next feature. It’s a proof that there is capacity in the system. I.e. the customer should ‘push’ more work unless he has been presented with a withdrawal Kanban. It just seems to make the ‘pull’ nature of the system more explicit.

      A thought that occurs to me is that the total number of withdrawal Kanban ‘collected’ at the beginning of the value stream in a given period could be a useful metric in terms of trending capacity. For example we could say ‘we had 30 total withdrawal Kanbans (i.e. available capacity slots) in the past month, over a team of 10 people’. Does that tell us anything?

    2. I think to take the idea even further, the withdrawal Kanban could be a ‘ticket to do work’ at every stage in the value stream.

      If we follow the ‘forward’ and ‘reverse’ conversations above, when the customer asks the deployment team to deploy a feature, the ‘message’ or request could be in the form of a withdrawal Kanban. The customer wants some work to happen. This withdrawal Kanban then gets handed down along the stream.

      This withdrawal Kanban should trigger work entering the value stream. I.e., nothing should enter the value stream unless there’s an explicit request. Again, this is just making the pull nature of the system more explicit.

      In one of my earlier posts, I propose that TDD is a pull system. Would you agree that a failing test is a withdrawal Kanban?

  2. As for the failing test: one could indeed argue that the request to fix a failing test, is a withdrawal kanban. But I would not see it that way for tests written by a developer himself (as done in TDD), but rather for tests that transcend disciplines (e.g. functional tests / acceptance tests).

    As for the withdrawal kanban coming downstream from the customer, first to the deployment team and then further: I feel that’s a bit too theoretical to justify the need for a separate kanban type on one board.

    Actually, I think this is how practice maps best onto kanban:
    * business asks for a specific functional “theme” (=set of related user stories) to be developed, by handing the request to the product owner
    * product owner partitions the theme into separate user stories and requests them to be developed by the team
    * team develops and tests the user stories and requests the (in-team) testers to test them
    * testers test stories; if incorrect, a fix is requested from the developers; otherwise a deployment is requested
    * deployers wait for all the user stories to arrive before they are assembled into the release representing the requested functional “theme”
    * when deployment has taken place, the deployment team hands the requested user stories back to the product owner (=release notes)
    * the product owner hands the requested “theme” back to the business, thereby handing them back the withdrawal kanban for themes, allowing them to request the next functional “theme” to be delivered

    Note, the product owner will be the one in contact with the business, since from a business perspective, the functional delivery of the product (from the product owner) is more important than the technical delivery (by the deployment team), even though the latter is mandatory for the first.

    Actually, come to think of it, the passing of withdrawal kanbans is all about passing around responsibility. The business hands the responsibility of the creation of a functional theme to the product owner. The product owner hands the responsibility further down to *both* the dev/testteam and the deployment team. Note word *both*, with which I imply that the there is no further depth of responsibility below the level of the product owner: the deployment team and dev/test team all have their own separate responsibility. If the deployment team would actually be responsible for the delivery of the test team, and the test team for the delivery of the development team, then withdrawal kanbans would go deeper along this route (according to your example). But this is never the case in (agile) software development, since it would create far too much distance between the developers and the business.

    Hmmm… that’s a new insight for myself. This might well be basic kanban knowledge (which I desperately need to read up on) or maybe I’m missing the point completely. But I feel this makes a bit more sense to me now. What do you think?

    1. The reason I wrote about the whole forward and reverse streams, and the reason for your blog post (I think) is because of the difficulty in seeing the ‘pull’ in those systems. In your scenario above, I have difficulty in seeing the pull. How does the business pull value from the delivery team?

      For me, the ‘pull’ comes in when there’s a need to do work – we only do work when there’s a need. This begs the question, how do we know then there’s a need? How do we represent that need? In my original post, we know there’s a need because the product owner has asked for something to be deployed. This request bubbles down the line until work starts being performed at the beginning of the stream. Today I proposed using explicit withdrawal Kanban to represent the need.

      If you look at it from a TDD point of view, if the customer asks for something to be deployed, and magically the feature already exists, then no more work needs to happen, and the withdrawal Kanban does not get passed down the line. I.e., if all your tests pass, stop writing code.

      This also boils down to the question of ‘how do we add value’ (or ‘what is our goal’ if you’re into Theory of Constraints). We add value only when we deliver (deploy) software to the customer. That’s why I started off the process with the customer asking for something to be delivered. This also fits in with what you say about the (real) customer only caring about ‘functional deployments’. As a customer, I don’t care how it gets done. All I want is something to be delivered, so that’s what I ask for. How that request turns into real software should not be my concern as the customer. I just want to ‘pull’ value from the system.

      I agree with you about responsibility and roles in a ‘proper’ cross-functional delivery team. However the use of a Kanban boards does not proscribe cross-functional teams, or any structure 🙂 That’s part of its power.

      I would even argue that Kanban boards imply, to some extent, some type of Waterfall (sequential) process.

      Personally, I agree with you about team structure and ‘sequencing’ of work. My belief is that design cannot be a sequential process, and that there shouldn’t necessarily be a hand-off of work between people in an organisation. The team should as a whole be responsible for the work, in totality. I’m still struggling with the implications of this in terms of idle time etc.

      1. Hey Joshua,

        I’m with you. Cross functional should always be preferred above waterfall. And I indeed sometimes wonder, when I see kanban/story boards evolve after each retrospective, why they become more sequential / “waterfally”. 🙂

        As for your question: “How does the business pull value from the delivery team?”. Well, the business is not interested in the fact that there’s a delivery team. The business pulls value from the software development department, which internally has a product owner (taking the “orders”) and a delivery/deployment team (delivering the “orders”).

        Actually, in your initial Toyota example, you illustrate the same thing. You don’t let the truck driver, whose delivering the new Toyota’s, take the new orders at the garage. Instead the “Toyota factory” is requested to fulfill an order for a new car, where the order taking department is the intaker and the truck driver is the deliverer.

        A question could be: does the order taking department first route the order through the transport department, and have them pass the order to the actual “car making” team to “pull a car”? In your car example they don’t. And I don’t think they do either.

        For software development, we can draw direct parallels between the product owner and the order taking department, and the transport department and the deployment team. So in that case, the process I sketched is still largely the actual value stream.

        Things do get interesting around the assembly of built stories into an actual deployment. Will the testers pull a deployed system from the deployment team, or will the development team deliver separate stories to the product owner and have the latter pull the actual “theme release” from the deployment team?

        Interesting topic.

        Cheers, Pascal.

  3. Ok, as I understand it, in the scenario you’re describing, there is some kind of ‘higher level’ coordinator role, which you’re assigning to the product manager (correct me if I’m wrong). In that scenario, I agree.

    However a ‘product owner’ is not a prescribed role for using a Kanban board, so I haven’t really used one in my thinking scenarios 🙂

    In any case, replace ‘customer’ with ‘product owner’. How does the product owner pull value?

    I think my scenario kind of falls down because the case of ‘there’s magically something we can deploy, so we don’t need to do any more work’ doesn’t really happen. I.e., there will *always* be development and testing work. (Although it might be possible that there isn’t analysis work?)

    Again, I’m just trying to highlight a pull system, and some of the attendant advantages. Also, all my thinking goes to supporting the notion that we add value by delivering software only. Therefore the only reason to do analysis/development/testing work is to deliver software.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s