RTC Adoption Problems: Tool, Education, or Perspective?

I work with CLM customers a lot and sometimes I encounter people struggling to adopt RTC. Once in a while the problem is with RTC – a bug, the rare difficult-to-use feature, etc. Once in a while it’s just a technical knowledge thing. For example, if you’re not aware that your Websphere JVM heap space should be no more than half your physical memory, then you’re going to have issues.

And sometimes the problem is human nature. It’s our own difficulty with breaking out of an existing perspective, breaking old habits and old ways of looking at things. These are the most difficult problems to solve, but solving them provides the biggest payback.

Example: Scrum Iteration Planning

To illustrate this issue, let’s say you’re using the RTC Scrum process template. You think that it takes too long to load an iteration plan. You perceive a performance problem. Fair enough.

So we look at your plan and see that you’re loading many hundreds of work items when you display your plan. In other words, you have planned to do hundreds of things in the course of a single Scrum iteration. And these are higher-level items, Epics and Stories, not just tasks and bugs. The problem is, a Scrum iteration shouldn’t have that many planed items. You should generally have dozens of plan items, not hundreds. What gives?

It turns out that you have nested iterations (which is fine), and your iteration plan is focused on the highest level iteration (which is not fine). We find that the timeframe of this high-level iteration lasts for more than a year.

Scrum iterations are designed to be short and provide a deliverable at the end. Four to eight weeks is common. If you have longer iterations, it’s harder to do the planning, estimating, and managing that makes Scrum so useful. Instead of looking at all the planned items in your project, you want to look at just those that are planned for the current (or possibly the next) short iteration. Scrum focuses the team on the “now”, partly because Scrum allows for a lot of change to a project in the future. In fact, Scrum embraces and encourages change, so we can’t know, in a detailed way, what’s going to happen past the next iteration.

This means that you are losing a lot of the value of Scrum if you are trying to see the entire project in one iteration plan. And, if you only look at the plan items for a fine-grained iteration, you’re not going to have performance issues because you’re not loading hundreds of plan items.

It also means that in this example, RTC looks like it has a performance problem, but what’s really happening is that the Scrum template is being used in a way it’s not designed for. You’re trying to pound a square peg into a round hole.

Right Process, Wrong Perspective. Or, Right Perspective, Wrong Process.

So now you’re saying “OK smart guy, but I really want to see the entire scope of my project. I’m used to looking at Gantt charts and critical paths in Microsoft Project. It’s how I’m successful at delivering my software!”

This is the crux of the problem. Scrum (or any process) is designed to deliver value in a certain context. For Scrum that context is small teams that can deliver in short cycles and who embrace plenty of changes as you go. But maybe you’re working on a project that can’t do that. Perhaps you have a large project that must try to define all requirements up-front because of contractual constraints. Or you’re required to report progress against a specific total estimate so you can bill the customer. Or your organization is used to working in a way that’s not the least bit Scrummy, and old habits die hard.

We can argue all day about what’s “good” and “bad” about the process you’re using, but that’s not the point here. It may be that the nature of your project prevents you from adopting all of Scrum (or whatever process you’re trying to adopt). A better way to say that is that the nature of your project should define the type of process you adopt. Maybe you actually do need to look at all plan items across the entire project at all times.

That’s OK, I’m not judging. But let’s not fool ourselves into thinking that Scrum will solve our problems because Scrum is all good, hail mighty Scrum. Let’s use RTC to model the process that we can do and must do, the process that we’re contractually obligated to do or that has proven to be effective in our organization for our particular set of circumstances. Or, use RTC to model the process that we need to do, that will solve some problem in the way we develop our software.

The real problem in the scenario described above is that people want to do Scrum “because it’s Agile”. People want to get that Agile mojo and make their projects less painful and more predictable. But first their project needs to be amenable to Scrum practices, and if so they need to change their perspective and the old, ingrained, unconscious habits they’ve developed.

It’s very, VERY hard to change habits and perspectives. You have to have a clear target and keep that in front of you while your body and mind try to yank you back to your habituated way of doing things. The good news is that a tool like RTC can help you by enforcing new process elements that you want to adopt.

