Jesper Boeg on Priming Kanban
In this interview, Jesper Boeg, author of the new InfoQ book – Priming Kanban, discusses the keys to using Kanban effectively, and how to get started if you are currently using other approaches.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Mark Levison on Jun 02, 2008
Once you're team has released the first version of a product you're faced with the dilemma - how to maintain the first version while continuing to make progress on new releases. Facing this problem Michael Dubakov, CEO and Founder of Target Process wrote about their experience in "Should We Have Parallel Releases and Iterations in a Project?".
In this case Michael wanted fixes for version 1.0, ongoing work for 1.5 and new features being developed for 2.0. Do we have a single team because its only one project? Within that team do you assign some developers to release 2.0, others to 1.5 and steal time from Joe (the sacrificial developer) to fix critical issues in 1.0? For Michael the conclusion was to minimize waste and not work on 2.0. With all the developers focused on 1.5 we've reduced multi-tasking and are making decisions as late as possible (after all those must 2.0 features might not be must have by the time 2.0 rolls around).
In Steve Campbell's experience this problem is best solved when by including all the work (for all versions) in a single Sprint Backlog. The result any team member can pull a task (whichever the release) and work on it. Steve goes on to discuss branching strategies for this situation: either don't branch at all (using a runtime switch to differentiate versions) or branch only components that are undergoing a major rewrite.
Matt Swaffer, of Eclipse Software Systems Inc, uses a very different approach. His team doesn't ship patch releases, instead their goal is to maintain the stability of the trunk, then if a bug fix is required the customer is just invited to download the latest build. In addition they tag every release and in the event of a critical bug can go back to fix it. His ultimate goal weekly releases.
Switching to the issues around releasing several products from a single code stream, Kent Beck author of Implementation Patterns, talks about a two projects he's worked with that had to support seven customers. Each project had a fair amount of custom code in addition to the core logic. In one case they maintain separate code bases for each customer. When a new customer is acquired they clone the "freshest" branch and continue developing. As Kent notes they're sinking under the weight of their merges. On the other project a single binary is delivered to all customers in this case they found a way of making sure that only correct batch of custom code is run for each customer. In Kent's opinion the key difference is:
The key difference between the two is finding ways to defer binding. What I found was that this began by choosing a principle--we are going to have a single code base. This eliminated some design options, but plenty still remained. Another important principle is that in the first case we don't mind having some duplicate code. If it's clear how to eliminate duplication, we do, but we are willing to wait for clarity.
Finally John A. De Goes, of N-BRAIN says:
Branches are a form of waste and the goal is to eliminate them, to move to a single code stream, whose most recently released version is the only supported version, which is forcibly pushed to all installations on every release, with releases happening as frequently as possible (ideally, one release per feature/defect). All of which is made a lot simpler with SaaS.
Transforming Software Delivery: An IBM Rational Case Study
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
In this interview, Jesper Boeg, author of the new InfoQ book – Priming Kanban, discusses the keys to using Kanban effectively, and how to get started if you are currently using other approaches.
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).
Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
No comments
Watch Thread Reply