Saturday Morning Ramblings... Bloody Stoopid Mary

Good morning everyone... I'm on a plane up to Philly to do a little work with the PMI Agile CoP. Delta bumped me to first class and I'm halfway through my second Bloody Mary. I'm asking that you be patient with me while I ramble on here a bit. I've got a nagging issue on my mind that I want to explore with you guys while I'm in transit this morning.

I was on my way home last night, on my way to the Buford High School homecoming football game, when my good buddy Dennis Stevens called and asked if I wanted to get together for a little while. I had a few hours until I needed to be anywhere, so I was like sure. You'd think that after a few years of knowing each other, we could find something else to talk about, but the conversation quickly turned to Scrum and Kanban.

You guys know that I am pretty pragmatic when it comes to selecting methodology... I genuinely feel that in the right set of circumstances, most methodologies... even Waterfall... have their place. What tends to set me off... and almost always forces me into some sort of a 'devils advocate' position, is when we start talking about these things as if they are absolutes.

Without going too far off in the weeds, we got to talking about Kanban's strengths when it comes to helping teams that have to blend operational or support work with other project work that has deadlines. Dennis was passionately making the case the Kanban is superior because it has classes of service, work in process limits, and explicit policies.

Of course this is all true... but what inherently makes it better? NOTE: getting ready to play 'devils's advocate for a minute. With every Scrum team I've spun up, we've had a conversation about how much time should be allocated to support. We just know that whatever is allocated to support, that allocation is going to lower our velocity.

We've implicitly define a class of service and we set an implicit policy around the work. What's the big deal? Sure... if I was a Scrum team that wasn't taking support activities into consideration, or doing something stupid like aborting the sprint every time a new support issue came in, Kanban might help. But I'm not talking about strawman Scrum here. I'm talking about well coached Scrum.

I suggested to Dennis that the premise of the discussion was fundamentally flawed. The real problem isn't which approach should I use to manage this variation... it's that this variation fundamentally exists in the first place. You see... I can manage variability using either approach... the problem is that we have work that inherently needs stability (new product features) being done by the same team that is doing work that is inherently unstable (bug fixing and support).

We can use either approach to constrain the amount of time allocated to the variable work, but what happens if all hell breaks loose and that policy has to be broken? Sure, we need to have a conversation about that... but I'm not convinced that Scrum or Kanban does a better job a prompting that conversation. Again... the core challenge is that these two concerns are competing for the attention of the team.

Someone goes away unhappy... either the customer waiting for a fix because the policy was enforced, or the product owner waiting for a feature because the policy was broken. So you see... this isn't a methodology problem... is a communication problem. It's an expectation problem. More than likely its a technical debt problem. And it's also likely that we haven't invested enough in the product to get done everything that needs to get done.

So... as long as we are talking to each other, and making good tradeoffs, and managing our efforts to deliver the best possible business outcomes... who cares what approach we take?

I would like less discussion about which approach is better... more about the core problems we are trying to solve... and more about how our various approaches help fix the core issues we are dealing with. Context is key... any statement of superiority in the absence of a specific context is a non-starter in my book.

Time to get back to my Bloody Mary... my ice is melting ;-)

Subscribe to Leading Agile

Kanban for Agile Teams Whitepaper

This paper has been a long time coming. The first draft of this was written while I was still at VersionOne. I pulled Dennis in to add his expertise and put some final touches on the content. We got the paper delivered, but it stalled on a technical debate over the definition of Lead Time vs. Cycle Time. The issues are finally resolved and the paper is ready for download.

Head over to the VersionOne site, download the paper, and let me know what you think. Here is the abstract:

Kanban has recently become popular with many project teams because of its ease of implementation, use of visual controls, ability to accommodate a wide variety of organizational design patterns, integration of stakeholders and relentless focus on the continuous delivery of value. Many development teams have found success with Kanban when more mainstream agile practices did not yield acceptable outcomes.

