Not Blogging Today

Just thought I'd share with you guys what NOT blogging looks like for
me this weekend. Subscribe to Leading Agile

Oredev 2009 Malmo Sweden

I got an interesting invitation to head to Malmo, Sweden this year for the Oredev 2009 conference. I'll be doing two talks in the agile track... one on scaling agile and the other an experience report based on the coaching gig I did earlier this year. Regular readers will recognize some of the topics I plan to speak about.

The Manager’s Guide to Agile Adoption

Agile methodologies are helping teams deliver software faster and with much higher quality than ever before. Given the success of agile at the team level, many managers are exploring the possibility of implementing these methodologies across the entire product delivery organization. These managers launch their adoption efforts only to uncover many common myths, misperceptions, and obstacles that derail their efforts before they really get started.

Organizations fail to become agile because they don’t understand what makes agile teams work. Breaking past traditional organizational constraints, even the constraints imposed by some of the better known agile methodologies, will free managers to create situationally specific strategies that support the formation of teams and enable them to deliver both reliably and consistently back to the business. Agile teams become the building blocks of agile organizations.

This talk will explore a roadmap for agile adoption that begins with teams and demonstrates how teams work together to deliver more complex projects and portfolios. Mike will expand the team concept to include capabilities and show how capabilities can be organized to optimize value across the enterprise value stream. At each step of the adoption process, Mike will demonstrate how to choose the policies, practices, and metrics that create learning and drive sustainable organizational change.

Agile Adoption past the Team – An Experience Report

Discussions of agile often assume that there is a single team, assigned to a single product, with a single dedicated customer guiding all the product decisions. In reality, many organizations are building complex products that require the efforts of more than one development team. When teams have to coordinate to deliver a highly integrated product, the product owner’s job often becomes too big for a single person.

Not all the interesting scalability problems are reserved for the enterprise. Product Owners have challenges when trying to coordinate the deliverables for only four or five dependent development teams. Quite a few organizations are expanding the role of Product Owner to include Product Owner Teams and Product Owner Teams with Architects. These teams work in partnership with the Product Owner to maintain the product backlog and drive integrated decision making.

This talk explores a 3 month coaching engagement where the customer needed to coordinate requirements and design across five highly dependent development teams. Mike will show how the teams went from zero to hyper-productivity in a matter of sprints by implementing solid engineering practices and deploying a Product Owner team to coordinate deliverables across the entire product delivery organization.

Speaker Bio

Mike Cottmeyer is a product consultant and agile evangelist for VersionOne. Prior to joining VersionOne, Mike was a senior project manager for CheckFree Corporation where he led a portfolio of projects for their online banking and bill payment business unit. Mike has 20 years of experience leading IT initiatives using a combination of traditional, agile, and lean project management best practices.

Mike is a certified PMP Project Manager and a certified ScrumMaster. He co-created the DSDM Agile Project Leader certification and holds Foundation, Practitioner, and Examiner level certificates. Mike is an honorary member of the DSDM Consortium and a founder of the Lean Software and Systems Consortium.

Mike speaks internationally on the topic of Agile Project Management and writes for several blogs including http://www.leadingagile.com and http://blog.versionone.net and occasionally for http://www.agilesoftwaredevelopment.com.

Subscribe to Leading Agile

Subscribe to Leading Agile

Agilepalooza!

Are you going to be anywhere near San Francisco, CA on May 29th? You need to find a way to get to AgilePalooza.

AgilePalooza is the first of a series of not-for-profit community events presented by VersionOne. It is meant to be a fun, low cost gathering that brings internationally recognized coaches and trainers into community for a day of learning and advancing agile methods. None of the speakers are paid to present or participate...they are offering up their services simply to support the agile community. For the ridiculously low price of $69... attendees will get a full day of agile learning, breakfast, lunch and good times. If there are any funds left over after the event they will go directly back into the AgilePalooza program or be donated to the local agile user groups supporting AgilePalooza.

Go to http://www.agilepalooza.com for more information and to register. Where else can you get this kind of Agile love for only $69?

Subscribe to Leading Agile

Subscribe to Leading Agile

Books I Recommend Often...

Quite frequently I am out talking to traditional project managers or new agile teams that want to learn a little bit more about all this agile stuff. Inevitibly I get asked what books I recommend for folks trying to sharpen their agile chops. Thought I would share a few that I recommend the most with a few words on why I think they are important:

Extreme Programming Explained - Kent Beck

This was the first book on agile I ever read and it really is foundational to the whole agile movement. The practices behind XP are the the secret sauce that makes all the agile project management and leadership stuff really hum.

Managing Agile Projects with Scrum - Ken Schwaber

How can you talk about agile nowadays without knowing something about Scrum? This book does a great job explaining the project management side of Scrum and is a great resource for someone just getting their feet wet with agile.

Agile Estimating and Planning - Mike Cohn

No one explains agile planning better than Mike Cohn. Release planning... got it. Velocity... got it. Planning poker... got it. If you understand the fundamentals and want to put planning structure around agile, read this book. It is essential for running a disciplined agile project.

User Stories Applied - Mike Cohn

Two in a row from Mike Cohn? User stories tend to trip people up. Understanding how to write requirements as functional threads valuable to a customer is hard... this book helps you do it better.

Agile Software Development - Alistair Cockburn

I can't have a list of agile books without one from Alistair Cockburn. I probably like this book best, but don't usually recommend it first. It describes software development as a cooperative game... similar to musicians improvising on stage. A bit esoteric, but a brillant piece and a must read for the more advanced practitioner.

Software Project Manager's Bridge to Agility - Michele Sliger and Stacia Broderick

This is really the first book that mapped the processes behind the PMBOK with agile methods. These ladies and I really see the world the same way. I am a PMP and this is the one I always recommend when talking to the PMI crowd. It is a must read for the PMP trying to manage an agile project.

Scaling Lean & Agile Development - Bas Vodde and Craig Larman

