Real World Jazz Results – Our Customers are not “Kind of Blue”

Real World Jazz Results – Our customers are notKind of Blue
I have been wandering the world (electronically) and North America (physically) for the past year and half helping IBM customers understand the capabilities of Jazz, and the implications of the deployment of those capabilities for their organizations.  I have deployed countless Proof of Concept environments, run many Proof of Technology shows, and spent many a day discussing the relative merits of a variety of software development tools, methodologies, and just plain old war stories from the age of “stone knives and bearskins“.  I have also helped some of our larger customers begin to deploy the Jazz technology, and leverage the benefits associated with adopting the Jazz platform as a foundation for software development activities.  The most important thing that I have done, is not deploying the Jazz technology, it is measuring the results and benefits that the Jazz technology has given our customers.
IBM has been deploying Jazz internally for a while now, and we do have some measures of the benefits that we are realizing.  This is great… for IBM.  The issue is that IBM has a unique access to resources and circumstances that will not be replicated in the situation of ANY of our customers.  Just because the guy who lives next door to me realizes 20% lower medical costs by self insuring than I do, doesn’t mean that it is the right approach for me to take.  The guy is a doctor, so the that might skew the results a bit.  What the examples I am going to share in the article show is that it is possible to realize improvements in productivity and software development performance with Jazz, even if your company isn’t called IBM.
The first example is a typical example for many small organizations that adopt the Jazz technology.  This particular group is within a line of business with one of our larger customers, but they operate like a small software group.  They had a small team doing Agile development, and using a mix of spreadsheets and open source tools to help them.  We decided to use this team as a pilot project, after we assured ourselves that we could easily migrate them off of the Jazz platform after a handful of sprints.  That was 10 months ago, and the team still refuses to get off of the Jazz platform.  They bought it so they wouldn’t have to lose it.  They like it that much.
It been 10 months, and we have had a good amount of time to collect data from this team.  I will stay away from using actual dollar amounts and talk in rough percentages, since some of this information is considered sensitive by this customer.  The benefits that this team saw over time began with some dramatic improvement, once they got comfortable with the tools, and broke down along these lines (in terms of time):
  • Developers – saved roughly 18% of their time by using/collaborating with Jazz (90 minutes a day)
  • Business Analysts – saved roughly 11% of their time because stories were easier to manipulate, status and prioritize with Jazz (55 minutes a day)
  • Systems Analysts – saved roughly 40% of their time, since following stories and approved changes was so much easier (200 minutes a day)
  • QA Analysts – saved roughly 10% of their time, with easier traceability between stories, test cases, and builds (50 minutes a day)
  • Program Management – saved roughly 15% of their time with the improved transparency of Jazz (75 minutes a day)
My second example is a much larger organization, with over 400 software development staff.  This group has a large number of Agile teams (hence a much larger sample than my first example), that range in size from 8 to 18 people per team.  This particular group has decided to quantify their benefit in terms of dollars, by taking their average rate for a fully burdened resource, and multiplying it by the time savings.  After roughly 6 months, this group was able to summarize their annual benefits from a Jazz based implementation:
  • Planning Automation – $389,000
  • Daily scrum meetings (time reduced) – $810,000
  • Quality Improvement –  $194,000
  • Reduced effort to manage work items – $1,200,000
  • Project reporting – $130,000
  • Reduced time determining project status – $990,000
  • Reduced time to establish new teams – $432,000
  • Reduction of duplicate efforts – $648K

This comes out to a grand total of $4,793,000.  That is almost five million dollars.  These numbers look a bit unbelievable, and represent a HUGE cost savings and capability improvement.  Even if we assume that people are in “happy” accounting mode, and cut these numbers in half, it still represents almost two and a half million dollars in savings and increased capability.  This is significant.

Closing Thoughts
It has been a great first year of posting my insights, thoughts, and observations of Jazz technology to this blog.  I anticipate that I will continue to do so in the coming year.  This final post of the year is a significant one for me.  It is significant because it represents real capability increases and cost savings that have been realized by my Jazz customers, not just some projected benefits derived from a small pilot effort.  Our Jazz baby is beginning to grow up and make it’s own way in the world.  While these cost benefits are impressive, what holds more promise for me are the strategic benefits that Jazz provides to an organization:
  • It allows an organization to have a balanced portfolio of software tools that reduce it’s risk, and allow it to leverage successful technologies more quickly.
  • It provides an organization a high degree of transparency into IT development efforts, and thus improves the accountability with teams, groups, and the entire IT organization.
  • It allows our customers to actually do active monitoring and management offshore and outsourced IT efforts.
  • It helps software development people focus on what they are good at – developing software.