Organizations that are interested in adopting or improving agile methods should evaluate the underlying principles behind Kanban and how the principles can work together with more traditional agile methodologies. While there are meaningful differences between agile and Kanban, many teams will find that blending the two approaches can create tremendous value for their organization.

Subscribe to Leading Agile

Is Kanban just Waterfall with Small Batches?

Often when I introduce Kanban to teams that are just getting familiar with Scrum, one of the first comments I'll get is... it looks a lot like waterfall. So, here is the question, is Kanban just waterfall with small batches? Let's say you kept all your functional silos in place, and simply started running smaller projects... small to the point of being a feature or an MMF... would you get better business outcomes?

I haven't been in a situation where I could actually try this approach at any kind of scale, but my gut tells me that you would get better performance. You'd increase the rate at which the organization created value, you'd decrease the amount time spent doing up front planning, and you'd decrease the number of in-flight dependencies you're managing at any one time. Decreasing the batch size would make it easier to change direction when business conditions changed.

My guess is that's why some folks are so excited about Kanban... you get better overall performance, without having to change anything about how the organization is currently structured. You get incremental improvement without the transformation and change issues that come along with a Scrum adoption. In addition, you'd now have a way to explicitly visualize the work, manage the flow of value, and drive conversation that incrementally improves how the overall system behaves.

So... what do you think? Is this the preferred way of working? Do we abandon teams and transformation? Is adopting Kanban as simple as working on smaller batches, value stream mapping, and setting work in process limits to create flow? If we took this approach, what would be our tradeoffs? Would we be leaving anything out by not transforming?

BTW - It is worth marking the occasion... this is my 300th post on Leading Agile. That's kind of a cool milestone.

Subscribe to Leading Agile

Noodling on Kanban... Part Three

Earlier today we noodled on the secret sauce... maybe even THE most important value add... of implementing a Kanban system. Kanban gives us a very visual way of identifying and elevating the constraints in our system. The ONLY way to really get a team to go faster is to increase capacity at the constrained steps in the development process. Building inventory in other parts of the system leads to waste and re-work.

If you get nothing else out of this little series... that is your take-away.

For today... we are going to talk about going iterationless. So far we haven't really talked about the iteration but most Kanban teams have figured out how to live without them. We'll talk a bit about how to measure progress without being able to measure velocity at iteration boundaries. Without iterations... without velocity... we need another measure of team throughput.... and that is where cycle time comes in.

Going Iterationless

While agile is fundamentally designed to accommodate change, the idea of an iteration implies some degree of certainty about what it is you plan to build, even if that certainty is only two to four weeks into the future. In some environments customers can't wait until the iteration boundary to introduce changes. In some environments requirements cannot be neatly fit into a consistently sized window of time.

This understanding has led some teams to abandon the iteration all together and now consider planning at iteration boundaries to be a wasteful activity. These teams have opted toward working directly from the prioritized product backlog and only bringing new work to the team when the work in process limits allow a new feature to begin. Agile introduced the idea of small batch sizes by limiting the amount of work that could be pulled into the iteration. Kanban teams take this approach to the extreme and reduce the batch size at any one time to that of a single user story.

Teams that implement this approach have ad-hoc planning meetings when the team is ready for new work. They conduct periodic operational reviews to asses team performance, communicate with management, and evaluate the overall health of the system. Teams choose appropriate boundaries for traditional retrospectives but they are not necessarily tied to the operational review or any predetermined time-box.

Velocity versus Cycle Time

Agile teams become predictable by stabilizing the size of the product backlog and establishing a consistent velocity over time. We can assess the delivery date of a fixed scope product backlog by dividing its total size by the velocity of the team. Likewise, we can use velocity to make trade-off decisions when trying to manage to a fixed delivery date release. Without the iteration, there is no longer a fixed period of time from which the team can measure team velocity.

Kanban teams replace velocity with the notion of cycle time. Cycle time measures the total elapsed time from when the feature was started until it is marked complete and accepted by the customer. Cycle time can be useful for predicting delivery and making both short-term and long-term customer committments. Becuase features are independent and not allocated to a fixed scope sprint, the team can always work on the highest priorities of the business.