I am not as sold on this one, but it is one of the few that addresses agile at scale. There are a few things I disagree with and I think it is a little dogmatic about taking the feature team approach. It is well written and provides a valid perspecitve on how to scale agile to the enterprise.

Scaling Software Agility - Dean Leffingwell

In my opinion this is the only book that adequately addresses dealing with agile at scale in a complex enterprise... period. If you are building complex applications, systems of systems, in a large organzation... this book is a must read. This is the one I find myself recommending most frequently as of late. Its the only book that really challenges the idea of a feature team and provides a credible alternative.

Managing Iterative Software Development Projects - Kurt Bittner and Ian Spence

This one is a little non-agile... almost RUP... but I think it does a solid job of explaining iterative and incremental software project management... with a bit of a nod to the agile practitioner.

Any others that should be added to this list? Put your recommendation in the comments... but make sure to explain why it needs to be added.

Subscribe to Leading Agile

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

Throttling the Agile Enterprise

It feels like a year ago I did the post Enterprise Constraints and Feedback. The past few weeks have been filled up with the Lean & Kanban conference and some client work that required my undivided attention. Toward the end of that post, we talked about 6 principles that allow your organization to properly throttle work through your agile enterprise. I wanted to take a moment this afternoon and explore those a bit and see where it takes us:

Make small bets by approving smaller projects

How many of you guys have been on an 18 month project? How many of you have been on an 18 month project that got killed or totally re-scoped after a year or so? The reality is that in today's economy the uncertainty associated with large scale software development projects is just too high. The longer it takes to get product to market, to get real customer feedback, and to start generating revenue... the more risk you accept as an organization. Given our track record of project failure... smaller projects are less risky projects... and therefore better projects to approve.

Prioritize for finishing projects rather than starting projects

This is a complicated one. It gets into this whole discussion around keeping work in progress to a minimum and optimizing for the overall throughput of the organization... rather than for optimal resource utilization of the individual. If you are an agile organization, and have bought into the idea of organizing around teams, you should be pretty good with the idea of 'done done'. 'Done done' means that we don't deliver partially completed work. The only features that count are the ones that are ready to be shipped to the customer.

Interleaving a bunch of partially complete projects just makes the overall system deliver value less effectively. If we have three projects in the portfolio that are all planned to take three months each... and I do them one at a time... when will they be done? The first one will be done in three months, the second in six months, and the third in 9 months. What happens if I try to do all three at once? Best case you might deliver the first in 7 months, the second in 8 months, and the third in 9 months. More likely you'll deliver the first one in 12 months and the other two will get killed.

Don't start projects that you are unable to finish

Building on this idea of prioritizing for finish rather than start... if there is more than one team that has to work together to deliver a project... or even a MMF... and we can't get all the work 'done done' within the time-frame allotted, don't start it. We usually use some form of logic that goes something like... well, we have this person or this team with nothing to do... let's get them working on the next project. Keeping people busy is not a good reason to start project work.

The problem is that starting the next project dilutes the organizational focus from working on the projects that are already in process. Chances are pretty good too that when the other teams free up requirements will have changed or we'll learn something that leads to significant rework. This is tough pill to swallow... but I would rather that idle team go help another constrained team... or even do nothing... rather than start work on a project that is underfunded and low on the priority list.

Work on the highest priority projects first

All of these are pretty closely related, but if we always prioritize the project that is most valuable to the business... and we always focus on getting projects to 'done done'... and we don't waste effort by working on things that don't have the support of the rest of the organization... we know that we will always be delivering the most valuable features to the business with the least amount of waste from building software that might not ever be consumed. This might mean that teams are idle at times... it might mean that teams need to be redeployed... and it might mean that you need to let some folks go.

Make sure to read the next section before you go and start laying folks off from your team... there is hope!

Provide support for those teams that are slowing down your ability to deliver

If you find that a large part of your organization isn't busy because one particular team is slowing everyone else down... cool, you have just found where you need to go help. An enterprise full of teams building software is a continuously shifting set of constraints just waiting to be optimized. Someone at the Lean/Kanban conference said that a perfectly optimized organization has only one constraint optimized at a given time. An organization with every team optimized is actually the least optimized overall system.

Having identified the team that is slowing down your ability to deliver, you have identified where you need to go get better as an organization. By focusing your attention on the team that is preventing the other teams from delivering valuable work to the organization, you are focusing on the area of your development organization that is going to yield the most productivity gains for the overall system. It does not make any sense for a team to get better delivering software if they are not your primary constraint.

Establish an enterprise level velocity

If each team has a velocity sprint over sprint... and we start making smaller bets... and we prioritize for start... and we don't start things we are not able to finish... and we start working on the highest priorities first... and we elevate our constraints... you know what happens? We can start measuring project velocity across the enterprise just like we measure point velocity within the team.

Pretty cool idea... let me know your thoughts on this one.

Subscribe to Leading Agile Subscribe to Leading Agile

ProductCamp Atlanta

There is a FREE event for Product Management types in Atlanta. The first ProductCamp Atlanta will be held Saturday, June 6, 2009 at the GTRI Conference Center (250 14th Street, NW, Atlanta, GA). You can find the details here… http://barcamp.org/ProductCampAtlanta.

They are looking for sponsors and session leaders. (Product Manager types LOVE Agile topics). Please forward this post to other people who might able to come to Atlanta for the event. This is going to be really cool, I have done a few barcamp type events and they are great learning opportunities.

Right now I am a strong maybe to go... my wife and I are leaving for Vegas (SQE Better Software Conference) the week after so I don't know what is going on with the kiddies that Saturday. If I were not travelling the week after... I would definately take a Saturday to go. I strongly encourage you guys to make this happen!

Subscribe to Leading Agile Subscribe to Leading Agile

Why a LeanSSC? Why a Lean Certification?

As you guys know, I was down at the Lean/Kanban conference last week and got involved in the formation of the Lean Software and Systems Consortium. As a result of all my blogging and Twittering... Mark Levison, an agile coach and editor from InfoQ... asked me why we needed a LeanSSC and why a new certification? It was a great question that needed more than 140 characters so we took the conversation off Twitter and into e-Mail.