I hope that 2010 provides me with more inspiration and stories for this blog, and I encourage you to post comments and questions here.  Like the rest of the Jazz based universe, this small outpost is only as informative and entertaining as my readers make it.  Send me your stories, observations and questions, and I will get to them as best I can.

Jazz Progressions – Approaches to Mixed Tool Implementations

Moving from Louis Armstrong to Thelonious Monk….

This blog entry deals with some of the smart people that I meet during my travels, and the subject of getting the benefits of RTC in a ClearCase based environment.    We have a lot of customers that have a HUGE investment (in terms of time, effort and money) in IBM/Rational technologies, like ClearCase, ClearQuest, RequisitePro and others.  Many of them wonder about the best way to leverage the new Jazz based infrastructure in that existing environment.  You want to get the best of both worlds, and you want to have the flexibility to use the best tool for the job at hand.  So how do we move forward in a nice orderly manner?  More specifically, how do we coordinate our SCM systems (RTC and ClearCase)?

That was a question put to me by one of our customers.  So I asked some smart people to come along with me to discuss the issue.  Geoff Clemm and Carol Yutkowicz from the Jazz development team graciously accepted my invitation.  Working for a big company like IBM has it’s drawbacks, but one of the big advantages is that there is ALWAYS someone smarter than you in the organization that you can learn from.  I learned a lot from Geoff and Carol today.

The basic documentation and perception in the Jazz customer community is that there are two ways to link in your ClearCase assets to RTC.  The first is by using the ClearCase Synchronizer, which synchronizes the artifacts associated with an RTC stream, to a particular ClearCase branch/stream.  The second is to utilize the newer ClearCase Bridge, which essentially replaces the Jazz SCM capability with ClearCase.  In the first case, you have some of your teams use RTC for SCM, and other teams keep using ClearCase for SCM.  In the second case, all teams keep using ClearCase for SCM, but use RTC for functions like work item tracking and agile planning.  Most of the customers that I talk to like the first method (utilizing the ClearCase Synchronizer), because they may have multiple teams working on some shared components, and because they like using ClearCase for builds due to it’s build auditing capabilities and the investments that they have already made in build automation with ClearCase.  Some use plain scripts for this automation, some use BuildForge, and some use other non-IBM tools (like Maven, Hudson, and so on).  The important piece is that they have invested a lot of sweat and thought in setting up a sophisticated automation of their build and release process, and the thought of rewriting all of that in a Jazz environment makes them cringe.  I can’t blame them.  BuildForge and those other tools will all work with Jazz just as well as they do with ClearCase, but it has taken years to develop their existing automation’s, and rewriting all of them can be costly and time consuming.

So that is the issue.  My problem was that I was looking at the technology to synchronize a single project’s work, and I wasn’t thinking of the entire Enterprise.  I was picturing a scenario like the following picture, where I have corresponding streams in both RTC and ClearCase.

The issue with this approach is that when you have an organization with hundreds (or thousands) of projects, you have to pay the cost of having hundreds (or thousands) of ClearCase Synchronization jobs copying versions back and forth between the two repositories.  This would thrash your VOB servers and limit your ability to take advantage of a lot of the cool SCM features in RTC to manage complex hierarchies of projects.  It could also be a challenge to monitor and manage all of these synchronization tasks.  So I was I thinking of things in terms of a lot of little individual projects, each (potentially) with it’s own custom setup for synchronizing the RTC repository with their ClearCase VOBs.  Luckily, I brought along people smarter than I am.

Geoff pointed out that Jazz uses streams in a similar way to ClearCase.  I can have multiple RTC projects, that utilize multiple Jazz components, but in each of those components I can establish an RTC stream called “CC_Sync”.  It would then be possible to create a stream in all of the impacted ClearCase VOBs called “Sync”.  Now I would be able to synchronize ALL of my RTC work with all of my ClearCase repositories with a single ClearCase Synchronizer task, set up to synchronize these two streams between all of these RTC components and ClearCase VOBs, as shown below.

So there we go, administrative and performance nightmares solved.  Geoff further pointed out that we could do this in a series of streams, to support multiple build targets.  So you might have a synchronization stream pair for release candidates, quality test candidates, and performance test.  The number of ClearCase Synchronizer tasks is still kept to an easily manageable number, regardless of how many projects you are supporting.

I would still STRONGLY suggest that you not work on both sides of the divide for work on a particular piece of software, since you will need someone to manage and resolve any collisions or merge conflicts.  If you do have to have some team members working in RTC, and other team members in ClearCase, then I would STRONGLY suggest that you keep the synchronization streams “quiet”, and only attempt to share work that is ready for delivery/integration.

If you are interested in some of the details of this approach, comment on this and let me know what your particular challenges are.  The best way to see this in action is to try it out in a test environment.  Let me know what you see in your environment.

We are all Agile in the eyes of the Jazz Admin

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.