Many Kanban teams will track the cycle times of similarly sized stories, making a distinction between the cycle time of a one-point story versus the cycle time of the other possible story point values. If the team becomes proficient at breaking down user stories into similarly sized increments of work, estimation is no longer even necessary, and cycle time becomes the only metric necessary to measure the delivery capability of the team.

What's Next

The next and final post in this series will talk a little about why you might want to choose Kanban and a bit about Corey Ladas' work on Scrumban... an interesting hybrid of Scrum and Kanban for teams in transition. We'll also hit a little on some work I am doing with a couple clients to introducing Kanban boards for project/portfolio management.

Subscribe to Leading Agile

Noodling on Kanban... Part Two

Okay... time for part two in my Noodling on Kanban mini-series.

Yesterday we talked about the Kanban board and how it was similar, but not the same, as the Scrum task board. We also talked about work in process limits and how they can be used to explicitly control the flow of value delivered by the team. This post we are going to explore the idea of constraints and how Kanban handles the division of labor on the team. So without further adieu... constraints and labor.

Constraints

So this is how it works... we’ve got the board and we’ve got the work in process limits. As work moves through the team it is possible that certain steps in the development process might become bottlenecks and constrain the flow of value through the system. For example, the team might be dependent on a person who is not part of the team to deliver a particular feature. If that person is not available to assist them team, the work in process limits will prevent more work from being started until that constraint is removed and value is able to flow from the team once again.

Constraints are those steps in the process that are limiting the team’s ability to get completed backlog items through the system. The Kanban board forces us to stop taking on more work until we get the problem with our constraint fixed. By focusing all our attention on the constraint... we work together until the impediment is removed. Work in process limits encourage everyone to work as a team and prevent any one individual from getting too far ahead of everyone else.

Fundamental to the idea of managing constraints is the notion that any partially completed features are considered inventory and could potentially lead to waste. Our goal with a Kanban system is to limit the team’s ability to create inventory and increase the likelihood team members are doing work that will result in value in the shortest amount of time possible. Kanban systems elevate constraints and force the team to address them before they can bring additional work into the queue.

For a great visual representation of this whole process, go visit Henrik Kniberg's blog post... One Day in Kanban Land.

Reasonable Division of Labor

Some teams that encounter a Kanban board for the first time note that the columns seem to reflect a waterfall style process mapping. The reality is that requirements have to be analyzed and designed before they can be built and tested. The problem with waterfall is that teams work in large batches, doing all of one phase before beginning the next. In traditional methods, there is typically a high degree of specialization amongst team members and an excessive number of handoffs between teams as work moves through the system.

The Kanban board acknowledges the phases a backlog item must go through in the development cycle, but like mainstream agile, encourages small independent user stories that are developed in small batches. The columns on the Kanban board do not represent strict hand-offs between team members but more the feature's state during that time in its development lifecycle. While Kanban teams can accommodate a reasonable division of labor, Kanban teams are still typically made up of specializing generalists. Having specializing generalists on the team reduces skill-set dependencies and levels the flow of work across the team.

Kanban, like Scrum, leaves it to the team to decide how work moves through the system and doesn’t explicitly assign work to an individual with a specific skill-set. The Kanban board does acknowledge the reality of intermediate development states, and through the use of work in process limits, explicitly controls the amount of work in each state. This allows work to be managed, helps identify constraints, and provides visibility so the team can determine which impediments should be dealt with next.

The next post in this series will address going iteration-less and replacing velocity with cycle time. We'll close after this next one with some thinking about when you might consider using Kanban and maybe even introduce some advanced contexts I find particularly interesting.

Subscribe to Leading Agile

Noodling on Kanban... Part One

For the next few posts I want to explore some of my thoughts on Kanban. Like many in the community, I started thinking more about this during the Lean/Kanban Conference down in Miami. On the heels of that conference I did an exploratory post on some of the similarities and differences between Scrum and Kanban. The post addressed how Scrum and Kanban (in principle) were not all that different and how Kanban makes some things explicit that Scrum leaves up to the team.

