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 Mike Bria on Jun 17, 2009
Adopting agile is not easy. Many organizations often struggle trying to squeeze the practices of Scrum or XP into the way they work. Mike Cottmeyer offers a reminder to such organizations that placing too much value in the "how" of agile may be a misguided approach.
Cottmeyer asserts the following:
Getting straight about what we are are actually trying to accomplish with our teams will help us get past some of the dogma, methodology battles, and Scrumdamentalism that is preventing us from incrementally adopting agile practices. Is our goal to adopt Scrum or is our goal greater business agility?
Mike goes on to explain the reasons he believes its most important that teams "deliver value" while being "accountable", "predictable", and "transparent", and that they "get better". Following this, he gives his view on why each of those things is more important than teams having "Product Owners", "Scrum Masters", "Planning Rituals", and doing "Daily Standup Meetings".
He asserts that not having a similar value system could actually be your impediment to successful agility:
[Certain Scrum or XP practices] could be out of sync with your organization and actually impede your ability to adopt agile. You might need to think about what you're really trying to accomplish and come up with some situationally specific strategy to build teams... and to get teams predictable.
It might be unreasonable to ask the business to take a Product Manager and turn them into a Product Owner. It should be perfectly reasonable to ask them to make sure teams have the requirements they need to build software... requirements that accommodate change... help mitigate risk... and deliver value better and faster back to the business.
Jim Shore has previously discussed related ideas, well worth checking out after reading Mike's original post.
Transforming Software Delivery: An IBM Rational Case Study
18 agile and lean practices for effective software development governance
SCM best practices for multiple processes, releases & distributed teams
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!
Thanks Brian, great addition!
Scrumdamentalism - very nice term!
However, I think not enough attentiion has been paid on the distinction between a solution that is designed and a solution that emerges. See this - setandbma.wordpress.com/2009/06/18/why-am-i-unc...
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.
3 comments
Watch Thread Reply