Friday, March 20, 2009

Kanban & Planning and Estimation

And while we’re on the topic of Kanban controversy against Agile practice stalwarts (Kanban & Retrospectives), let’s revisit Kanban & Planning and Estimation ...

I’ve reported in the past how some Kanban teams eliminate estimation altogether and reduce planning to a very simple prioritization scheme to re-fill slots in the input queue. It’s worth discussing whether or not these are prescriptive foundational elements of Kanban or whether they are in fact choices made in specific situations?

First, let’s look at estimation. Kanban teams often eliminate estimation except when they don’t! What Kanban exposed was the fact that not all requirements or requests are equal from a risk perspective. Some requests carry a significant risk from late delivery due to the nature of their cost of delay (or cost of failure) curve, also known as the market payoff function. If for example, failure to deliver a feature on a given date would result in a Federal government fine for breaking the law, then we can describe this as a unit step cost of delay function with a defined tangible cost. Kanban teams treat requests like this differently from other types of requests. In fact Kanban teams typically create several classes of service - 4 or 5 is typical. Classes of Service are delineated (usually) with different colored tickets on the board and through different prioritization policies. It is normal for higher classes of service to require some form of estimation. The significant cost of delay that can be incurred through late delivery has to be mitigated through estimation and the use of the estimate to facilitate prioritization into the input queue in an optimal fashion. Early enough to insure delivery, not too early as to displace something that might be more valuable at an earlier date.

So, Kanban teams eliminate estimation when the risk profile says it is appropriate to do and don’t when it doesn’t.

What about planning?

Well planning is different in Kanban. A release cadence needs to be agreed based on the transaction costs of delivery/deployment. An input cadence needs to be agreed based on the transaction costs of convening the stakeholders and the coordination cost of bringing them together to discuss the input queue. A standard class of service level agreement with a cycle (or lead time) needs to be agreed as a target for delivery. As for planning in terms of selection of items in the backlog, this is done as late as possible on as little of the backlog as possible. It’s a very Lean approach to planning.

It’s not that there is no planning in Kanban but it is a different approach to planning than either traditional project management or more modern Agile methods such as Scrum.

Related Posts: Kanban & Retrospectives, Kanban in Action. Technorati tag: David+Anderson, Agile+Management, Agile, Lean, kanban, Software+Engineering, Project+Management

Kanban & Retrospectives

There’s been some chatter on the discussion lists and Twitterverse recently on the topic of whether Kanban practitioners view Retrospectives as waste (in Lean Thinking terms).

Heck, Kanban has already cocked a snoot at Agile Holy Grails such as time-boxed iterations, and planning and estimation, so why not retrospectives as well?

So the record needs to be set straight on this. Some clarity and signal needs introduced amongst the noise.

Some mature Kanban teams did drop the use of retrospectives. No one told them to do it. They just did. Retrospectives were not adding value in their lives and hence were seen as a wasteful activity that could be eliminated. How did this come about? Well, firstly the management (that’d be me) had encouraged a culture of continuous improvement and a focus on objective quantitative management. The organization was holding a monthly operations review to reflect on performance. So, there was already a monthly retrospective opportunity built in to the working lives of team members. Secondly, mature kanban teams were capable of releasing (or integrating in the case of major projects) every couple of weeks or so, with a negligible defect count. Things went very smoothly so there wasn’t much to discuss. And thirdly and most importantly, the institutionalization of a culture of continuous improvement had created what was known as the “after meeting”, when folks huddled together after the morning standup meeting to discuss issues that often led to improvement opportunities. These spontaneous meetings were equivalent to what in manufacturing is referred to as a spontaneous quality circle. This empowered self-organizing type of self-affiliating quality/improvement group has only been seen in some of the most Lean of companies. Kanban seems to facilitate it in software development.

So, to summarize… teams that were part of an organization that gathered objective data, held a monthly operations review (and walked the walk, not just talked the talk) on organizational performance, and teams that delivered with a mature regularity, reliably and predictably, and teams where the culture had matured sufficiently that spontaneous quality circles were forming after daily standup meetings, found iteration (or release) retrospectives to be of little added-value and dropped them from the process.

Teams that did not mature to this level tended to keep retrospectives as part of their process. While the very mature teams would still hold a retrospective when something extraordinary happened - such as a botched release. In this case, retrospectives were being used in an event driven manner to perform casual analysis and resolution.

So it’s horses for courses. Kanban can enable a team to reach a level of maturity where they may choose to eliminate retrospectives (or not.) It’s a choice! Every situation will be unique. The important thing is not to see elimination of retrospectives as wrong or bad or “not agile.” Equally, don’t rush in and eliminate retrospectives. Don’t proscribe retrospectives. Let the team make its own decision when it is ready and embrace the evolution of process that comes with continuous improvement. Technorati tag: David+Anderson, Agile+Management, Agile, Lean, kanban, Software+Engineering, Project+Management

Thursday, March 19, 2009

L&K2009: Dean Leffingwell Opening Keynote

Dean Leffingwell will be the opening keynote speaker at Lean & Kanban 2009 in Miami on May 6th. Register now for the whole event at the early bird rate of $700, or for the one day Lean event May 6th only at $335.

A Lean and Scalabe Requirements Information Model for Agile Enterprises