There are a lot of things I consider myself pretty knowledgeable about... but on the whole... I am not certain Kanban is really one of them. David Anderson wasn't sure he agreed with my conclusions about Kanban… but didn’t totally slam the post… so I took that as a small victory ;-) For the real experts... you do need to go hear what David Anderson, Corey Ladas, Karl Scotland, David Laribee, and Henrik Kniberg have to say about all this. These guys are in the thick of the Kanban movement and most of what I know comes through them.

That said... I fancy myself pretty good at figuring stuff out and understanding what is most important. I am also pretty good at communicating complex ideas in a way that others can understand. So with that little bit of confidence (bravado) I am going to take another stab at explaining what I think is essential about Kanban… what tooling and principles I think are most important… and explore a bit how we can use these ideas to help our organizations become more effective.

Kind of like my first post on Kanban… I believe it is helpful to start from a shared foundation and bridge into the new ideas. My opinion is that there are five or six things... right out of the gate... that we need to know about Kanban to be knowledgeable of where it fits and how we can use it to our advantage in the enterprise:

The Kanban Board

The Kanban Board is a tool that helps the team visualize the flow of value through the development process. If you have used a Scrum task board you should be pretty familiar with the general concept behind the Kanban Board. There are sequenced columns that represent the states a work item can have at any one time. As work progresses through the development lifecycle, the card is moved from one state to the other, until it has been accepted by the customer.

The primary difference between task board and the Kanban board is that the Kanban board tracks the flow of user stories through their development cycle and is not concerned with tasks. This is significant because now the team is focused on the value creating item, the user story, rather than the activities required to deliver that value. Only when the entire user story makes its way through the Kanban board have we delivered value to the customer.

A simple Kanban Board might have a column for the backlog, work in process, and the work completed. A more complex Kanban board might break out the work in process column to include dedicated areas for each of the steps in a typical development lifecycle: analysis, design, develop, code, and test. Some Kanban boards will include columns for buffers between the various states depending on the needs and process maturity of the team.

Work In Process Limits

Kanban is more than just a way of visually tracking progress at the user story level. The Kanban board is intended to help the team minimize waste, focus on the most important work, and keep the value flowing through the team. The Kanban team accomplishes this by setting work in process limits for each column of the Kanban board. Work in process limits effectively restrict the amount of work that can be in any one state at any one time.

One common failure mode in Scrum is late delivery within the sprint. Late delivery means that all the backlog items were in process during the sprint but were only fully done and accepted in the day or two prior to sprint closeout. Late delivery introduces risk, tends to destabilize velocity, and results in delayed value delivery to the customer. Scrum addresses this by encouraging team members to work together on only a few backlog items to completion before starting new work.

Kanban takes this implicit guidance and makes it explicit by setting a limit on the number of work items that can be active at any one time. By limiting the amount of work that is in process, the team is forced to focus on getting backlog items fully done before new work can start. These limits can be determined by the team, or by their management, in ways that optimize the flow of value and reduce the number of intermediate work products.

So... What's Next?

The next post in this series will address constraints and a reasonable division of labor. After that we'll discuss doing away with iterations and replacing velocity with cycle time. We'll close with some discussion around why a team might want to consider using Kanban (over basic Scrum) and a little on where I see Kanban being used outside the team in more of an enterprise portfolio context.

Until next time...

Subscribe to Leading Agile

The Hard Reality...

We all want to be really good at what we do... we strive to get better... we want to think that we are making a contribution to the success of our organizations... we want to think that we are adding value. The hard reality... and one we NEED to really come to grips with... is that sometimes we are doing great work... sometimes even building great working software... that has NO market value.

If our activities don't result in marketable, sellable software... we are wasting time and we are wasting money.

