Does Agile use Kanban?

A friend recently asked the question ‘Do you have to have similar sized stories in order to make Kanban work in Agile?’  This prompted my response to his question:

“Kanban, as implemented in Lean Manufacturing, is part of a ‘pull’ system. In an ideal pull system when a unit is sold a signal is sent within the pull system to indicate that the system needs to manufacture the unit that has been sold. Often this signal is in the form of a card on a wall or billboard. (’Kanban’ in Japanese actually means ‘billboard’.) More often though, a Kanban system is used to trigger replenishing inventory when inventory in the workflow gets to be too low for the step in the workflow that is consuming the inventory.

“The use of Kanban in Agile really isn’t a pull system though. In Agile, the Agile Wall is used to indicate work that is available but the work is pushed through the system and is waiting to be pulled by the next step in the workflow when they have cycles available to do the work. (The key word there is ‘waiting’ to be pulled.) So, although people pull work from the Agile Wall, the work was pushed onto the wall from the previous step in the workflow.

“A better approach to keeping the system optimized is to not worry about keeping the size of the stories the same in order to keep the flow even, but rather use Theory of Constraints to make sure that the constraint in the system is never starved. Doing anything more than that has little effect on throughput so considering story size becomes a moot point.”

It’s great that the Agile community is embracing the fundamentals of Lean.  Eliminating waste and reducing unevenness and overburden are consistent with the tenets of Agile.  We just need to be careful in embracing terms and not really knowing what they mean or how they relate to what we do in software development.

Evil Rob’s Photography and Coding Skills

Good morning Rob.

Since we talked on the train I wanted understand better why your photographs are so good, so compelling. So I went to your Flickr account through evilrob.org to check them out again.

It’s easy for me to recognize things in your pictures that I am pretty good at – framing a scene or cropping to make the composition a little more interesting. But I realized last night that your mastery of lighting is a skill that I don’t have and that is why I have not able to articulate well what I find so compelling in your photographs.

You do a great job in managing the depth of field in your photos, something that I am mindful of when I take photos but I don’t really have a mastery of yet, but I realize now that your considering the lighting in photography has you think in dimensions beyond depth of field. You are considering multiple dimensions as you work with your multiple light sources or as you manipulate your subject within your available light.

I your ability to think in multiple dimension is also what makes you a great developer. It’s the same skill set. You have the ability to solve an immediate problem in the context of a bigger business application within its emerging architecture in a way that will be maintainable and testable and adds the most business value with the least amount of code.

Great stuff Rob – both the photography and your coding.

And thanks for the new blog on Business Analysis. I’m going to share it with my colleagues at Tacit.

Tom

Nuggets of Wisdom From The Cluetrain Manifesto

Fellow Tacit Passengers on the Cluetrain Manifesto Express:

So I am working my way through Cluetrain this weekend hoping to complete it before our discussion group on Tuesday and I am kind of having a hard time hanging in there with the book as it goes through some dry spells. But them WHAMMO! a great section or nugget of truth will really jump out at me. Last night it was this passage from pages 129-130:

“We often assume that complex projects can only be accomplished through centralized planning and control. It worked for building the Hoover Dam, after all. Not to mention World War II.
“But of course, in only works for some types of wars in some types of places. And the builders of the Hoover Dam aimed at creating a massive physical object with delicate dependencies so that there was only one way to succeed and many ways to fail.”

The light bulb come on! That’s it! This is why do so many people in the software development business, especially architects, continue to manage by command and control. They believe that there is only one way to succeed in building an application – THEIR WAY. But with software development there are MANY ways to succeed (and of course still many ways to fail).
This insight gives me a way to help determine if waterfall or agile is appropriate for a project. Yes, I believe that there are situations where waterfall is appropriate. So the question becomes: am I faced with initial constraints that dictates details of the solution or can that solution emerge? And if I am faced with these kinds of constraints, are they the preferences, styles, latest fads or bigotry of an architect or manager, or are they real constraints?