Agile development practices introduced, adopted and extended the User Story as the primary currency for expressing application requirements within the agile enterprise. However, as powerful as this innovative concept is, by itself the user story does not provide an adequate construct for reasoning about investment, system-level requirements and acceptance testing across the enterprises project team, program and portfolio organizational and system hierarchy. Building enterprise-class software systems in an agile manner requires a richer model for discussing requirements-related concepts including not only user stories, but Investment Themes, Epics, Features and Nonfunctional Requirements as well as the various types of acceptance testing that helps assure system quality. In this tutorial, Dean Leffingwell describes a Lean and Scalable Agile Enterprise Requirements Information Model that scales to the full needs of the enterprise, while also providing a quintessentially agile subset for the agile project teams that do most of the work. This model has been developed and applied effectively in a number of very large scale agile enterprises, some supporting thousands of practitioners.

Dean Leffingwell Bio

Dean Leffingwell is a consultant, entrepreneur, executive and technical author who provides product strategy and enterprise-level agility coaching to large software enterprises. Recently, Mr. Leffingwell was founder and CEO of consumer marketing identity company ProQuo, Inc. Mr. Leffingwell has also served as chief methodologist to Rally Software. Formerly, Mr. Leffingwell served as Vice President of Rational Software, now IBM’s Rational Division, where he was responsible for the Rational Unified Process. Leffingwell was also co-founder and CEO of Requisite, Inc., makers of RequisitePro for requirements management. Mr. Leffingwell has been a student, coach and author of contemporary software engineering and software development management practices throughout his career. His is the author of Scaling Software Agility: Best Practices for Large Enterprises and Managing Software Requirements: First and Second Editions, all from Addison-Wesley. Technorati tag: David+Anderson, Agile+Management, Agile, Lean, kanban, Dean+Leffingwell

Monday, March 09, 2009

L&K2009 Highlights: Amit Rathore

In the 2nd in my series to promote the Lean & Kanban 2009 conference, I’d like to highlight Amit Rathore (former Thoughtworker) and promoter of Lean Thinking in software development. Amit is proof that several people can follow the same line of thought independently and come up with almost identical solutions. I’ve been a big fan of Amit’s blog. I’m looking forward to meeting him in person at the conference. Amit will be presenting on May 6th, Lean Day in Miami.

Lean Software Development for Startups (or Why Agile isn’t Enough?)

If you’re in a startup, then you know that statistically, the odds are heavily against you. Pretty much the only inherent characteristic of a startup that can be counted upon to help, is that of its small size. If the company can be nimble and agile, then it can hope to gain some traction against its larger rivals. In such an environment, using an Agile methodology is a given. Without some form of a hyper-iterative software process, it is impossible for a startup to create a successful product. Or even to determine what that product is! In todayʼs climate, exacerbated as it is due to competition, lower capital requirements for software companies, the compression of Internet time, and the recessionary economic conditions, it is no longer enough to just use an Agile method. To stay competitive, indeed to just survive, something more is required. Lean Thinking provides just such an advantage. A startup needs to ground its philosophy in Lean Thinking, Theory of Constraints, Critical Chain, Queueing Theory, Systems Thinking, and the like. It will obviously gain from the long-term focus, throughput-based accounting, and value-based constructs that these provide.

Amit Rathore Bio

Amit Rathore has been using agile methods since 2001 - and has more recently been a thought-leader in the lean software development community. He spent nearly seven years at ThoughtWorks working on a variety of projects in several domains - at large and small organizations. He’s played several roles during this time - developer, architect, and project manager. Amit has been writing about his experiences at http://epistemologic.com and at http://s-expressions.com .

In the middle of 2008, he became part of the founding team of a startup based in Mountain View, CA. He’s leading the software development effort in this organization - and he’s been using lean techniques in order to do maximize what is doable, given the limited resources at the fledgling startup.

Register today for all 3 days at Super Early Bird price of $550, or Lean Day May 6th only at $335. Technorati tag: David+Anderson, Agile+Management, Agile, Lean, kanban, Amit+Rathore

Friday, March 06, 2009

L&K2009 Highlights: Peter Middleton

I’m going to do a series of blog posts highlighting content at the Lean & Kanban 2009 Conference in Miami May 6-8. Starting with Peter Middleton, co-author of Lean Software Strategies. Peter will be presenting on May 6th Lean Day at the conference.

Lean Software Development: achieving better requirements

Abstract: Agile approaches help by acknowledging the uncertainty and noise that surrounds software development projects. Their solution to this is evolutionary or emergent development. The question now is how can we improve on this? How to make the requirements process more objective and rigorous? The presentation suggests that a lack of rigorous requirements data can lead to sub optimisation and solutions that lack end customer focus. The next wave is to understand why customers interact with the organisation and then put those interactions under statistical process control. The evidence available for the strength of this approach is substantial

Peter Middleton Bio: Dr Peter Middleton MBA is a Senior Lecturer in Computer Science at Queen’s University Belfast, Northern Ireland. His PhD in Software Engineering is from Imperial College London. With James Sutton he co-authored the book: ‘Lean Software Strategies’ which explored the application of lean ideas to software development. His current work is on putting customers’ interactions with an organisation under Statistical Process Control (SPC). The SPC data shows precisely the organisational performance customers are experiencing and therefore the current capability of an organisation to deliver it’s services. Performance gains in the order of 40% are normal when change based on this data is implemented. The proposal is therefore the Agile and Lean methods should evolve to incorporate this technique.

Register today for all 3 days at Super Early Bird price of $550, or Lean Day May 6th only at $335. Technorati tag: David+Anderson, Agile+Management, Agile, Lean, kanban, Peter+Middleton