We might justify this to ourselves by saying that we can only control within our circle of influence... that we have to be the best we can be within the areas we can control. Maybe... but if you get really good at creating design documents for projects that get killed... it is still waste. If I build features for a system that never gets sold to a customer... it is still waste. If I build services for a component that never gets consumed by the application... it is still waste.

Anything you document... or code... or test... or even deploy... that doesn't get sold to a customer is ultimately waste. It doesn't matter how good... or how fast... or at what velocity you do your work... unless it sells... you have wasted time and money building it. And that... to me... is what makes Lean such an interesting topic right now...

Scrum really brought home some powerful ideas... revolutionary ideas that have changed how we think about product development. We've learned the value of building organizations around teams and the value of self-organization. We've learned to give the business the power decide what and empowered the team to decide how. Scrum helped us learn that real improvement comes from keeping everything visible and removing the impediments that are really slowing our teams down.

Lean brings a relentless focus on value... not just valuable software... but real delivered value to our customers. Lean expands the concept of value beyond just the product delivery organization... it recognizes that the enterprise value stream often includes other parts of IT... and other parts of the business. Lean gives us language and principles to really scale agile out to the enterprise.

Individual performance doesn't matter... team performance doesn't matter... until we can figure out how to bring it all together into something we can actually sell.

Subscribe to Leading Agile

Scrum or Kanban... it's not Black or White

It's been fun the past few months to watch Kanban get some traction out in the community. It seems that my Google Reader is full of agile guys talking about Kanban. If you are David Anderson... this has to bring a little smile to your face. David and a few others have done a great job generating quite a lot of energy around this topic.

One of the things I found really interesting over the weeked was the words some folks were using to describe the value of Kanban. They were using words like 'increased visibility' and 'buidling trust' with the business. While I wouldn't argue with any of that... I was struggling to figure out how the benefits of Kanban were any different from how we would describe the benefits of Scrum?

If both methods 'increase visibility' and 'build trust'... there has to be something more. In my opinion... the key difference between Kanban and Scrum is that Kanban makes explicit what Scrum leaves implicit.

Let me explain...

Scrum takes the approach that the team is a black box. The business puts requirements in... and after some predetermined amount of time... they get working software out. Within that black box... the team gets to self-organize... they get to self-manage. The business gets to decide what... the team gets to decide how. The processes inside the team are abstracted from the business AND from management.

Kanban takes the approach that the team is a white box. The business puts requirements in... but rather than leave it up to the team to figure out how best to deliver the work... management plays a role in defining the work. There are explicit workflows... work in process limits... and visual controls that track the flow of value through the team. Kanban gives managers a role helping to deliver working software.

One of the earliest agile books I ever read was Mary Poppendieck's 'Lean Software Development: An Agile Toolkit". Not long after that I read David Anderson's "Agile Management for Software Engineering". Lean thinking and theory of constraints were just built into the very fabric of how I thought about and managed agile teams. As Kanban started capturing mindshare over the past few months... I found myself wondering what was so new.

We teach Scrum teams not to wait to the end of the iteration to deliver features to the product owner. We want to see linear increase in story completion during the sprint. We talk to each other everyday to identifty and remove impediments. When one team member is struggling to get something delivered... we are encouraged to help them get finished before we start on something new.

Scrum teams should be constantly focused on getting to done. I would argue that there is a bunch of single piece flow thinking up underneath a well run Scrum team. I would suggest that there are some implied work in process limits at play. I would suggest that effective Scrum teams are continuously indentifying and elevating constraints. For some teams... in some environments... it probably makes a ton of sense to make all these implicit controls in Scrum explicit by using a Kanban. Is it necessary in every environment? That's where I am not totally sold.

For now... for me... Kanban becomes another tool to help teams predictably deliver working software in the face of uncertainty.

For another view of this... go check out Dennis Steven's post on 'Uncovering Better Ways of Delivering Software and Helping Others do it'. It is a good look at how Kanban can help teams get better at delivering software without some of bad attitudes toward management that Scrum can sometimes encourage. Dennis might be a little more sold on Kanban that I am ;-)