I’m going back to reading now…thanks for listening!

Tom

How a constraint can move within a software development system

Below is a link to a good article from the folks at Net Objectives regarding Agile and Theory of Constraints that I came across this morning. It talks about what I have seen recently on a project on how the constraint can quickly move to another part of the software development system.

http://www.netobjectives.com/blogs/comment-on-TOC

In the example I give below the constraint has moved from developers to BAs as we have optimized our coding teams. It’s important to recognize how we optimized the development effort and specifically how this has moved the constraint onto the BAs. The bottom line is this:

On our project, by optimizing our coding efforts we are getting to the hard details, the details that are not captured in the client’s requirements document, much faster than we were before.

How have we gone about doing this?

1. We are actively reducing the number of story cards in play

A developer should not have more than one card in play. We tend to let a developer take on another card because they are blocked, often because of requirements questions. By only letting a developer have one card in play at a time it will force the developer to deal with the hard stuff right away and not put it off until later. This requires an immediate conversation with the BA to work out the details.

2. We are forcing the focus of our development efforts back onto story cards rather than tasks

We want to keep the development cycles on story cards as short as possible. To do this we are centering our daily standup around story cards rather than each developer’s status. This helps us identify when a story is taking longer than expected. What we are finding is that a story is taking longer because of requirements issues which requires a BA to resolve.

3. We are optimizing the whole development team through greater collaboration between UI and Services Teams

Once again, the optimization of the whole development team allows us to get to the hard details sooner, specifically, the details of the interfaces between UI and Services. These details only get identified and sorted out through coding both sides of the api at the same time, not documenting them. And we are not just talking about api signatures, but the edge cases that are frequently not identified in a requirements document that require conversations with a BA to resolve.

As you can see, all this requires that a BA be available to developers to keep them from becoming idle or inefficient. This becomes a point of contention for the BA’s time if they are given a mandate to complete a set of documentation well ahead of the developers need for the documentation. Management needs to align their expectations of BAs to provide Just In Time requirements.

Project Retrospectives

I’ve been doing retrospectives as part of my role as an Agile Project Manager and Agile Coach for several years now. In doing so I have found myself leading retrospectives in the following types of situations:

• I am a member of the development team
• I am not a member of the development team but I know the project, the team and the domain
• I don’t know the project team but I do know the domain
• I don’t know the project team and I don’t know the domain

I have had varying degrees of success in doing retrospectives and they relate closely to the above list. My most effective retrospectives have been with projects where I am not a member of the development but I know the domain. (By domain I mean something like eCommerce, Public Safety etc.) Here’s why I see that I have or have not had success:

• If I am a member of the project team I bring my own agenda to the retrospective and I am less likely to let the content of the retrospective unfold from others
• If I don’t know the domain well too much time in the retrospective is spent teaching me what the team is attempting to accomplish
• If I know the domain I can ask better questions, not because I know the answers but because I know what is most likely important

One other thing I have taken notice of lately is how I feel before going into a retrospective. It seems that how I am feeling often aligns with the effectiveness of the retrospective. For example, if I am confident going into a retrospective it is often because I have prepared MY agenda for the retrospective. These retrospectives often don’t have people participating as much as I would like them to.

In contrast, prior to some retrospectives I am a little nervous. This is usually for projects where I know the domain but I don’t know the project team. I get nervous because I am about to venture into the unknown. I know the domain so I can ask good questions but I don’t know what might come up in the meeting. These tend to be the most effective retrospectives that I have lead. I am not over-confident. I am focused on drawing out of others how they are feeling rather than telling them what I think they need to hear.

Finally, there are retrospectives where going in I am absolutely terrified. These are retrospectives where I don’t know the people/project and I don’t know the domain. What am I doing here! What can I do to help these people? I have learned some facilitation skills that can help me in these situations but I feel more like a referee rather than a leader.