After responding to Mark... it seemed that you guys might be interested in my response as well. For completeness, I'll give you Mark's question he posted to the Lean/Agile Yahoo! group and then my complete response:

Mark's Note

I wasn't at the conference and so all I can do is read the press release. After reading I'm confused.

1. Why does the world need a Lean Consortium?
2. What does the Consortium hope to achieve?
3. Why do we need another certification?
4. How will this certification be different from the CSM/CSC/CST?

Confused in Ottawa
Mark

My Response:

Hi Mark,

I don’t know that I’ll have all the answers here… the organization is brand new…. just barely out of concept… so some of this will shake out over the next few weeks. I can tell you the reason that I was interested in exploring creating a new organization.

As it stands right now, the DSDM Consortium and the Scrum Alliance are the only organizations offering certification. Very few people have heard of the DSDM certification and clearly the Scrum certification has exploded over the past few years. I like Scrum, I practice Scrum, and while not a CST… I teach Scrum. Scrum is a great small team framework but I do not believe that Scrum by itself is scalable.

Most of the teams that are scaling Scrum have expanded the idea of a single Product Owner to the idea of a Product Owner team. This is not part of base Scrum but is essential to coordinate the activities of many teams working in concert. Also, many large organizations are built around large system components, components that are products in themselves… these teams are building integrated systems within large component architectures. Scrum gives no guidance on how to do this.

In any organization that is large and complex enough for the feature team model to break down, you have to start looking for effective ways of managing flow across the organization… how to manage work in progress… how to manage constraints… how to manage dependencies. Scrum gives no guidance on these scaling issues… Lean does.

There were two primary camps in the room when the LeanSSC was formed. There were people that thought of Lean as a discipline unto itself… one with its own body of knowledge. The were also people in the room that felt strongly a LeanSSC needs to build on the foundation of agile, embrace what we know, but build lean scaling principles into the fabric of that body of knowledge. Personally, I am hoping the LeanSSC takes the latter approach.

So to answer your questions directly:

1. The world needs a LeanSSC because there is an agile body of knowledge that is bigger than what Scrum is prepared to address. By creating an organization that is broader than Scrum, one that can embrace a broader body of knowledge, we have the opportunity to engage academia, corporations, and individuals that are interested in advancing that body of knowledge.

2. Some of this will be worked out over the next few weeks but the general idea is to identify the body of knowledge, create a set of Lean/Agile competencies, and provide certification around these competencies. You might also imaging a structure that allows member organizations to contribute to and benefit from the growing collection of intellectual property. Ideally we create a very open system.

3. The Scrum certification has been great in leading the software industry to a broader knowledge of Scrum in particular and agile in general. Scrum as it stands now does not meet the needs of the enterprise… people that are making Scrum work in the enterprise are using techniques that are counter to Scrum and certainly not contained in the Scrum training material. The LeanSSC has the opportunity to broaden the certification track and give companies a path to build a more competent workforce. I can’t imagine that people believe Scrum is all you need to know to build large scale software projects.

4. I suspect it will be based on a set of published competencies. I suspect that there will be multiple training courses to address the various competencies. I suspect that any training organization will be able to deliver competency training and that to receive certification in a competency will require a test. I suspect there will be multiple paths through the competencies based on the objectives of the person or persons receiving the training (developer, manager, senior leader). This is not defined yet… but I suspect it will be a much more open system.

I would like to reiterate that this is all MY opinion and may not reflect the official position of the LeanSSC or any of the individual founders. There is a lot of work to do… the formation of the organization is just a first step.

Mike

What do you guys think of my response? Does it carry water? Do you think this team of people is off base? I am interested in your opinion....

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

#LK2009 Alan Shalloway (Closing Keynote)

Closing Keynote: The Case for Lean-Agile Software Development

Alan's closing keynote is about what is next in software development.  Alan approaches this field as a scientist and starts off talking about the need to understand what we are doing and why we are doing it.  He goes on to talk about software and the critical role is plays in our society... nearly nothing would work in the absence of software.  The more important software becomes in our lives.. the more quality becomes important.  Some of these software systems are life and death.

 

Alan gives us a quick history of the software industry and explains our journey to maturity.  Over the years we have seen a pendulum swing from no management... or ad-hoc management... to heavy command and control processes.  Alan has a sense that agile is as much a reaction to something as it has been a solution.  On a personal note... it was refereshing to hear Alan say this becuase that has been my feeling for a long time.  I know agile works... but in large part it was a reaction to really bad middle-managemen t... really bad project management.

 