Subscribe to Leading Agile

Adam Lambert or Kanban... America Has Decided

The American Idol season finale starts in a few minutes and I am really hoping that Adam Lambert pulls it out tonight.... that guy can really sing. Okay... okay... this is not a blog about American Idol... just had to get that off my chest. But in all seriousness... that is what I am planning to do with my evening... watch Adam Lambert take home the crown. Just had to pound out a quick post to get a few questions out into the blogosphere before the Adam Lambert victory party begins.

Okay... really.... no more Adam Lambert... I want to know what you guys think about all this Kanban stuff and how it fits with the rest of agile...

Over the past few days I have been dipping in an out of the Kanban boards and paying a little extra attention to what David Anderson is writing over at www.agilemangmement.net. David did a nice piece this week asking if Kanban is just a tool? The conversation has been great and I appreciate the time and energy everyone is putting into the discussion. I am learning a lot. That said, there was one particular quote in David's last post I would like to discuss:

"So Kanban (pull) changes the underlying paradigm from project-centric to flow and value-stream centric." - David Anderson

I'll admit, I am still getting my head around all this Kanban stuff. If we are using Kanban within the sprint to put visibility around the flow of work within the iteration, I get it. If we decide the iteration is waste and decide to go to a total pull system... cool, I get it. If we are able to increment an existing application little bits at a time, I pretty much get it. Are we going too far saying that our industry is moving away from the project-centric paradigm? If that is the case, we need to at least establish context.

Are we working on incremental changes to an existing product? Okay, I get Kanban. Are we working on a support queue? Okay, I get Kanban. I can see how Kanban is more than a tool in that context... it embodies the values of Lean thinking... pull, flow, value, waste elimination, and continuous improvement. It becomes not just a way of measuring and limiting work in process but a way of thinking about the work itself. In that context, projects don't make a whole lot of sense.

What I don't get is how we are going to do pull and flow and only work on a single slice of the application at a time when we are doing a large scale system implementation. When we are building an application from the ground up and there is no foundational architecture. When it takes time to established a shared understanding of the overall product vision to converge on an acceptable technical solution. What about when we are working on a system of systems? What if some of those systems are external suppliers of systems that have to integrate with our system?

What about when we have incremental investment and have to be done at some given point in time? No release planning? No iteration planning? No product backlog? Have we moved past the triple constraints when our customer expects delivery at a certain time, at a certain cost, with some idea of what they are getting for their dollars? Does Kanban work here too... if so, is it the same Kanban we were talking about before?

I think that in some ways Scrum is hitting a wall because some of us think that Scrum is the answer to everything. Is Kanban the new answer to everything? Is it going to replace Scrum and XP or DSDM or AUP or Crystal? I can't even imagine how we can have these conversations without understanding where and when is the best context to apply these principles. I feel like a broken record but there is a time and place for all these techniques.

There has to be a way to make use of this entire body of knowledge. However you slice it... it is up to us to know how to use all this stuff and choose the best practices for the situations we find ourselves in. Once we see things through that lens, it becomes less about who is right and who is wrong... and more about how to apply this stuff... and when to apply this stuff... and more about how we can move the industry forward the best we collectively know how.

Adam Lambert or Kanban... you decide?

Addendum 5/21/2009: I was really bummed that Adam didn't win... oh, well.

Subscribe to Leading Agile

Subscribe to Leading Agile

Lean or Kanban or Agile

Here I am.. Sunday afternoon.. Mother's day. Just got back from taking the family out for a low key Mother's day celebration and now I've got a little quiet time before the week begins. The conference last week was quite a rush... had a great time... met a lot of great people. Before the week gets going I want to sort through some of my thoughts on this whole Lean/Kanban thing.

A bit of history... Mary Poppendieck was one of the first few authors I ever read when I got formally introduced into the agile community. I recall how much her book resonated with me then... and looking back I can see how much it influenced how I think about agile... and the agile movement as a whole. I tell you guys that to say I have never made much of a distinction between agile and lean. To me... it was just a different way of looking at the same fundamental truth.

