John Hines' Software Process Blog

A blog on Agile software development and Scrum

  Home  |   Contact  |   Syndication    |   Login
  39 Posts | 6 Stories | 43 Comments | 0 Trackbacks


The information in this weblog is provided “AS IS” with no warranties, and confers no rights.

This weblog does not represent the thoughts, intentions, plans or strategies of my employer. It is solely my opinion.

To err is human, to forgive is divine.

Tag Cloud



Thursday, April 29, 2010 #

Often reorganized teams end up with multiple copies of work management tools.  Like having three places to gather requirements, three places for customers to submit support requests, three places to plan and track work.

Tools that combine these features into a single product fall into the ALM category.  These may or may not be Agile planning tools, but are tools that allow you to look in a single place for requirements, work items, and reports.

One of the interesting choices is Software Planner by Automated QA (the makers of Test Complete).  It's a lovely tool with real end-to-end process support.  It is a paid tool with a license in the thousands of dollars for a handful of concurrent users.  Still, it’s intuitive, has great Agile capabilities, and has a reputation for excellent customer support.

Another choice is Rational Team Concert by IBM.  Reading the specs on this product makes me want to submit my resume to Big Blue.  Not only does RTC integrate every part of the Software Development Lifecycle, but it’s free for up to 10 developers.  It has beautiful support for all phases of Scrum.

I would strongly recommend the use of a third-party ALM tool rather than writing your own.  Unless, of course, you're going to sell it.

Technorati tags: Scrum Scrum Tools

A simple mistake to make is to assume that the use of Agile methods and Scrum will make everything easier.  Take your teams, make all work visible, track it, and presto: An efficient, functioning software development organization.

Scrum does have benefits like keeping close to your customers and increased predictability.  And it’s true that as teams become proficient with Scrum they tend to become more efficient.  But I don’t think it’s true that Scrum automatically helps people work together.

Instead, Scrum can point out when teams aren’t good at working together.   And it really illustrates when teams, especially teams in sustaining mode, are reacting to their customers instead of innovating with them.

What I’d recommend for any blended team is to look at your current product lifecycles and work on a single lifecycle for all work.  If you can’t objectively come up with one process, that’s a good indication that the new team might not be a good fit for being a single unit (which happens all the time in bigger companies).  Go ahead & self-organize into sub-teams.  Then repeat the process.

If you can come up with a single process, tackle each piece and standardize all of them.  Do this as soon as possible, as it can be uncomfortable.  Standardize your requirements gathering and tracking, your exploration and technical analysis, your project planning, development standards, validation and sustaining processes.  Standardize all of it.  Make this your top priority, get it out of the way, and get back to work.

Lastly, managers of blended teams should realize what I’m suggesting is a disruptive process.  But you’ve just reorganized the team is already disrupted.   Don’t pull the bandage off slowly and force the team through a prolonged transition phase, lowering their productivity over the long term.  Drive a true consolidation.  Destroy roadblocks, reassure those on your team who are afraid of change, and push forward to create something efficient and beautiful.  Then use Scrum to reengage your customers in a way that they’ll love.

Technorati tags: Scrum Scrum Process