Alan suggested that we need to get past the either or nature of the manifesto (a comment I did not fully agree with, don't believe it is either or) and create a balance between management discipline and software craftsmanship.  Business cannot be run with a 'you'll get it when you get it' attitude.  It just doesn't work that way.  You cannot just ask a manager to stand back and trust that the team won't crash and burn.  We need to have the right management controls that allow the team to be empowered and the manager to effectively manage the team.  

 

Alan's take is that practices are more widespread than principles and that we are suffering from not having the proper management view and a lack of professionalism in our industry.  Very often we see teams that love agile... they love the practices... but the business is not getting the value they hoped for from their agile implementation.  They have high practice adoption but low agility.  Alan goes into the management paradigms we have available to us from industry:  Craft.. interchangeable parts... and interchageable people.  Lean gives us a fourth alternative...

 

Lean gives us the opportunity to manage.. .without being command and contrlol.  The business decides why our work is valuable.  The manager decides the best way to deliver that value.  The team decides how we achieve that value.

 

This pretty much took us through the first hour or so.  Alan wrapped up his part of the talk and handed the mic to Alan Chedalawada.  The second Alan got more tactical and showed us how to put all of this together.  All in all a really good talk and a nice way to close out the conference.... at least the formal part of the conference.  The day is going to continue with a few hours of open space lead by Jean Tabaka.  I'm going to stick around for the first few minutes but need to get to the airport and head home.  

 

There's not really a good way for one person to document open space sessions in real time but I am hoping that some folks will take pictures or notes during the individual sessions and get them up on a wiki somewhere.  If that happens... I will do a quick post to let everyone know where they land.  Totally rockin conference... really glad I was able to make it down.

 

Conference out... Mike

 Subscribe to Leading Agile

Subscribe to Leading Agile

#LK2009 Willeke, Shinkle, and Laribee

This is going to be the last set of talks for the day. The Kanban talks, somewhat unlike the Lean talks yesterday, has been mostly experience report type presentations. It has been really cool.. all the speakers have done a great job... but we are getting to a point where there is not a tremendous amount of differentiation between the stories. I am going to try to keep these next few summaries centered around the "a-ha" moments where the speakers add something new to the conversation.

Eric Willeke: The Inkubook Experience: A Tale of 5 Processes

Eric works for a small company called Inkubook that builds self-publishing website. The presentation was really unique becuase it was totally visual... totally picture based... even the agenda which was a photo of a Kanban board... very clever. This talk was really more like a story... a story about Eric's journey to discover a process that worked for his time.

Just to give you a little background on their situation... if we have learned nothing this week... context is everything. His team had a constantly changing backlog... an agressive timeline to deliver (2 months or so)... and team of specialists. They tried scrum but it just wasn't working for their team. It seemed that the specialization around the analysts was causing problems getting the sprint started on time.

After several iterations of trying new things... pulling the BA out... putting the BA back in... pulling the architect out... putting the architect back in... they started doing some Kanban like process control. Eric told a great story about being sure not to call what they were doing Kanban... if the label stuck... that early transition process would be called Kanban.

Eric's team focused in process maturity around Kanban... introduced queues across the team... they had implicit work limits (the team just seemed to get it)... and established flow across their development process. They got hit with an unexpected layoff and the Kanban process allowed them to recover in less than a day. Their SLA stayed the same but the throughput of the team went down accordingly. It was the specialized analysts that took the brunt of the downsizing. After the team learned how to interact with marketing directly... their throughput actually recovered.

At this stage of the conference... there were really no new ideas presented. Eric did make an interesting comment that his team had gotten so good at single piece flow... they no longer felt the need to use the Kanban board... they just know where things are all the time. He drew no conclusions about their findings but assured the community that he would let us know how things are working out.

It was really cool hearing the transition story, how the team learned from their mistakes, and how they inspected and adapted their way to a pretty cool Kanban implementation.

The other thing that was really cool is that you can tell the speakers are learning from each other. Folks are referencing other speakers in their talks and changing their content on the fly to reflect what they learned. So far... this has been one of the most interactive learning experiences I have ever been a part of... and that is saying something for a conference that was not designed as an open space. So far... no one has wasted my time... and I have a pretty low tolerance for speakers that don't deliver.

Chris Shinkle: Embracing Kanban, A case study examining how Kanban has been integrated into Software Engineering Professional (SEP)

This talk is shaping up to be one of my favorites so far. Chris starts his talk by explaining his particular context... 4-6 month projects... 4-6 people per team. They have many transitional projects where they frequently stop and start... go on hold and come off hold. The company was agile friendly and had tried implementing FDD... but the transition did not have lasting impact. Once things got widespread... agile was met with resistance. Can you guess what they tried next ;-)

Chris takes a totally different perspective than the other speakers on Kanban today. He introduces the transition to Kanban by introduces the Dreyfus model of learning. If any of you guys are familiar with Aistair Cockburn's Shu-Ha-Ri methaphor... this is very similar. The Dreyfus model has five levels: novice, advanced beginner, competend, proficient, and expert. The talk centers around the Kanban related behaviors related to their progression through the Dreyfus model... very enlightening.

Here is a quick summary of what Chris observed as the team moved through the various stages of the Dreyfus model:

Novice - Using the Kanban board as a task tracking system with no regard for WIP. One advantage was that it illustrated the development process and exposed it to the team. They could see what they were doing and had a better understanding of what everyone else was doing.

Advanced Beginner - At this point, the WIP limits being followed. Teams started to understanding the impact of blocked work items and the cost of re-work.

Competent - The whole team participated and had a sense of ownership. They ought out alternate practices and discovered BDD, TDD, Pair programming, Modeling, and pair code reviews. They started seeing the effects of the changes they made and discovered lean principles for themselves.

Chris made a quick acknowledgment here that without emotional involvement you will never move past the competent level of development...

Proficient - Throughput and reducing cycle time became the primary focus. The team began to focus on the other roles... not just their own... they started looking at optimizing the whole. They became focused on reducing swim lanes and work in progress. Kaisen moments became more commonplace

By using Kanban the team started learning lean... in this case process led to an increased understanding of the principles.

Expert - Team never got to that... could take 5 to 15 years.

This was a great talk and an interesting gear shift from the other experience reports we have heard earlier in the afternoon. Looking forward to hearing David Laribee up next...

David Laribee: A Leaner Form of Agility

David sets up this talk by discussing is role at XClaim... the company he joined prior to joining VersionOne. David was the product owner and coach and involved with all elements of development and process design.

The first half of David's talk focuses on process and his experience developing the Kanban system at XClaim. David is a BIG believer that values drive your choice of practices and that practices drive your choice of tools. If you don't know what your team values... you need to go back and figure it out. David is also a big believer in collaborative process design... people support a world they help create. He goes on to explain how his team at XClaim went about designing their Kanban board.

David explained how practices increase performance... but that over time... the team will plateau. The only way to get better is to eliminate waste. He tells this great story about a team of phychologists that decide to pay people to dig holes. At the end of the day... the holes are covered over. The diggers are told they will be paid double if they come back tomorrow to dig more holes. Over time... people stop coming becuase they value meaningful work.

By elimating waste... you not only make things faster... but you engage your team in meaningful work. David talked about how Kanban is a window into how we work and that processes should emerge... start with the simplest thing possible and only add steps and practices as they are deemed necessary by the team. Reflect what you are doing now... first... and optimize for essence over ceremony.