A buddy of mine recently told me the story of the blind men and the elephant. The general idea of the story is that we have a bunch of blind guys in a room with an elephant (sounds like a problem waiting to happen to me). These guys are each touching the elephant on different parts of its body. The guy touching the tail says an elephant is like rope... the guy touching its leg says the elephant is like a tree... the guy touching its ear says it is like a giant leaf. You get the idea. The point is that without being able to see the whole... they each describe the elephant from their own particular point of view.

As I watch people debate over what it means to be agile... it seems we were a bunch of blind men arguing over the nature of the elephant. If your point of view is small, colocated teams... scrum brings a valid perspective. If your focus is more technical... the practices of XP tend to resonate. If you come from a larger more structured organization... you might need AUP or DSDM. If you have a really small team of experienced developers... let's talk Crystal. Context is everything.

It seems to me that much of our debate is out of context. When we get dogmatic about one methodology... about one set of practices... we are often not taking the other person's context into consideration. That is why the Agile Manifesto was so powerful... it was a set of value statements... it was a set of principles... that was broad enough to be applied in a situationally specific way. We have to take the local context into consideration.

I don't think the Lean/Kanban proponents are saying they have found a better way... I think that we are continuing to learn and to grow and to better understand what it takes to deliver great software. It seems to me that the Lean/Kanban movement is not out to replace XP or Scrum or DSDM but to help organizations that are having trouble adopting these practices... or have adopted them and need something else to increase their productivity.

Here is a quote from the Schwaber and Beedle book "Agile Software Development with Scrum"...

"Empirical process control models are elegantly simple. They employ feedback mechanisms to monitor and adapt to the unexpected, providing regularity and predictability. The actors in a Scrum team empirically devise and execute the best processes possible based on their skills, experience, and the situation in which they find themselves"

The line about the team devising the best processes possible based on their slkills, experience, and the situation in which they find themselves has always resonated with me. I think that Lean and Kanban give us another set of processes and tools that can help the team improve. I do not believe Lean and Kanban are at odds with Scrum... nor do I believe that Lean and Kanban are going to be successful without the engineering discipline encouraged by XP. We are just another set of blind men looking at a different part of the elephant.

My personal take...

Kanban is a visual process control tool that helps teams effectively manage the flow of work through the sprint. Scrum gives guidance that the team decides what they can do... and the team decides how it will get the work done. Kanban gives the team another way to inspect and adapt and to learn how to get better. I am not hung up on the fact that Kanban is iterationless... I can apply it within the iteration. If I determine that the iteration has become waste and no longer need it... I'll get rid of it.

My goal has never been to do Scrum... my goal is to build great software as fast as possible. In Scrum process improvement is implicit... the team inspects and adapts and find ways to get better. In Kanban we put specific visual controls in place that help the team better understand the flow of work through the sprint and make targeted improvements as necessary.

To me the idea of Lean is a bit broader... lean deals with the enterprise. Lean is about managing the flow of work across teams. How do I take an idea that comes from biz dev... turn it into a product idea... get the work assessed and approved... built... tested... delivered to the customer... billed... and supported. Lean can give us some guidance here for how to manage the flow of value through the organization. Kanban is a tool... Lean is a philosophy.

A team could use a Kanban board to manage the backlog item through the development phases... analysis, design, code, and test. An enterprise could use Kanban board to manage the flow of an idea from inception through development to billing and support. The principles of Lean can be applied within the team and across the teams. Understanding value streams... identiying constraints... eliminating waste are all explicit ways of helping the team get better. These are principles and tools that explicitly help the team inspect and adapt and make better decisions.

As a founding member of the Lean Software & Systems Consortium I hope we continue to build on what is out there and resist the urge to make this something wholy new. Remember... agile is all about uncovering better ways of developing software by doing it and helping others do it.

Lean/Kanban gives us another set of tools to help that come about.

Subscribe to Leading Agile Subscribe to Leading Agile