But if you try to use the Scrum template (for example) because you want to adopt Scrum, but you want to view reports and plans like you did in your old Waterfall process, you’re going to be frustrated. You’ll be banging a square peg into a round hole. There’s nothing wrong with square pegs or round holes, but we need to pick the right peg for the right hole.

This means we may choose the Traditional process template in RTC instead of Scrum. Or we choose the Simple process template and add Scrum elements to it, along with some custom stuff we like. Or we choose the Scrum template and add some elements from the Traditional template to it.

We do what we need to do to make sure we:

  • Do things that make us successful in delivering software IN OUR PARTICULAR ORGANIZATION.
  • Consciously change what doesn’t work, and enforce what does work.
  • Continuously review our process and incorporate new best practices. In other words, make a habit of creating new good habits.

And when we bump up against a problem in RTC, we want to ask ourselves if:

  • Something is wrong with RTC
  • We lack some knowledge we need to acquire
  • We’re using the chosen process in the way it was meant to be used

I guess the moral of the story is that there’s no such thing as a free lunch. If you want the advantages of Process X, you need to understand how Process X delivers the value that it does. Then embrace that behavior by forming new organizational habits.

In my experience, this is the most difficult part of adopting a process. Teams and organizations who get good at this are much more successful than those that don’t

About these ads
This entry was posted in Uncategorized and tagged , , , . Bookmark the permalink.

6 Responses to RTC Adoption Problems: Tool, Education, or Perspective?

  1. dtoczala says:

    This is so spot on, it’s scary. Great article, and one I will point many of my current customers to. I wish I wrote it…….

  2. There are similar issues on lower levels. I’ve worked with teams that were coming to RTC from ClearQuest. Rather than explore and embrace RTC Dashboards, they simply started replicating their entire CQ query collection in RTC queries. Not all of them will convert and they get frustrated by that. And the management that was hoping to get better visibility from the dashboards just sees all the same queries. To the extent possible, it’s like nothing changed except the URL. It’s hard and valuable work to get people to embrace the new possibilities and the rewards that come with them. Nice piece, Jim.

  3. Guido Schneider says:

    Thanks for this article. I agree with many points. One point I disagree is the statement about plan size. I already discussed this in a Blog from Tox “Keeping my Jazz Server happy and my users overjoyed”.
    Your statements are true for a Scrum Team in the execution of the Sprint. So for the sprint planning, daily standups, review and retrospective meetings within the team this is valid and the plans are seldom larger than 100-200 workitems.
    But on project level or scrum-of-scrum level you have larger plans. They span scrum teams and also iterations. You need this for release planning, controlling, reporting etc.. Projectleaders, Product Owners etc. wants to see the progress of their plan items. And they may be distributed over several teams and iterations. For this we want to have progress calculation through WI hierarchies, we want to profit from the bars in the plans.
    Of course you can do many stuff with reports, dashboard widgets or maybe queries. But queries cannot calculate and do not show WI hierarchies.
    The scrum template is good for scrum teams, but does not answer scrum of scrum, project or portfolio questions. The traditional template answer maybe a bit more on this level, but has the complete wrong terminology. So a larger organisation will always end in some sort of “Hybrid” process.

    One word about CQ query migration, this we try to avoid. Our teams learned to use plan views and do customization and visualizations there. Plans are a real benefit against queries.
    Unfortunatly it is not possible to feed a plan with a query result for visualisation.

    thanks again Jim

    • jruehlin says:

      Thanks for the thoughtful comments Guido.

      Regarding the Scrum scenario I used, I was only using that as an example to illustrate how our perspective affects our success or failure in adopting a process. I wasn’t trying to call out something good or bad about Scrum.

      However, since you brought it up… :-)

      I started to respond to your observations here, but I got too interested in the subject and it became its own blog post. See the new post “A Brief Explanation of Why Processes Don’t Scale”.

  4. Pingback: A Brief Explanation of Why Processes Don’t Scale | JazzPractices

  5. rfeggins says:

    Reblogged this on Reedy Feggins Jr. and commented:
    An excellent post on practical use of RTC and how it can successfully be adopted.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s