The second half of David's talk is about the engineering practices that support Lean practices.

David highlights why Scrum is failing... it is due to the lack of solid engineering practices as the foundation. He goes on to describe how stories and tasks need to be independent, but that pairs of pairs can be deployed, that we can use set based concurrent engineering to solve some of these problems. He talks a bit about how teams can use BDD... composite applications... feature inboxes... a highlights some companies that are doing this stuff in their lean enterprises.

At this point, David is splashing code up on the screen so I have to admit... I tuned out a little bit. This was the most technical talk of the conference and worth checking oout the InfoQ video when it is posted. It was cool hearing David talk since we both work for VersionOne... he did a great job... so next time... check him out.

Subscribe to Leading Agile Subscribe to Leading Agile

#LK2009 Vale, Cook, and Landes

The day has certainly gotten off to a strong start. We are seeing lots of great practical advice on how various organizations have implemented Kanban systems in their organizations. I enjoyed the first few session of the morning and am looking forward to the next set of talks. This set bridges the morning and the afternoon. After this set... we'll have three more speakers and close out the day.

Alisson Vale: Practical Experiences and Tools Applied to a Kanban Sustaining Engineering System

Alison is taking the conversation up a notch. His talk is explaining a very sophisticated approach to managing his Kanban process. There is no way that I am going to be able to explain to you guys the depth of complexity here... but I think I can share with you a few key takeaways that will augment some of the earlier session overviews.

I didn't talk at all about David Anderson's class of service discussion in his earlier talk. It was a really interesting point... but was discussed late in the talk and not fully developed. The main idea is that a Kanban card can have a class of service... an indicator that speaks to the risk associated with that feature. Does the feature need to be delivered by a certain date... is it an emergency request... is it a nice to have? All that kind of stuff is a class of service.

The reason I bring up David's class of service idea is that Alisson had a slightly different take on class of service. Alisson sets up the conversation by establishing the idea that long term relationships require long term agreements and defines four types of agreements in his organization: problem solving agreements, support agreements, improvements for stability, and new value agreements. Alisson defines his class of service around the agreements he makes with his customers.

Interesting concept and I think you can see how these might play out in scheduling... and defining work in progress queues.

By establishing work in process limits around each class of service... we create predictability... we create flow... around each class and can mitigate risk by deciding how much to invest in each particular class. One interesting outcome of taking the Kanban approach is that you create a policy driven... metrics based... organization. Setting limits on work and giving the teams guidance about what to work on... when... and how... you actually empower the team to work without management intervention.

Another theme of Alisson's talk... and this is starting to be an emerging theme across the talks... is the distinction between allocation vs. prioritization. This idea can be applied to classes of service AND for different types of business activities of features. If I am hearing correctly... what this tells me is that the team is allocated based on class of service and feature type... and then prioritization happens within those allocations.

Prioritization is not absolute across the entire backlog but only relevant within the context of a particular feature or service class. This is an important distinction because it allows the business to mitigate risk and apply resources to risk mitigating activities that might not otherwise make it to the top of a priority driven product backlog. Like most of what I am learning about Kanban this week... this approach gives us explicit mechanisms for managing our sofware organizations and get's us past the typical handwaving about letting the team decide.

This is all about the appropriate level of constraints... and the appropriate level of guidance... constraints and guidance that actually empowers the team to operate in accordance with the overall business objectives. Alison's talk was deep and detailed... it was impressive. Personally... I am still struggling to see how to apply this level of detailed management to the kinds of organizations that Dean Leffingwell is talking about.

Linda Cook: Crack that WIP - Introducing Kanban into an Organization

Okay... this was a really interesting talk. For one, the talk was centered around two infrastructure projects.... most everything so far has either been software or non-IT. To add another wrinkle, Linda's last project with this team was done using Scrum but Scrum created too much process overhead for the team. She decided to introduce Kanban as a way to eliminate waste and to right size the process.

As I am listening to the setup of the project, she describes the team as a set of experts that didn't want to estimate, didn't want to do any documentation, didn't want to use any user stories, didn't want to do retrospectives, did not want to do sprint planning, and had no need to review their outcomes. They did not have... or need... a Product Owner and did not have a need for a ScrumMaster. I was left after the setup wondering what separated this kind of process from just an ad-hoc get-it-done attitude.

The team did track and measure task completion on the Kanban board and they did do a daily stand-up meeting. As Linda explained the process further, it seems that her team was really going for aggressive elimination of waste, measurements around the flow of tasks, and making sure the team was getting to done by minimizing the amount of work in progress. With no process controls, no estimating, no understanding of the backlog, and no baseline against which to measure flow... how would you ever know when you are going to be done.

That is probably more my problem that Linda's problem. Linda's method sounds great for a support team with a continuous flow of requests... I can't get my head around how such a lightweight process would apply if there were any sense of constraints or controls... or if the team was less expert in getting their work done. I am hoping that either Linda or someone else from the conference will weigh in and help me understand this a little better.

Eric Landes: ChaMP Continuously Improving and Enterprise Development Group

Eric Landes has an environment that seems to lend itself pretty well to the kind of process I described in my summary of Linda Cook's talk. Eric's team was made of of 10 or so developers that were tasked primarily with handling a steady flow of services requests into the IT organization. The request... something he called a change request... is really what they were tracking as part of their Kanban process.

After implementing Kanban processes he was able to reduce the cycle time of a request from 41 days to around 9 days. This was done through the basic implementation of Kanban first and then by continuous improvement of the process and the focus on eliminating waste. Listening to Eric talk... the key to the success... like on most of these other talks... centered around limiting the amount of work in queue... and then subsequently work in progress.

Eric introduced a concept called a parking lot to keep track of all the work the team could potentially do. This work was pulled into the backlog, and at the point the item was in the backlog, it became in progress... this was the first and primary buffer. At this time they are not limiting buffer size within the WIP states. This seems to be because the entire team was developers. Eric is building disciplined practices around analysis and QA and could move to tracking intermediate states at some point... this could result in further improvement.

