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 Deborah Hartmann Preuss on Oct 24, 2006
With agile methods there's not much to study, thin books, beautiful books but thin! Whereas if you go to Unified Process, in particular Rational Unified Process, there's no one that ever will be able to read it completely... if you want to adopt it, there's no way you can adopt it without having coaches or mentors that help you. I wouldn't even try to adopt Unified Process without having people who have done it before. It's too expensive and too risky to do it. But that is how it is today; it won't be like that in the future.His vision includes collaborative 'Intelligent Agents' to help make sense of the possibilities inherent in a large methodology, automated agents which make customization recommendations based on usage patterns.
Transforming Software Delivery: An IBM Rational Case Study
Monitor your Production Java App - includes JMX! Low Overhead - Free download
Using Drools? See what you're missing! Get the Power of Drools with the Assurance of Red Hat
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!
Great interview, but the transcript has lots of errors.
When answering the question What actually is intelligence agents, is like the paper clip in Microsoft Word? Ivar talks about Expert Systems, not expo system, and Rule-Based Systems, not Ruby systems. Also, it's intelligent agent and not intelligence agent. Answering So what do you think about MDA? he talks about model and model-driven and not modern and modern-driven.
Hello Nikolay,
i've taken of those mistakes:)
Another great interview, Ivar really is a legend (in his own time I may add).
I think his views on agile development are very true. Agile development relies on the tacit knowledge of the developer's knowing what to do in software development (the process), and hopes that each developer has the same (or similar) tacit process. I also agree that most everything in the "agile manifesto" should be assumed by default - working with the client, incremental and iterative development, ...
However, I do think he left out one main difference (as I see it) between agile development and a more developed (for want of a better word) methodologies.
This is the fact that (as I see it) agile development sees the source code as the primary model for the development. To me, trying to capture analysis information, design information and all other information in the source code is a nightmare. The only thing it has going for it is that it removes the redundancy that usually (but not necessarily) exists if you have multiple models.
Cheers,
Ashley.
--
Ashley Aitken
Perth, Western Australia
mrhatken at mac dot com
On more thing I forgot to mention (that my memory was prompted by the article on pair programming) is that Ivar tended to portray pair programming as necessarily taking place between a senior developer (in a mentoring and coaching role) and a junior developer. I don't think this is meant to be the case, or need be the case. I believe that two reasonable developers using pair programming would develop better quality code than they each could separately and probably faster at that. There may even be a benefit to two junior developers working together (as long as they were prepared to refer to textbooks and other learning material etc.) For me, one of the benefits of pair programming is to help us be more disciplined, to help us stay focussed, and to help us get over any erroneous programming things we may do.
Cheers,
Ashely.
Pair progamming in general/theory is peer pair progamming, correct. However, pair programming with best ROI is what Ivar may be referring to. This works great to get junior developer on board for a similar thinking process. Considering the quatity of code written by Junior developer could be large in real world especially with Senior people getting involved in the so called "meetings". My real experience. Also, pair programming is viewed as a risk control strategy for single point failures especially for core modules.
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.
5 comments
Watch Thread Reply