Published by admin on 29th July 2009
I always love posts like this one on InfoQ. Vikas Hazrati has collected various lists of agile practitioners’ favorite books on the topic. For anyone wanting a quick guide to learn more about agile development, this is an excellent start. Even if you’ve been practicing agile for a while, you might encounter a book you haven’t read yet. Personally, I was a big fan of Tom DeMarco’s Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency, so I was glad to be reminded that I should get my hands on a copy of DeMarco and Timothy Lister’s Waltzing with Bears: Managing Risk on Software Projects…
Published by admin on 1st July 2009
Most forward-thinking software organizations have already accepted that they need to be agile in order to compete in a market whose evolution is accelerating faster than ever before. Of course, being “agile” is a fairly vague descriptor. However, those readers who have successfully implemented agile management and engineering techniques at their organization know that for the vagary embedded in the phrase “agility,” real organizational change occurs through very specific activities. That is, agility entails much more than simply declaring one’s self to be agile. Instead, true agility is the result of dedicated observation of agile values and the committed practice of its processes.
Tomas Björkholm understands this, as illustrated in his detailed investigation of the differences between two agile practices: Scrum and Kanban. In an article recently published on the Agile Journal website, Björkholm lays out the primary differences and similarities between the two methods and then weighs in on what he thinks is most valuable about each one. Certainly, they share some important sensibilities, since Kanban is most closely identified with the Lean movement, which also influenced the development of Scrum. But what differences they have make a big difference and the author astutely teases out why, for instance, Scrum’s use of iterative work cycles (i.e. sprints) is superior to Kanban’s view of work as a continuous flow. (For starters, there’s a crucial psychological factor to sprints: Scrum’s “chunking” of work enables developers to really focus on the most immediate tasks, rather than become distracted or overwhelmed by a never-ending stream of work.)
If you’d like more information on either Scrum or Kanban or would like to see an expert dissection of the two methods, I’d recommend you check out the article.