There has been a lot of interest lately in so-called “Kanban.” While it would greatly alleviate my personal angst to discuss the use of this term, what it really is/means and so forth, that would likely only be interesting to me (and a few other pedantic people who will remain nameless). Instead, I want to talk about taking an Agile approach to what is generally more predictable work than new product development (e.g. for support teams). I get asked about “support” all the time. Recently I was asked via email, “How can I ‘use agile’ for support issues? Scrum seems … LEARN MORE »

I attended the Agile NYC conference this week and was pleasantly surprised with the quality of speakers and overall professionalism of the event. For the last several years, I have only attended bigger conferences like the annual Agile Alliance or Scrum Gathering so it was refreshing to mingle with a smaller audience that allowed more intimate connections with people. CollabNet hosted the obligatory booth, allowing us to share our story with potential customers. We met nice people from all kinds of organizations from retail, finance, publishing and many more. As with any conference people were at all different stages of … LEARN MORE »

Sometimes a requirement is just too big to get done in one iteration. What should we do then? Return to Agile Tips

Sprints are not purely for construction. In a broad sense, producing a little bit of product is a goal of every Sprint. But not the *narrow* sense of production or construction people are traditionally thinking of. Sprints 1, 5, 19, and 100 should all contain planning, design, choosing tools, (re-)evaluating the best ways to work together, etc., not just the heads down stuff like coding and testing. I think we’ve all seen the hazards of teams having their heads down too much of the time: a pile of bad code written around faulty assumptions. One or two architecture “experts” still … LEARN MORE »