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 Amr Elssamadisy on Feb 23, 2009
In this interview with Brian Marick at last year's Agile 2008 in Toronto he tells us all about micro-scale retro-futurist anarcho-syndicalism. What IS micro-scale retro-futurist anarcho-syndicalism? You don't know what it means? That is the point, Marick states:
I made it a practice at times in my career to pick names that are so incomprehensible that nobody can possibly have any preconception as to what I am talking about so they will have to ask.
In this interview Marick shares with us his ideas on how to go back to Agile's roots and have people come of teams saying "this is the best project I've ever worked on" instead of we suck less.
He also goes back to what he thinks are mistakes in the Agile manifesto and tells us about his current plans to implement his ideas that, if successful, will take us back to the glory days of the original Agile movement.
Transforming Software Delivery: An IBM Rational Case Study
SCM best practices for multiple processes, releases & distributed teams
agility@scale eKit: 10 Principles, Scaling Model, Metrics, Collaboration
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!
Agile has lost its fire because its become a religion. Its a bunch of must-do things with the reasons to do them disappearing from center stage (ie. by the rules, for the rules, and nothing but the rules forever, amen).
One thing is for sure, rule based behavior will ultimately fail. The reason is simple. The rules were developed in a certain narrow context. They worked in that narrow context. However, that they worked spelled their doom. The context changed. It always does. The change was not noticed. The rules were followed. The process failed but the rules could not be at fault because they were the "right" rules. The rules continued to be used and they continue to produce failure.
But...but...but...Agile works. Does it? Well... its popular ... its used in more and more places ... everyone knows that .....
No Agile doesn't work because its no longer agile. Its a vast set of REQUIRED practices. Its sacred *Rules* are to be slavishly follow without knowledge, understanding, or thought and especially without modification or exclusion. Its a crank you *must* turn that is supposed to produce results.
Agile has lost connection with the one thing that made it agile: the fundamental human values that made work worth doing for its own sake. Values guide action within context and assist achieving purpose in a changing environment. Rules dictate action without regard to context or purpose beyond following the rules.
What everyone knows must be questioned. What everyone does must be challenged. Those who insist on the sacred *Rules* be followed must be required to prove they apply to the given task and that they support the intended purpose. Further, they must prove that the intended purpose is coherent with the fundamental human values that make work worth doing in the first place. Once that is accomplished, the fire will return and Agile will once again become agile.
Is Agile, agile enough to do this? At least Brian appears to be moving in that direction. It remains to be seen if the Agile Gods are so inclined.
Me? I am a Micro-Scale Retro-Futurist Anarchist team of one. I was agile before Agile hit the ground and started to crawl. I still am agile. Agile? No way! I don't follow the sacred *Rules*. I follow the values in context to meet a purpose that matches the fundamental human values.
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.
2 comments
Watch Thread Reply