We had a pretty interesting side conversation around whether it is important to have a real visual board or is it better to use an electronic system. One guy in the audience... a master black belt... was a strong advocate for manual visual controls... Corey Ladas spoke up and talked about the use of large LCD screens in the team room area. Like most things... the answer is likely to be to very situationally specific. David suggested yesterday we use both as a best practice.

Kanban seems powerful... but is not rocket science. The common themes being expressed are really interesting. It is encouraging that we seem to have a somewhat common understanding of how this should be done. That said... the amount of variation driven by team characteristics and the local environment is powerful as well. We need to remember that none of this stuff... lean... kanban.. agile.. .is a one size fits all strategy.

Getting ready for the last three sessions of the day...

Subscribe to Leading Agile Subscribe to Leading Agile

#LK2009 Anderson, Scotland, and Hathaway

Here we are on day 2 of the Lean & Kanban conference... the focus shifts today from Lean to Kanban. David Anderson is giving the opening keynote... David Laribee from VersionOne is giving the closing talk. There are lots of great speakers in between and I cannot wait to hear what they have to say. Hopefully I'll be able to keep up with these summaries... David Laribee is promising a bunch of techno-talk... so we'll see how well I am able to keep up ;-)

David Anderson (Opening Keynote) Kanban-Applying Principles and Evolving Process Solutions

David starts his keynote by highlighting a problem with the Lean and Kanban community. We are trying to take a bunch of Japanese words and figure out how to apply manufacturing processes to software processes. David is encouraging us to stop trying to find the software equivalents to manufacturing and focus on the consistent application of principles. As a community we need to judge people by how well they apply principles of lean... not practices of lean.

David shared a few quick set of principles that are worth sharing here:

First he introduces five principles that managers can use to ensure their success as a manager: Focus on quality, reduce work in progress, balance demand against throughput, prioritize, and reduce variability to improve the process

Later in the talk David introduced an agile decision filter... ask yourself as you make decisions if you are applying these criteria: Are we making progress with imperfect information, are we encouraging a high trust culture, and are we treating work in progress as a liability rather than an asset?

His final list was a lean decision filter to help us make decision around applying lean practices: Value trumps flow, flow trumps waste elimination, eliminate waste to improve efficiency. As you are deciding what to do on a day to day basis, evaluate your decisions against these lean priorities.

David shared many of his thoughts on how to structure a Lean/Kanban organization. He has come to the conclusion that visual control are insufficient for managers and software based controls don't create the right culture of accountability. His recommendation was to use both... interestng. David's teams met daily to review the Kanban data and then broke into smaller daily standups if necessary. He held a monthly ops review, rather than the traditional agile retrospective, to ensure accountability and look for opportunities to improve.

David's talk emphasized that Lean and Agile adoption needs to be values based and underpinned by cultural change. Practices are going to be influenced by very situationally specific needs of each team. Management decisions and policies need to support the unique properties of the organizational culture and selected in such a way that we influence the organizational culture in the direction we need it to go.

There were lots of examples in this talk based on David's extensive experience with his current clients... his time at Sprint... and his time at Corbis. This is another one of those talks that you need to go find on InfoQ. There were lots of great, specific information about Kanban tools and techniques are extensive guidance on how David thinks some of these principles should be applied. Way... way... too much to include in this summary.

Karl Scotland: Kanban, Flow, and Cadence

Karl Scotland started his talk by explaining some of the language and basic principles behind Kanban. Kanban is a Japanese word that means visual cards and showed some pictures of Kanban systems from industry and software. He explains that Kanban is a way to improve productivity my limiting the amount of work in progress AND limiting the amount of work in queue.

It is pretty counter intuitive to think that if we put less work in the system we actually get more output from the system. This is based on Little's law that states cycle time is equal to the number of items in progress divided by the completion rate. To decrease cycle time... our ability to deliver... you either have to reduce the number of items in queue or increase the completion rate.

What I appreciated about Karl's talk was the specificity with which he described how his team implemented the process. He talked about the specifics of the features and drew some parallels to the INVEST model of story creation and how we can take larger features and epics and break them into something that could be put on a Kanban card and digested by the team.

Finally... I really liked how Karl was very explicit about buffers and limits and how a team would prioritize for finishing work rather than starting new work. One of the most common objections to lean/kanban is the fact that some people will be idle if there is a bottleneck in the system. Karl addressed this by talking about the kinds of things that folks can work on while they are waiting. They can basically work on anything that does not create work for a downstream process.

What does this mean? Well... they can do spikes, minor refactoring, or training. If they can find a feature that does not create downstream work, that could be done to. My personal opinion is that this one point is the most counter-intuitive part of the whole lean/kanban movement. Getting past this really gets to the ideas of continuous improvement, systems thinking, eliminating waste, and the entire lean value system.

Like I said... there was quite a bit of very specific guidance during the talk... but these were my key takeaways.

Rob Hathaway: Not Just Fun and Games Building the Mousebreaker Web Site

Today is proving to be much more tactical than what we heard yesterday. I guess that makes sense... Lean focuses more on principles and philosophies... Kanban is a specific practice within that overall framework.

Rob started his talk by stating that sustainable change is created by living the principles of lean and choosing practices that support the principles. He introduced several core principles that we have heard in most of the other talks: deliver value, prioritization, work in progress limits, and quality... and several practices that can be applied: minimum deliverables, releasing on demand, establishing visibility around MMFs, and the importance conducting reviews and retrospectives.

Rob encouraged us to focus on using smallest simplest process first...add more when and why the team or system needs it.

It has been interesting to see some of the different perspectives on what it takes to to effectively implement Kanban. Rob focused on the importance of collaborating with the business, the challenges with iterative delivery and the perceived need for certainty, and getting the executives involved early.

Like most of the speakers so far... Rob talked a lot about the specifics of his implementation and some of the challenges they faced along the way.

Subscribe to Leading Agile Subscribe to Leading Agile

Announcing the Formation of the Lean Software & Systems Consortium

