My guess is that Ladas provokes extremes of like or dislike to his writing, depending on whether you happen to agree with him or not. Nevertheless I fall in the middle (well three and half stars rounded up perhaps!) as, while I do find the uncompromising ridicule of non-lean/less-lean processes somewhat wearing, I do think he's got some important ideas to share.
So I'm with the author on the main thrust of his argument, but just to dismiss eXtreme Programming for example as a reinterpretation of the V-model, seems less than just for one of the key advancing influences for agile in the first decade of this century. Similarly Scrum comes in for some merciless treatment - many people are going hate this book on an emotional level long before they parse the content - and especially if they interpreted the title as a description of an agile method that combines elements of Scrum and Kanban. That's not what Ladas means by Scrumban. He's discussing instead what evolution of process would take place if a team was using Scrum and adopted Kanban, while relaxing Scrum's rule-immutability. His answer is that many of Scrum's practices will change and you will end up with a much leaner process, with less work-in-progress, and independent cadences for queue replenishment, improvement events and releases. In other words you end up with a typical Kanban system. Hmmm... take care what you assume is in this book when you read the title!
Any way if you can get past his style, Ladas gives us some very interesting observations on Lean software development systems. In particular I found the "feature brigade" section fascinating - a discussion of how a Kanban process for software development could be built by analogy to a fire brigade's chain of buckets. The point about such a system is that it is self-levelling, since the point at which the fireman with an empty bucket meets the one with the full bucket is variable, depending on the current rate of working of the two participants. Such self-levelling of Kanban systems, if it can be achieved with simple feedback mechanisms like this, will lead to real advantages as they are scaled.
This is an idea worth persevering with the book for!
The Improving Projects blog from Huge IO (UK & Ireland) is primarily about products, organisations and projects... and how to improve them. As well as musings on agile processes, software engineering in general, and methods like Kanban and Scrum, there's advice here too for users of process planning, execution and improvement tools - and the metrics they can provide. https://uk.huge.io
Subscribe to:
Post Comments (Atom)
Breakout sessions that ensure everyone in the meeting meets everyone else
Lockdown finds us doing more and more in online meetings, whether it's business, training, parties or families. It also finds us spendin...
-
Ron Lichty is well known in the Software Engineering community on the West Coast as a practitioner, as a seasoned project manager of many su...
-
Cost of Delay (CoD) is a vital concept to understand in product development. It should be a guide to the ordering of work items, even if - ...
-
Understanding Cost of Delay (Part 2): Delay Cost and Urgency Profiles In part one of this series of blogs on Understanding Cost of Dela...
No comments:
Post a Comment