Rediscovering the Obvious : Kanban, ProjectExecution

The relationship between Agile and Lean – one man’s perspective

willeke — Tue, 06 Oct 2009 11:58:00 GMT

This is a copy of a post I wrote to leanagile on 6 Oct, 2009. I have copied it here because I feel that it explains my perspective well.

One of the things that has caused me to embrace both Agile and Lean is that they are not closed systems. Each of them (explicitly, I believe) recognizes the need for learning and self-redefinition. As such, I tend to assume that each of them has already absorbed the best of what the other has to offer. In many cases, the two were saying the same thing using different names. In other cases, one or both holds something to be an underlying assumption (I'm thinking the role of People ) that doesn't get spoken of much, and causes confusion. The primary discussion point of value to me is in understanding how to more properly utilize the thinking patterns coming from both sources. In Lean, I find great value in the attempts to provide a scientific basis for why things work, giving me mental models to help understand future situations. Others perceive this same aspect as a negative, dehumanizing, theorist perspective. I respect that view, even though I don't agree with it.

I personally perceive that Scrum as a framework has been defined as a closed system. This turned me off on it for a long while until I see people like Tobias Mayer at work... now I question my understanding... thank you Tobias.

I personally perceive that Kanban as a framework has been defined as an open system, but is at risk of being turned into a closed system. I do not wish to see this happen.

Regarding the CAS [1] aspects of this thread:
I believe it is an incredibly valuable systems-thinking tool and perspective to evaluate what happened in a situation. As such, I believe it is also a valuable tool to predict what may happen in future situations. This puts it in the same bucket as lean, agile, and many of the other tools at our disposal. I wouldn't "Go CAS" any more than I would "Go Lean" or "Go Agile", but I will happily add them to the set of lenses I use to understand and inspire in a given situation.

I hope this perspective helps, or at inspires a bit of thought.

[1] The thread had a deep discussion of the role Complex Adaptive Systems theory could play in Lean transformations.

Shu Ha Ri for Kanban systems

willeke — Sun, 06 Sep 2009 16:13:21 GMT

Context

A recent discussion on the kanbandev list interested me because it really brought a focus on what we mean when we say “kanban”.

First, David Anderson posted:

On Fri, Sep 4, 2009 at 2:35 PM, netherby_uk wrote:

(#1) kanban (small k) - meaning signal card - original literal meaning is closer to "shingle" (in American), usage "to hang out your shingle". Signal cards (kanban) are used to facilitate self-organization on a shop floor. With the correct policies they can be used to enable a pull system.

(#2) virtual kanban pull system (small k), generally shortened to "kanban" for convenience - the tool, mechanism of method of using kanban (signal cards) to implement a full pull system in a value-stream. In most of the Taiichi Ohno quotes he is using "kanban" in this sense. Note this includes visualization. Generally speaking the visualizations are not the kanban(#1) but representations of the actual work as knowledge work is invisible.

(#3) Kanban (large k), a method for change management (in software engineering and knowledge work), an enabler of a Kaizen (continuous improvement) culture and process. To do continuous improvement there is a need to incorporate a number of bodies of knowledge including the full suite of Lean thinking, Theory of Constraints, Deming's Theory of Profound Knowledge, Risk Management / Option Theory, and more will doubtless be added to this list.

After some discussion, Joakim Sundén added:

On Sat, Sep 5, 2009 at 7:27 AM, Joakim Sundén wrote:

1. Kanban (or Kanban Boards) as visualization of project status that helps teams to make work self-directing. This seems to have been Kenji Hiranabes and Poppendiecks early application/understanding of kanban, see e.g. Hiranabes 2007 InfoQ article "Visualizing Agile Projects using Kanban Boards" or Poppendiecks "Implementing Lean Software Development". It is all about visualization and there is no notion of limiting WIP etc. Speaking to Hiranabe and other agile japanese developers on a study tour in Japan this spring most of them referred to kanban in this meaning although some, e.g. Hiranabe, were aware of the other meanings as well.

2. Kanban as a tool. Includes the definition above and extends it with mechanisms as pull and limiting WIP. It can be used with agile methods as well as with waterfall approaches. People who use this definition seem to think of kanban as a tool particularly (and sometimes _only_) useful in software maintenance departments, e.g., where Scrum doesn't cut it because the constant emergencies ruins the sprint planning.

3. Kanban as an application of lean thinking to software development that is somewhat different to, but not necessarily in opposition to, Poppendiecks flavor of Lean Software Development.

Echoing what David wrote in a later post on this thread, I don't recognize Joakim’s #1 at all. In fact, when I speak I generally recognize it explicitly as an antipattern because of the pain and chaos it caused the team at Inkubook (as compared to both Scrum and WIP limited pull based systems).

David and Joakim somewhat share the same perspective for their respective #2 and #3’s, so i won’t distinguish between them from here forward. I have seen these 3-level splits before and I find them not working for me because I feel that they miss an important progression. Dividing them into explicit steps loses the important aspect of transitioning between them. I responded with a ShuHaRi perspective that I feel fits the real situation better.

Shu

I don't see what we're calling kanban as having any real Shu level components at the process level. I suppose working as a member on one of these teams could be considered a Shu level behavior as you learn and copy what your team is doing. A team attempting a kanban system on a Shu-level understanding will degenerate into cargo cult and likely failure. It certainly misses the opportunity to improve itself.

Ha

Ha is the entry point for most teams. You read a bunch of different people's approaches to how kanban is being done, and you take a shot at it based on the set of practices you know. You put up the visual control board, throw some WIP limits on it, and start managing your work that way. You find some success, and you try different practices that sound useful as they are discussed on the boards. Your level of success goes up and down as you try them, and you learn.

Ri

Ri behaviors emerge when you start feeling the need for changes and see the appropriate places to make the changes. This is very similar to David's original #3 at the top of the discussion, but without the explicit statement of the bodies of knowledge involved. I do pull from all of those areas David lists, but I also pull from adult education, hospital management (a special flavour of lean), NLP, software architecture, design & patterns, physical architecture, science fiction, military history, a study of politics, and anything else that inspires me to a better solution at the time. Thus, I argue with David's #3 on semantics, not on intent. The core goal is to "achieve continuous improvement through continual application of approaches and techniques from a variety of sources".

Ha->Ri is a process of continual improvement itself, and I suspect this is why I don't see #2 and #3 as different things... I see it as an axis of progression and learning on which #2 is the starting point and #3 is one of many possible futures.

Incredibly generic procress description

willeke — Fri, 03 Apr 2009 00:12:00 GMT

Excerpted from the first draft of my experience report for leankanbanconference.com:

Somebody has an idea to add value. Somebody approves the idea has merit, requests that it be built. Somebody transforms the idea into a set of specific changes that need to be made to the application from a user’s perspective. Somebody identifies how those changes need to relate to the existing technical implementation. Somebody causes chose changes to occur to the system. Somebody confirms that those changes were indeed made. Finally, somebody agrees that the changes did indeed provide the desired value.

It may not stick, but for the moment the incredible level of generic writing has a purpose in the document.

Continuous Integration - When and why?

willeke — Mon, 12 Jan 2009 16:53:00 GMT

Earlier today, on Twitter
Me: Having issues with the positioning of continuous integration vs branching models lately. Absence of latent code pattern description, mostly.
Scott: What are the issues?
Me: Mostly around cross-team/large product situations where the need for selective feature disabling may arise from QA finding
Scott: Tell us more.
Me: This blog post

Continuous Integration

I've always viewed the concept of continuous integration (CI) as a very good thing. I relentlessly persue the reduction of batch sizes until it doesn't make sense due to the transaction costs. I believe strongly in individual (pair?) developer discipline. I believe less strongly in a strong unit testing library and TDD, but view it as "usually a great thing". I believe in flexible designs capable of handling varied changes in short durations. All the things that enable cross team CI are things I believe strongly in following, but I just don't quite agree that it should be taken all the way.

On the kanbandev group on Yahoo! groups, there's an incredible conversation going on between Brad Appleton and Bas Vodde between how large development teams can work using CI techniques, and the crux of the discussion briefly converged on the question: "Can you have large integrated teams without using a branching model?" For the purposes they are discussing, I would happily say "Yes". However, I'm running into a different reason for branching: Providing options to management.

CI vs. Options

A branching model allows our developers to practice CI against a branch specific to their current Minimal Marketable Feature (MMF). Due to our frequent (average ~1.5 per week) releases to production, we have determined that we never want to have a partial MMF in production. Given a work in progress (WIP) limit of two MMF's in dev and three MMF-equivalents [1] in SQA, we tend to do a production release whenever SQA approves one of their three slots. Our branching model allows us to do a good job testing the MMF on its branch because we update the branch from the main line on a regular basis and definitely before we push to the test environment. This allows a quick smoke test after we merge the branch back to main rather than a massive regression effort. This model allows our management to make a decision about individual MMF's quality and determine which ones should be pulled into SQA (and thus for production). However, if an MMF happens to have poor quality, it is almost always found while the MMF is still on the branch, allowing its bugs to be worked and brought up to an appropriate quality while other MMF's are able to continue. I think this is similar to the Release Train model, but rather than be on a time interval, it's pull-based off of the SQA's output queue.

Option source: Branching vs. Latent Code?

There are other ways of accomplishing the same goals. Specific features can be enabled or disabled through configuration properties at either build or runtime. This is _probably_ the better pattern for most situations. The situation I'm encountering with Inkubook is that many new featues are forced to touch huge swaths of the app (recent examples: Adding calendars (vertical), improving client performances (horizontal), modifying cloud usage (interface point)). My question becomes: Are there effective latent code patterns for board, multi-tier changes? Given the nature of our application, I'd rather not have the code compiled into the client, even if it's disabled by hiding a button or whatever... silverlight spy makes it all too easy to turn that button right back on. Disable things at the service layer? Do I write acceptance tests that ensure that other in-flight features are NOT accessible? That seems like waste. Seems better to know that the code just isn't there... the costs aren't bad if you're good at branching, but at the same time, flipping off a property seems better.

Internal Consensus

As you can tell, I don't really seem to have a full perspective on this yet. I'll let you know when I decide, but for now I'll recognize the value inherant in both approaches and wait for a reason to change my perspective.

[1] An "MMF-equivalent" is a nice tag to describe a batch of priority one bugs that have accumulated in the main line and are determined to be worth testing and releasing without waiting for the next MMF to be merged in and released.

Announcing Lean & Kanban 2009 Miami

willeke — Tue, 30 Dec 2008 14:39:00 GMT

(Rescheduled to) May 6th-8th

http://www.leankanbanconference.com/

I'll be speaking, as will many of the leading thinkers in the Lean and Kanban software movement. Definitely worth a look at the site, and I really hope to see many of you there!

The announcement from kanbandev:

The Kanban conference is happening and the registration site is open.

http://www.leankanbanconference.com/

The site is a little basic at the moment. David Laribee and I sat up
in the small hours and got to this minimum marketable feature state.
We'll both be offline for a few days over New Year. We'll make the
site look pretty and add some more features next week. For now you can
register.

We're giving members of this list first priority on registration. The
event is limited to 125 folks. We expect it to sell out. We've
selected a superb venue the Mandarin Oriental Miami located on South
Beach at Brickell Quay right on the water.

http://www.mandarinoriental.com/miami/

Because of committed sponsors like Net Objectives and Ultimate
Software we are able to keep the registration fee down to only $800
per person for the full 2.5 day event. Registration includes an invite
to our evening reception on February 18th courtesy of Ultimate
Software. Breakfast and coffee breaks are included all 3 days. Lunch
is included on Wednesday and Thursday 18th and 19th.

Wednesday 18th February - Keynote Alan Shalloway - Lean Track and
Kanban Track sessions
Thursday 19th February - Keynote Don Reinertsen - open space all day
Friday 20th February - Keynote David J. Anderson - lightning talks for
2 hours

Please register now to avoid disappointment and book your flights to
Miami. Please be sure to make a reservation with the hotel. Ask for
the "David J. Anderson & Associates" event rate of $250 per night. The
hotel has indicated that it will honor this rate for extended bookings
prior or post the event subject to availability.

Our confirmed speakers are:

David J. Anderson
Alan Shalloway
Dean Leffingwell
Don Reinertsen
Peter Middleton
James Sutton
Clinton Keith
Amit Rathore
Corey Ladas
Karl Scotland
Eric Landes
Eric Willeke
Reni Elisabeth Phil Friis
Alisson Vale
David Laribee

and not yet confirmed...

Max Keeler and Linda Cook
Bob Stoddard (from the SEI)
Sterling Mortensen

Many of these people are regular contributors to this group and have
together created and lead the kanban movement over the last 18 months.
I believe this is the finest list of proponents of Lean software
development ever assembled.

With our 2.5 day format, we have one day of sessions in two tracks,
one day of open space and half a day of lightning talks. This will
give all attendees the chance to work with the experts directly.

I also need to thank WordClay who have kindly offered to sponsor the
publication of the proceedings. Each attendee will receive a book of
the proceedings - papers written by our many speakers. The book will
be available to everyone else after the event. Price to be determined.

Design Stories - A bridge between roles

willeke — Thu, 18 Dec 2008 20:18:00 GMT

This idea has been forming among our architecture group this week and I think it has enough potential to open up for public discussion. I'm hoping to get some good criticism and references to prior art I can draw on.

Overview:

Traditional stories provide a solid structure for understanding what value a given set of work is supposed to accomplish (i.e. Analysis). They do not provide a good means of giving a team guidance on HOW that is to be accomplished. On the other end, we have a great set of practices from XP and other sources that provide a means of creating very good code through pairing, co-located teams, etc.

Unfortunately, there is a gap present in most organizations. Where do you create a consensus about the architectural metaphor, that set of patterns and approaches that allows a good application to scale beyond a single team. Things like SOA can pull that decision making process out to the extremes, where there's a small body at the top working with services as a language, and teams that then take individual responsibility for their parts, but that doesn't extend to UI-intensive applications or to the deep complexity inherent in some domains. The core of the message is that Agile doesn't "do" detailed designs. There's a good reason for that: Detailed designs traditionally create a large transaction cost for each unit of work going through the system. When you've reduced batch sizes, the transaction costs become a higher portion of the overall per-item cost, thus making the detailed designs painful.

The design story template is used as the next layer beyond an XP-sized analysis story. It provides a mechanism for crafting highly focused design with minimal transaction costs. It also allows for training other members of the team on the design approaches as a core part of creating the design. In essence, each design becomes the process of filling out a small, defined template in the same manner as writing an FDD feature name or writing a BDD story. The part of this that is most interesting to me is that the design story follows a standard order starting with most generic (the story-level goal) and proceeds to the very detailed (what methods need created). Because of this, the architect [1] may stop writing at any point and allow a developer to write the remaining elements. In our organization, it will be reviewed, and the last line will frequently be left off. In others, the architect may stop after the third line and let a highly capable team member take care of the rest with no further interaction. It is entirely by intent that this template includes aspects that are typically left to the developer and starts with items that are usually left to the analyst or project manager.

This is a bridge between the value vision and the implementation, and provides a clear path towards training developers to handle harder, more abstract aspects as a part of their work and in a manner that is clearly relevant to their work.

Story:

In order to improve the user's perceived performance through a reduction of RAM usage,
we need to load preview quality images for the current page only.
This requires to make changes to page display behavior in the client,
using the established page mediator pattern through the page mediator factory,
to provide interactions between the project model's page changed event and the placement rendering

by creating a mediator named CurrentPageImageVisibilityMediator,
and writing the handler ProjectModel_CurrentPageChanged event that uses an ImageLoad asynchronous command to change the quality of the displayed image if the current page has become visible or ceased being visible.

Template:

In order to [goal of the story],

we need to [Decomposed software change supporting story].

This requires us to make changes to [the architectural/design components]

using [Identified patterns and approaches specific to the team/product]

to provide [specific interactions with existing components of this system]

by creating [specific class names to implement the patterns]

and writing [specific method names and behaviors]

Goals:

This came out of a few needs at Inkubook.

Developers wanting to grow in their craft and learn the design and architecture roles
Architects wanting to maintain enough control of the system's shape, but be able to effectively delegate
Keep batch sizes small, thus needing to
Minimize the transaction costs of each batch.
Different developers have different abilities, and the approach needs to scale to any of them.
Need to identify responsibilities without overwhelming the process
The need to provide meaningful review early in the design process

Influences:

There were a number of easily identifiable previous influences on how I was thinking, such as:

Communication pattern of "Describe a need, then ask to have it described back to you"
My understanding of FDD the concept of a Design Memo
Knowledge of BDD's "examples" notation
Desire to fit with an XP or BDD style "story" format and feel
The concept of the cone of uncertainty

Shu Ha Ri

[2] A good description of Shu Ha Ri can be found here. To summarise, the concept comes from the Japanese martial art Aikedo and refers to the three stages of learning.

Shu is the first stage, where the student is imitating and following the master’s steps
Ha is the second stage, where the student is showing understanding, and breaking away from the master’s steps
Ri is the final stage, where the student is showing mastery and fluency by creating their own steps

Mapping the concept of Shu Ha Ri into this story template, I believe that developers will be able to progress through all three stages for each of the lines in the template, at times in parallel. I want to do more evaluation of the androgogical aspects of using this sort of progression for teaching our craft more effectively, but that is something for another day.

Notes

[1] I'm saying "architect" in the sense of "the person whose job is to define the approach used in designing the application and for teaching that approach to the various teams involved". I understand the role changes based on system size and organizational structure.

[2] Taken verbatim from http://availagility.wordpress.com/2008/11/05/is-kanban-only-suitable-for-mature-teams/

Learning from Fast Food

willeke — Thu, 23 Oct 2008 18:54:00 GMT

Chipotle has the fastest service of any fast food vendor I go to. Rush hour, takes five minutes max. Go in when they're nearly empty and I can be out in under a minute. Feels faster than the best McDonald's times, even if it's not really. Why is this?

Chipotle does Kanban!

Why do I say this?

Their customer-facing staff are all generalists. They know how to work the register, make all the types of food, and warn the guys behind them when more supplies are needed.

They have a WIP limit of one order per person working the line. The cash register has its own WIP limit of one, or possibly two during the lunch rush.

Customers are the users, the food is the feature. The employees don't write requirements, they ask you just enough about what you want to satisfy the current stage of development.

The first employee pulls an order from the input queue, which is the line of waiting customers.

That employees take the order through the stages until there's another, non-busy employee next to them, then hand it off. There is no knowledge transfer, because there are no requirements beyond what's already piled on your burrito.

The first employee returns to pull the next customer, while the second employee works with the customer for beans, salsa, cheese, and so on, possibly allowing the next employee down the line to pull the customer's order forward.

At full employee capacity, there is one employee filling each stage and the customers move at a steady shuffle down the line. If there is no need for full capacity, then employees can clean tables, the kitchen etc while a smaller number of employees runs the food line.

At lower employee utilization, better (i.e. faster) employees are able to cover more stages, and are not limited in their performance by the process.

They do Kaizen events whenever something is screwed up. The employee will stop the line, solicit assistance from the adjacent employees or the kitchen as needed, and fix the problem. Work doesn't flow around in most cases because things are fixed very quickly and quietly.

Let's look at the key indicators:

They have work tokens (Customers) that utilize single piece flow (the order) and managed through WIP limits (Set dynamically by the resource count).

Resources pull work from station to station, avoiding all queuing for work in progress. (Technically, one order does queue before the cash registers most times)

They stop the line and resolve problems rather than allowing inventory to accumulate.

They have subordinated all other functions to the goal of minimizing customer lead time.

Higher Education and Software Development: Following parallel paths

willeke — Mon, 20 Oct 2008 16:56:00 GMT

I’m typing this in the car on my way to Ohio to see the in-laws because I just finished having an incredibly compelling discussion with my wife. My wife is an educator and has a masters of education specialized in adult online learning with a minor in curriculum design. We were discussing her frustration with some of the course authors and facilitators she works with regularly and transitioned to a discussion of how modern education as a whole interacts with online learning and online degrees. I’m going to describe a bit of recent educational history below. Please read this with the history of Agile, Scrum, and the current evolution of Kanban approaches in mind. Please keep in mind that I am intentionally disregarding correspondence schools going back into the 1800’s, although I could easily draw parallels there, too.

Online learning has spent the last two decades working very hard to become an accepted mainstream approach. Initially, online learning was used for niche training, and then degree programs began to become available from a variety of small schools. A huge variety of approaches were tried throughout the 90’s, with the good ones sticking and the bad ones quickly being forgotten. In the late 90’s and into the early 00’s, the industry started to consolidate with regard to the approaches and mechanisms used to deliver the learning, as well as the formats that were adopted for structuring the curriculum themselves.

Sound like the early agile movement? I find it interesting that there are summarization books that collect the successful approaches for online learning, just like Highsmith’s “Agile Software Development Ecosystems” does for agile.

Now, with University of Phoenix having led the charge and defined a highly effective “How” and then proven that it can be scaled very profitably, there are a huge number of small schools starting to get involved with their own programs. Additionally, the big, traditional universities are taking notice of what’s happening and introducing their own online degree programs. However, not only are the big schools years behind, they have a number of difficulties trying to integrate this “new reality” with the large-school mindset held by their administrations and tenured faculty.

I believe that sounds quite a bit like Scrum. It’s become the de facto “way to do Agile”, and it’s a very good one. My wife’s Master’s degree is from UOPHX, and I believe Scrum is vastly improved over traditional methods, so I don’t mean this as a slam. The big universities fit well with the issues faced by large companies trying to move towards agility.

The next wave is happening now. Back to where I started this discussion, my wife was chatting about a survey of “Authentic Learning” performed by her boss. This is where she sees the industry going next, and she’s certainly applying the principles and practices of authentic learning to her work, even before these principles and practices have accepted names or approaches. The essence of authentic learning is in moving away from students “learning how to be students” and towards “learning how to learn”. As an isolated example, authentic learning stresses challenging students with problems that have many possible solutions, rather than “traditional” problems with a single, gradable answer. By the way, "authentic learning" is new the same way agile is new. People have done it for a long time, but it's hard, and takes work, so people don't do it out of laziness or lack of discipline.

This is where I see Kanban fitting it. It’s not the answer, but it’s a positive move in the right direction, and it serves to move beyond the status quo towards a meaningful improvement. Even better, not only does it stress individually fitting solutions for the problems faced in development, it includes the Kaizen improvement culture for Just In Time improvements to the process. As an aside, I see Kaizen as being superior to the retrospective approach used in Scrum because it is event driven (pull) instead of periodic (push).

Now, we’ve done a great job pulling in many lessons from manufacturing to use in improving our software development process. So many, in fact, that manufacturing is becoming a very common metaphor, possibly even more common than the previous metaphor of home construction. Guess what? We’ve hit another single-metaphor system, and we’re driving straight towards stagnation again. I believe that now is the time to begin pulling in more metaphors, ideally those built on proven models. Education, with its many learning models, has a lot to teach us. Science, with its well defined methods for belief and proof, has a lot to teach us. Architecture has taught us patterns, and only recently have people really applied those to processes. I think we can learn quite a bit from service industries. Chipotle runs a very effective Kanban process for burrito building, for example. Economics had a great deal to teach us in managing incentives. The military could teach us a lot about specialized training, and about layered planning and delegation, and about utilization of specializations in a generalist environment, and about drastically changing the intent and behavior of a large force in a short period. There are a nearly infinite number of sermons out there that could be applied in various places. Traffic management could teach us [more] about avoiding bottlenecks. Some of these have been done already, some need to be done more, some might be brand new. I don’t care, so long as the knowledge comes to us!

Summary: Go forth, find guidance and wisdom from other disciplines, bring it back. And share it.

Back from Agile2008!

willeke — Tue, 12 Aug 2008 17:11:00 GMT

Wow, so much I probably should talk about, but I don't even know where to start. Massive amounts of networking, information, realization, and even contribution going on, and I can't unravel it at all right now. I think there's a lot of potential for transforming this into real, meaningful changes in my current environment, but I need to be cautious in how I approach things. I firmly believe in a few core changes that I think will drastically amplify the performance of our extended development group, but I can't just say "we need to do this"... I need to inspire people to _want_ an understanding of how it will help, and then I can happily and easily teach the basis of pull-based, work-limited techniques and explain what changes I expect to see appearing.

In other news, I had a great lunch with Chris S. today and am very excited to hear about the connections he made at the conference. He has a great opportunity to become a leader in the emerging area of Real Options within the Agile community and could extend both his personal brand and his current company's brand though developing those opportunities. Chris, go for it!

Finally, my brain's operating at a process level, and this post is hopefully a means to allow me to dump some of those thoughts and focus back on the code I need to write today. Maybe I shouldn't have started out touching the part of the system where the changes HAVE to be right, since it's the core factory of an entire tier.