Prior to the Lean & Kanban conference this week... I had the opportunity to participate in the formation of this organization... and as a result have become a founding member.   I'll give you more on my thoughts around this organization sometime next week.  For now... I want you guys to know this organization exists and open the floor for any questions.  

Consortium to Promote Lean Software & Systems Thinking For Software Intensive Enterprises

SEATTLE, WA., May 6, 2009 / PRNewswire. The Lean Software & Systems Consortium (LeanSSC) was formed today to assist enterprises that depend on software – from start-ups to those that build complex, software intensive products, systems & services – with the application of Lean Thinking throughout the enterprise.

LeanSSC is a global, non-profit organization whose mission is to promote professionalism and create awareness of lean science and associated competencies by creating and promoting a body of knowledge and an associated certification program. This body of knowledge will be organized around three elements of Lean Thinking – lean science, lean management and lean education.

LeanSSC will assist organizations in applying Lean Thinking to reliably deliver business value, adapt to changing market conditions, manage risk, improve predictability, increase flexibility and reduce variability – with the clear goal of substantively increasing the ROI of their software investment.

Founding member David Anderson noted, “It has been recognized for over 30 years that the role of management is the most significant leverage point on the economic performance of organizations that depend on software. During this period, management practices have not kept pace with innovations in software and systems development processes. The LeanSSC will bring Lean Thinking to bear on the organizational problem of creating software economically by providing a framework for better decision making and policy setting at all levels of the enterprise. We believe Lean Thinking adds value not only to individual contribution such as development, testing and analysis, but also to all levels of management.”

Other founding members also commented on the formation of the consortium:

“Lean Thinking brings an organizational solution to an organizational problem. I look forward to the LeanSSC making a substantial contribution to the industry.” – Dean Leffingwell

“The LeanSSC will help create a foundation of knowledge and foster a Lean Thinking paradigm shift that will greatly increase professionalism and improve outcomes in the software development industry.” – Alan Shalloway

“Enterprises building systems of significant scope have become increasingly lean, but not yet been able to engage its software development in this transformation. The LeanSSC provides the first practical mechanism to integrate software development into the lean enterprise.” – James Sutton

About Lean Software & Systems Consortium

Based in Washington, USA, LeanSSC is non-profit consortium comprised of corporate members, academic institutions, and industry leaders who share the belief that understanding and application of the science of lean will be of great benefit to software intensive industries. LeanSSC’s mission is to promote professionalism and create awareness of lean science and associated competencies by creating and promoting a body of knowledge and an associated certification program.

The consortium is committed to community, communication and education and will be hosting Lean Software & Systems Conferences in Atlanta, GA and Europe in 2010.

Founding members of the consortium include David Anderson–David J. Anderson Associates, Alan Shalloway and Alan Chedalawada–Net Objectives, Dean Leffingwell–Leffingwell, LLC., Don Reinertsen–Reinertsen & Associates, Karl Scotland–EMC Consulting, Rob Hathaway–IndigoBlue, James Sutton–Lockheed Martin, Mike Cottmeyer–VersionOne, Peter Middleton–Queens University @ Belfast.

Information on the consortium will soon be available at www.LeanSSC.org. For further information, contact David Anderson at dja@agilemanagement.net.

 Subscribe to Leading Agile

Subscribe to Leading Agile

#LK2009 Tabaka, Hsu, and Shalloway

Okay... I am on the verge of becoming a whiner here. All these talks are so good, it is exhausting to try and get them summarized in real time. I am surely missing many key and interesting points. I have a request out to the other conference attendees to comment on these posts to either add or correct any of my perceptions.

BTW - This will be the last post of the day but we'll resume the discussion tomorrow. Friday is Open Space so we'll have to see what to do about that one... not sure it will lend itself to that kind of summarization.

Jean Tabaka: Learning to be Lean

Jean has decided to take the room in yet another direction. Her talk centers around learning... and how we learn to be Lean. She kicks the talk off by introducing the 5 orders of ignorance. We move from having no process for discovery all the way to a lack of ignorance... actually being informed. She encourages us to be intentional about how organizations learn and how they can learn to adopt lean.

Jean's talk emphasized the idea that we have to be conscious about being systems thinkers... we need to stay focused on the whole. She discussed very tactical things like feedback loops and queing theory... but all that technical stuff was not really her main focus. She made the point that practices are secondary to how the organization thinks about itself and how it delivers value. She talks about how the mental the organizations mental model shapes how it behaves.

We need to focus on organizational change... how the transition is going to impact people... metrics... and compensation... and less on whether we implement Scrum or XP or Lean. Very often we implement practices without putting in the underlying scaffolding and how this can be detrimental to the long term success of any change initiative. My favorite point Jean made was that we need to look at the entire system... how the nature of the system needs to inform our thinking... and then how our thinking can inform our decisions about what tools we select.

Like everyone else, Jean's talk was very rich and full of great ideas and great examples... this was my best distillation of the essence of what she had to say.

Alina Hsu: Lean Beyond Software Development

Alina is a functional manager that has managed developers, testers, and analysts. Right now she is focused on lean process improvement as a consultant for her current company. Her focus is on IT service management and project management from more of a business perspective.

If you haven't noticed, I am writing these summaries in real time as the speaker is doing their talk. The model so far is to jot down all the cool thoughts, put together some summarization stuff on the fly, and then as the speaker is wrapping up... see if I can slam down a complete summary of the presentation. So... that said... I might have a better read on Alina's talk if I were paying more attention, but right now I am not sure where she is going.

Right now we are about 70% through the talk and she appears to be explaining the intricacies and challenges with a previous COTS projects. She is touching on the idea of respecting people and the need to optimize the whole. She introduces the idea of eliminating waste and delivering value and the impact of poor decision making, frequent delays, rework, and even wrong work.

As Alina closes the talk, she is discussing the need to define the big picture up front, timebox everything, short feedback cycles, standard work patterns, decision making and communication patterns, the importance of having flexible architecture. Okay... got it... I just needed everything pulled together a little bit. It is a bit ironic that a talk on Lean thinking seems to have focused on the parts with little attention to the whole.

