Posted on July 15, 2015 by
The Kanban Method was conceived as an alternative path to agility - as a means to improve responsiveness and adaptability without any significant revolution or reorganization in your way or working or political structure of your business. Lean Kanban University has recently introduced a series of training classes developed and evolved from older, tried and tested curriculum to ease adoption of Kanban and communicate the full scope and scale of what is possible when you fully embrace Kanban as a way to manage your modern professional services business.
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 July 31, 2014 by
This fall, we are introducing a new curriculum to our class offerings - Project Management with Kanban. Note the subtle choice of title - "Project Management with Kanban!" It isn't "Kanban for Project Managers." Kanban for Project Managers makes as much sense to me as "Kanban for Refuse Collectors" Why would such a class be different from say, "Kanban for Grandmas"? It's all just Kanban! Perhaps the case studies and examples might be different but the curriculum would be the same. On the other hand, Project Management with Kanban" offers us the chance to provide a new curriculum, specifically targeted at managing project where kanban systems are in use and the Kanban Method is part of the organization's management approach.
Posted on July 21, 2014 by
Success has many fathers! Recently, there has been some content published elsewhere on the web that seeks to re-write the history of the adaptation of kanban systems into the field of creative knowledge work. The individuals publishing these alternative versions of history are generally doing it for self-serving reasons or in some cases as deliberate misinformation to try and undermine my business. To put the record straight, I've compiled this definitive history...
A History of Kanban for Creative Knowledge Work
Dragos Dumitriu, manager XIT Sustaining Engineering at Microsoft, asks me to help him. I design a pull system for Dragos' group and coach him on how to introduce it. He "sells' the idea to his bosses and his 4 product managers who act as his customers. The pull system was implemented on Microsoft Product Studio (a forerunner of Team Foundation Server). There was no physical board. The engineering team was offshore in Hyderabad, India. The system implemented was inspired by Theory of Constraints Drum-Buffer-Rope and worked on the assumption that Test was the bottleneck.
Posted on January 28, 2014 by
In the 4th of my short series of short blog posts, I look at the antipattern of people claiming "We're following the Kanban process."...
Posted on January 28, 2014 by
Recently, we've seen a lot of activity in the marketplace focused on "scaling Agile." It seems after a decade or so, people have been willing to admit the "Scrum of Scrums" concept just wasn't cutting it. There is now sufficient evidence of large scale failed Agile transition initiatives to know that previous decade's hypothesis about delivering large scale Agile adoption hasn't worked. Now we have a new wave. IBM has DAD (Disciplined Agile Delivery) and Dean Leffingwell and Rally Software Development have SAFe (Scaled Agile Framework). Other tool vendors in the market are encouraging emergence of "me too" scaled Agile solutions.
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 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 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...