#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

#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

#LK2009 Observations from the Lean/Kanban Conference

We are only through the morning of the first day... and so far... each and every speaker has been worth the price of admission. David Anderson has done an excellent job of rounding up a world class group of folks to come and speak. We all know that David is passionate in this space and it really shows in his commitment to putting together a great event.

First, the Mardarin Orient Hotel in Miami, FL was an excellent choice of venues. The facility is beautiful and right on the water. We have great views of the ocean and a picturesque urban residential area on the other side of the waterway. The staff here has been excellent and their responsiveness to various requests has been stellar.

I am not sure this is what David indented, but this year is a pretty small conference. If I had to guess we have maybe 40 or so attendees and almost half as many speakers. What that means for those attending is that the density of thought leaders is very high. Many of those not on the formal agenda often speak at other conferences. The room is very full o really smart people.

The average age of attendees seems to be higher than at many of the other conferences. I haven't run around polling the crowd but I would guess the average age is at least 40... maybe a little higher. That probably speaks to the target audience for this particular topic. The Lean Kanban stuff is really aimed more toward effective management of software creation rather than the practice of developing software.

My guess is that this attracts a more seasoned audience.

The final thing I'd like to comment on is the overall structure of the conference. There are a lot of speakers but only one track. Every speaker, aside from the keynotes, gets 45 minutes to talk. This format has resulted in a few rushed presentations but really adds value for the attendees. The conference is really fast paced and no one has to choose which talk to attend. Everyone gets to hear everything.

I cant' say enough about how things are going. Like I mentioned, this is going to be replicated next year in Atlanta. You might really want to consider adding this to your list of travel destinations next year.

Subscribe to Leading Agile

Subscribe to Leading Agile

#LK2009 Sutton and Mortensen

This post is just going to get us through the morning sessions. So... next up I'll summarize sessions from Jim Sutton and Sterling Mortensen. We'll pick up Amit Rathore in the next post...

James Sutton: Let Lean be Lean, Let Agile be Agile, and Ever the Twain Shall Meet

James Sutton is the other author of the book "Lean Software Strategies: Proven Strategies for Managers and Developers". He is a systems engineer at Lockheed Martin, and much like Middleton, is not really an agile guy. Jim is bringing a very structured, large company, systems engineering approach to the conference. His voice is very welcome. This talk was so dense with information... it is going to be very hard to summarize. I understand that InfoQ is recording the sessions and will post them to their site... this is one that you'll want to find a take a listen.

Sutton says that his goal is the save the middle class in the US and he is not kidding. Jim believes that if we lose industry... if it all goes overseas... we will no longer have jobs in the US. His fundamental paradigm is that business in the West is focused on a unit cost model and that this way of thinking is killing us. As you might expect that his focus is on value streams and optimizing flow through the system. Jim starts his talk with some stats on the efficacy of various software models... he makes the case that agile is good and has value but that lean can improve productivity by 400% and quality by over 1000%.

After setting up the problem, Jim gives us some background on Demming and lays out the philosphical underpinnings of lean thinking. He emphasizes that while there are lean practices... lean is more of a mental model... a way about thinking about systems and organizations and a fundamental disposition to put people first. Jim goes on to talk about Demming's system of profound knowledge, systems thinking, and suboptimization. One of the most interesting comments in the talk was the distinction that lean introduces science into the idea of systems optimization where agile focuses more on how optimization emerges from the team.

After lots more talk around these ideas, Jim encourages us to take the tools of agile... and the tools of lean... to do the right amount of planning... but balanced with the legitimate need to just get started. I appreciated Jim's perspective that agile and lean are complementary worldviews and that we need to evaluate our particular context to decide what elements of each that we need to implement. All in all a very valuable talk.

Sterling Mortensen: A Case Study, Hewlett Packard LaserJet Development

Okay... this is going to kill me. Every one of these speakers so far has been absolutely fantastic. I was thinking that this talk from Sterling Moretensen would be pretty dry... after all we are talking a case study here. I am pleasantly surprised once again to find myself with way more information than I am ever going to be able to report on. The takeaway density of these talks is really through the roof.

Sterling starts his talk explaining the situation he faced at Hewlett Packard. The number of products were growing rapidly... products were getting more complex... the number of features were growing rapidly... all while they were moving to a common, shared services type software platform. Things got so complicated... there was so much work in progress... the organization could not do anything and defect densisty was through the roof. Like most of the other talks we are hearing today... HP solved the problem through the application of lean and agile principles.

Sterling's teams focused on small batch sizes... trying to deliver smaller features... and focused on delivering them on a fixed cadence. What they found was that by taking work out of the system... by reducing complexity... they were able to unstick the organziation and actually get features delivered. They found that as complexity goes down... productivity goes up. By delivering in a fixed cadence... by decreasing the time it took to get feedback... quality actually went up.

