Posted on October 28, 2014 by
Agile software development methods, with the exception of Feature-Driven Development, adopt the use of fixed time increments, often wrongly called “iterations”. In Scrum, these are known as Sprints. A Sprint is a fixed period of time with a defined scope and a commitment to complete that scope within that time window. Originally, Scrum defined 4 week sprints. This was changed later, circa 2004, to a recommendation for 2 weeks to be the default length for a sprint. In general it is recognized that agility is related to the frequency of interaction with the customers or business owners, and the frequency of deliveries. Hence, smaller timeboxes are more desirable. Software quality is often related to batch size and time to complete work in a non-linear fashion, hence, smaller batches, completed in short periods of time leads to dramatically fewer defects.
As a result of all these advantages, organizations adopting Agile software development methods, have been under pressure to adopt the use of shorter and shorter timeboxes for their sprints or iterations. On the face of it, smaller timeboxes and hence smaller batch sizes for the sprint backlog, are a good thing. However, smaller timeboxes create two types of pressure that are often difficult to cope with and adjust to: firstly, smaller batches require an ever more detailed approach to requirements analysis and development – the need to write every more fine-grained stories which can be completed within the smaller time window; and the need for an ever more accurate approach to estimation, so that a realistic commitment can made.
Posted on January 18, 2014 by
In the fourth in my series of short blogs, I'm looking forward to this new year of 2014 and beyond, "Now that the hipsters have gone!"...
Posted on January 17, 2014 by
In the 3rd of this series of short blog posts, I'd like to examine another antipattern in use of kanban systems in consulting and change initiatives. This is the last of the antipatterns for now but it won't be the last of this series of short blog posts.
In this antipattern, a consultant designs a defined process, either uniquely for their client, or out-of-context as a defined off-the-shelf solution that they document and publish in some form. This defined process includes the use of a virtual kanban system and so they claim this is "Kanban" rather than give the process a specific name...
Posted on January 17, 2014 by
In the second in this series of short blog posts, I'd like to take a look at another common antipattern in Kanban adoption - the use of a kanban board and the claim that "we are doing Kanban now" as a smokescreen for no change at all...
Posted on January 17, 2014 by
I have been storing up a series of short blog posts which are too long for a tweet but typically shorter than a full blog post. I've decided to publish them all separately so that they have separate URLs and can be indexed and referenced separately. This is the first of this series...
"After we started Kanban quality suffered because we stopped testing!"
This is just one of the many bizarre claims that I've heard over the last couple of years that fall into a general category of an organization discontuining some vital practice or knowedge creating activity allegedly because they adopted Kanban. I found these claims so bizarre that I could not fathom how they would come see things this way. Back in November I figured it out!...
Posted on October 24, 2013 by
Flow efficiency is the measure of the percentage of time we actually spend actively adding value by working on an item as it flows through a system, as illustrated on this kanban board.
Posted on September 27, 2013 by
Lean Kanban University, Accredited Kanban Trainer (AKT) credentials are available to internal corporate trainers as well as trainers from independent training firms. There is a class of LKU membership called Internal-Corporate AKT. Such trainers are able to teach certified Kanban training classes internally at their firms and issue Lean Kanban University certificates to attendees.
Posted on August 17, 2013 by
Over the last few years, I have been told on many occassions that Kanban needs to add specific guidance for: requirements definition and work breakdown; holding conversations; software architecture; holding meetings about improvements; negotiation; and most recently a governance solution. Sometimes, this advice is couched with a condition such as "Kanban won't scale unless you add _____".
The natural reaction when challenged like this is to reply with, "Indeed! I'll get right on that!" or "We already have a solution to that. We teach it. I've presented it at conferences but I haven't written it in a book yet." The natural response is to want to make Kanban bigger.
I'm not going to do that! I'm not going to make Kanban bigger. In fact, I'm seeking to make it smaller and tighter. Here's why...
Posted on August 09, 2013 by
So another Agile Conference in North America is over. Once again, perhaps for the 7th year running, we've heard a number of leaders in the Agile community promoting the idea that you should focus on doing the right thing - discovering what customers really want and need - rather than focusing on building and deploying working software. The argument goes that there is no point in "doing the wrong thing faster." This sounds bite always makes the speaker sound very smart and it catches attention. It's also used to sell a variety of requirements solicitation and discovery techniques as well as various flavors of product management (or methods for product ownership to use arcane tribal Agile language.)
I deeply disagree with this and I have done since 2005 when I first heard it suggested by one of my fellow co-founders of the Agile Project Leadership Network. I truly believe that building capability to "do things right" must take the lead. Here is why...
Posted on July 31, 2013 by
Increasingly this year I'm being asked to comment about the Scaled Agile Framework (of SAFe) being offered in the market by Dean Leffingwell (and others). One of the main Agile project management software vendors is pushing it very heavily with their clients as a solution to the increasingly recognized problem of scaling Agile adoption in large corporations. It is gaining some market traction. In two specific examples, both large corporations, one in the healthcare sector, one in the DACH region of central Europe and the other in North America, Kanban advocates have had some concerns about their firm's large scale move to adopt SAFe and asked me to share my thoughts with them. I thought I'd share them with everyone else too...