If anyone else out there got more from this talk than I did, please chime in... I am wearing out so maybe I missed something early that could have tied it all together a bit better.

Alan Shalloway: Redefining Lean... Creating a Model to Understand Product (and Software) Development

Okay... I have formally worn out summarizing these talks so Alan Shalloway is going to get the bums rush. What's cool about Alan is that he has a vision for where all this needs to go and his passion comes through in how he talks about this.

Alan believes that the Toyota Production System does not equal lean but that TPS is a special instance of Lean. As we move Lean forward, the state of the art will come from the intersection of three angles: Lean Science, Lean Management, and Lean Education.

Just like Jim Sutton, Alan want to save the middle class but is not confident he is able to change organizational culture at scale. He does believe that through the application of lean principles he can help organizations get better. Simple things like colocation... limiting work in progress... single team assignments... putting everyone under the same manager...can cause a 3x improvement - even in a waterfall team.

If this is so simple... why aren't we doing more? It seems that we only change when we have pressure to change. Sometimes we know the right practice but we don't always do it because we don't know why it works.

Culture is an idea arising from experience. Lean practices support the organizations need to change... the practices support the mindset we are trying to achieve. Great talk... but I am ready for a beer.

Subscribe to Leading Agile

Subscribe to Leading Agile

#LK2009 Rathore and Ladas

The diversity of perspectives at the Lean & Kanban conference is really refreshing.  We spent the morning talking about Lean in the large... we have now spend most of the afternoon looking at Lean in the small.  I hope these summaries are giving you a good glimpse of the kinds of things we are talking about here.  

Amit Rathore:  Lean Software Development for Startups

 

Amit is a former consultant for ThoughtWorks but currently works for a small startup in the financial services industry.  David Anderson gave Amit a glowing introduction explaining that he is an excellent blogger... has figured all this out based on first principles... and that he really gets this stuff.  This talk is based on Amits learning and was really structured like an experience report based on his own personal experience.

 

Amit starts his talk by explaining that startups are defined by their constraints.  Startups have less money, less people, little domain knowledge, constant change, fewer customers, and not so many chances to be successful.  For a small startup, t is always a recession.  It is essential in this environment that you eliminate waste at every step of the value chain.  Speed is the only advantage that a startup has.  

 

Amit goes on to talk about how process, systems thinking, technology, culture, and people all have to work together.  Constant change is the norm so startups have to understand the flow from idea all the way to production.  You have to understand the relationship between the sales person all the way through the development process.  Things are going to change so we have to be as flexible as possible for as long as possible.  Amit introduced the idea of progressive elaboration all the way from idea to implementation.

 

His team uses set based engineering... does not estimate... breaks features into stories that can be implementated in a day or so.  A startup is so subject to daily change... it does not make sense to commit more than a day or so out.  Estimating features and preplaning... even sprint planning... is subordinated to establishing flow... establishing a steady throughput across the entire organization.   

 

This talk was a really interesting counterpoint to some of the stuff presented by Dean Leffingwell and Jim Sutton earlier in the day.  These guys were talking about using lean across the technology organization to coordinate activities across multiple teams required to deliver a higher order feature.  The ideas certainly apply across the entire value chain... but managing flow in a technically complex organization seemed to be the main message.

 

Amit is focusing on a much smaller... much more dynamic and flexible software organizations... organizations that are much more subject to frequent change.  He introduces more directly the idea of managing value streams across the entire organization.  Frequent delivery is key... Amit encouraged the audience to reduce batch sizes and deliver often.  If you are going to fail in a startup... you need to fail fast and adjust quickly.  Reduce cycle time and get feedback as soon as possible so you can get more done with much less.

 

Corey Ladas:  ScrumBan... Lean Thinking for Agile Process Evolution

 

I am starting to sound like a broken record, but pretty much everything Corey said during this talk was worth writing down.  Let me see if I can distill a few of the ideas around Scrum-ban... a blending of the ideas of Scrum with the ideas around Kanban.  One of the most interesting things that Corey had to say was that Kanban is not a process any more than a backlog is a process. Kanban is a tool that can be used in a particular context... to derive a particular value.

Kanban is built around the idea of a Kanban card.  The card can be thought of as a user story... a use case... a scenario... or a feature; something that adds value to the business.  The way Corey explains this is very similar to the way I think about a user story... something small and discrete that can be delivered within the context of a single iteration or sprint.  The idea is that the Kanban cards are tracked through the various states of development within the sprint... analysis, design, code, and test... but that we put limits on the number of cards that can be in any given state at any given time.    

 

Whereas scrum attempts to limit this work in progress implicitly by encouraging the team to finsih work as soon as possible... Kanban handles this explicitly by setting management control around how many cards can live in any one state.  It provides an empirical method for managing the flow of work throught the team... and a way for teams to collect data and understand opportunities within the team to get better.  It puts some teeth around the idea of inspection and adaptation... it gives us some data to understand where we have weaknesses... where we can improve... and how we can deliver working software faster.

 

The interesting thing about Corey's perspectve here... is that by introducing Kanban within the sprint... we can ultimately find that we no longer need the sprint boundares.  We can go iterationless and start thinking about continuous flow through the development team.  Even more interestng... you can now break the hold of the single product owner managing the backlog and think about flow outside the organization as well.  

 

If you read my blog... you'll know that I have been on a rant lately about the role of the Product Owner and how it is an insufficient metaphor for the complexities of the business. Kanban and Lean can extend the single piece flow idea out to the business and take a look at the entire value stream from idea... to customer delivery... to support and operations.  

So... my main takeaway was that Kanban can be used within the Scrum sprint to help teams manage their constraints within the normal sprint planning, sprint execution, and sprint closedown processes.   Once we have maturity, and a but of data, around how effectively we build software... we can then consider breaking the boundaries of the timebox and go toward a continuous flow.  

 Subscribe to Leading Agile

Subscribe to Leading Agile