Many managers... especially Marketing managers (little jab there)... think that the more features you put in the queue... the faster work will come out. The metaphor is that of a hydraulic system. What HP found was that the development team was more like a highway... more cars don't increase flow... they increase complexity... and the flow of value actually goes down. Taking work out of the system... focusing on done....reducing cycle time and feedback loops all dramiticaly increased overall system performance. We need to stop starting work and start finishing work.

My favorite quote of the talk said something like... if you optimize all the parts of a system, the system is not optimized. If you optimize the system itself... only a single part will ever be optmized. Said another way... in an optimized system you will only ever have ONE single part optimized. That is so counter-intuitive to most folks. Again... I appreciated Sterlings acknowledgement that agile and lean are very complimentary approaches to software development... that teams and iterations can have a place in a lean framwork.... and that it takes good engineering practices to really achieve the flexibility and productivity that agile and lean promise.

Overall a great talk... really appreciated Sterling's contribution.

Subscribe to Leading Agile

Subscribe to Leading Agile

#LK2009 Shalloway, Leffingwell, and Middleton

I've been down in Miami all week at the Lean/Kanban Conference. The conference didn't actually start until today but I came down early to participate in a few meetings and ended up having a voice in the future of the Lean/Kanban movement... more on that in a moment. For now... I want to let you in on what's going on down here... why it is important... and maybe... just maybe... give you a few anchor points for our discussion on scaling agile in the enterprise.

Alan Shalloway: Opening Remarks

Alan Shalloway got the conference going with a few opening remarks around what's getting him excited about the lean movement. When agile was introduced it opened up new possibilities for how we write software. Lean represents a similar paradigm shift in the software community. Alan is a scientist at his core and appreciates the science behind lean and is pretty geeked on the idea of utilization theory... options theory... and flow theory. Lean will give software practitioners a scientific language to describe the process of creating software.

Alan announced the creation of a new organization to support the lean community. The organization is called the Lean Software and Systems Consortium... creating this organization was the reason for the pre-conference meetings.

The Lean Software and Systems Consortium will support the lean community by gathering a body of knowledge, establishing a set of competencies, creating a new certification for practitioners, and reaching out to business and academia for accountability, support, and feedback. The consortium will support an annual conference and a multi-tiered membership model. Speaking of the annual conference... the next one will be in Atlanta in 2010... venue to be announced.

Dean Leffingwell (Opening Keynote): A Lean and Scalable Requirements Information Model for Agile Enterprises

I've been a big fan of Dean Leffingwell for a while now. His book Scaling Software Agility is probably the most clear... well reasoned explanation of doing agile at scale that I have ever read. As we've been exploring here for the past few months... agile at scale is not a trivial problem... and that means the solutions are not likely to be trivial either.

Dean starts his keynote by explaining some of the basics of agile software development and why certain practices break down when you start to scale. He addressed some 'controversial' ideas like agile architecture, component teams, and managing dependencies across multiple agile teams. His talk leverages pretty heavily his recent work on a Lean Scalable Requirements Model but never really got into the Lean concepts that are required to make it all work.

During the Q and A session, Dean began to address the idea of creating a pull system to drive requirements across the team of teams concept. I totally agree with Dean's approach and really respect his work. You are going to see me explore some of these ideas over the next few weeks in my blog posts. That said... I think his keynote missed an opportunity to directly link lean into his lean agile requirements model. Dean's explanation of his model brought up issues that many in the software development community really needed to hear and he delivered a great talk.

Peter Middleton: Lean Software Development, Achieving Better Requirements

Peter Middleton is the co-author of "Lean Software Strategies: Proven Strategies for Managers and Developers". He is an academic at the Queens University in Belfast and has been researching Lean for the past 20 years. Peter writes about how lean will have an impact on the software community going forward.

Peter's talk starts with the fundamental assumptions of agile... agile methodologies assume that there is a high level of noise in the system... that requirements are evolving... technologies are evolving... and we just need to do something to make progress in the face of uncertainty. Peter's perspective is that this is a flawed paradigm... he postulates that the reason we don't understand our requirements is because we don't understand our purpose.

The talk focused on the idea that much of our problems with software requirements is that we have too much noise in the system.

Lean can help us reduce that noise by identifying our failure modes and improving them first. Middleton says that we should focus on what delivers value to our customer and work to optimize that value delivery. Getting there is a non-trivial problem... it involves reducing variability in the process... establishing the correct measures, constraints, and context... making sure your KPIs drive the right organizational behavior.

Taking the noise out of the system helps our requirements become more stable. Cleaning up the noise will help you improve performance but getting people to see this is the real challenge. Many folks have quite a bit invested in the status quo. To lead change you have to take a more indirect approach. As change agents we have to design an experience that lets the leadership team see the problems for themselves. Software is often not the problem... we need to address the bigger constraints in the system.

Next up... Sutton, Mortensen, and Rathore

Subscribe to Leading Agile Subscribe to Leading Agile