Another week, another customer that is either adopting Jazz, or very seriously thinking about it. I ran into an interesting situation in the past month, and I ran into it twice. It made me think a little bit about Agile development, Waterfall development, and how Jazz and Rational Team Concert can help an organization begin to get the troops marching in the same direction.
While working with a customer this week, we got wrapped around the thorny fact that while the organization would like to have all of their teams begin using Agile development methods, many of their teams would resist, and some efforts were probably better off being left with their current methodology (Waterfall, Iterative, Spiral, and so on). The reality of the situation is that in any medium to large sized organization, there will be a period of time where Agile teams and Waterfall teams will need to coexist. There may be projects and areas of the architecture where Agile is not the methodology of choice. So after agreeing to this point, my customer asked, “So how do you support this?”. We also spent some time talking about the differences between Agile, Waterfall, and Iterative methodologies. Luckily, it was late in the day, so I was able to leave without really answering the question.
Still, the whole concept kept rattling around in my head. Then it came to me. What is the BASIC difference between all of these methodologies? Speed and scope. (I know, that this is over simplifying things a bit, so all of you methodology zealots keep your flames to yourselves. I still believe that the core concept holds true.)
Think about it. In a Waterfall project, we scope the entire project, and then we do the whole requirements -> design -> code -> test thing. Because the scope is so big, this single iteration ends up taking about 12 months (which just happens to be the budget cycle). In an Iterative project (RUP or not), we lay out maybe 6 iterations of about 8 weeks in length, and break the work into smaller more manageable chunks, and then do the whole requirements -> design -> code -> test cycle on those smaller pieces. In an Agile project, we have some sort of vision, and then we make up a bunch of stories that we attack in quick, 2 week bursts. In each burst, we go through the same requirements -> design -> code -> test cycle, only on pieces that are really small, and we tailor the workload to the velocity of the team.
So what does this mean for a Jazz/Rational Team Concert deployment? Maybe I don’t need to have a bunch of different processes and work items for each different methodology. Maybe all that I need to do is provide a framework for a common iteration, and then let the project determine the length of time for each iteration. This will mean that teams will determine their “agile-ness” in how they interact with their stakeholders, and in how quickly they schedule their iterations. So now an organization can have a consistent process, consistent work product types (kind of), and collect consistent software development metrics. Bonus points: A common process, with tailored iteration lengths, is a lot more simple and cost effective to design, implement, support and improve.
The implications of this could be profound for an organization. Management will be able to look at teams, and determine the optimal iteration length for their teams/projects/applications. By measuring performance over time, it should be easy to compare the productivity of a team, and the quality of it’s work, based on the length of the team’s iterations. Do my mainframe projects do better with a 2 week, 1 month, or 6 month long iteration? Do my web applications do better with 2 week, 3 week or 4 week iterations? As an organization, are maintenance activities better done with longer iterations or shorter iterations? Does my Killer Bee team do better with longer or shorter iterations? How does risk factor into this?
It’s an interesting thought. So I guess ALL software teams are Agile, they just have different iteration durations. I would love to see someone try this out. Is your organization struggling with this issue? How do you look at the adoption of Agile practices in software development? Let me know, I am interested in seeing what Jazz (and non-Jazz!) users are seeing out there in the trenches.
Dan Toczala's Blog 