Gary’s Tech Thoughts Blog

Oh, how I love this post by Joel on The Duct Tape Programmer!  This is such a salient point that applies to so much more than the context here.  “You see, everybody else is too afraid of looking stupid because they just can’t keep enough facts in their head at once to make multiple inheritance, or templates, or COM, or multithreading, or any of that stuff work.”

I just ordered my copy of  Coders At Work.

On a total Tangent, I just completed the transfer of my domain name off of Network Solutions to Dreamhost.  Dreamhost is awesome and dirt cheap.  They have one -click installs of just about everything you’d ever want to run on your website and their registrations are almost free they are so inexpensive.  I’ve been hosting with them for over a year and have had zero issues (other than imap email, but that’s another story).  I 100% recommend Dreamhost.

Lots of discussion lately about measuring productivity has had me spending time I should be sleeping thinking about the same.  I love accountants and finance folks.  I find them very bright and love the way they typically approach any business discussion from the point of logic, but they can be an intractable lot as well.  They’d love to measure software engineering efforts like a consultancy – hours in, output out, utilization metrics pop right out the other side of the equation.  More utilization of the team means more productivity!  Wonderful!  Its so simple and we should have figured this out so long ago.  All that time wasted counting KLOCS and function points….

Of course it doesn’t really work. You can count hours, or days, or whatever to your hearts content but you are only measuring effort.  And, measuring effort of a software development group is an exceptionally tricky (and potentially dangerous) thing.  Its not the effort that matters, but rather the results.  So how do we measure the results?  Ahhh there’s the rub.

What we need to measure is the business value of the stories the team is being asked to build.  For the consultant this is very simple – you are paid by the hour for the consulting performed.  Thus, hours billed X hourly rate = business value.  The business value of a software going into a product is not so easily measured.  But, lets assume this is a solvable problem.  It gets even more interesting in the planning phase when you are making product choices.  For a proposed feature, what is the busniess value?  Now suddenly, this is not a software engineering question at all.

Last week, the Austin Agile development user group, AgileAustin, published a online poll of tools that teams in the local area favor for agile planning.  In response to the email announcing the poll, a couple of members emailed the list saying their favorite tool is no tool at all.  Some said index cards.  I shook my head a bit and emailed a good friend of mine who also leads development teams for his thoughts.  We came to the conclusion that it must be nice to work in a project so small you need no tools to help the team plan a sprint.

Actually, I don’t think it would be that nice.  I’d submit that if your plans are so simple that you need nothing to track them, or index cards suffice, you’re probably not doing much interesting.  For my team, Rally Software’s Rally Enterprise has been very successful in helping us plan very complex agile projects.  I recommend it without hesitation.

In many cases, our product management team enters user stories (sometimes we use epics for very large user stories) while the development, QA, and docs team breaks these down into stories and tasks.  We plan sprints as a fully integrated feature team across all these disciplines.  It’s not perfect, but it works and works well.

You can keep your index cards, thank you.

Tomorrow, I have the opportunity to speak at an Rally customer success tour at the Renaissance.  Tonight, I am reflecting on the leaders I have a privilege to serve with on the panel, Israel Gat, Jack Yang, Torsten Weirch, and Eric Huddleson.  These gentlemen are all significant leaders in the Austin Community and I’m looking forward to tomorrow.

I’ve chosen the topic of “Agile in the Large” since the real power of Agile is evident when you turn loose the teams to run at their full speed in a self directed agile process.  Agile gets really interesting with development teams over 50, and also holds its most promise.  We believe that the best way to scale a team and continue to deliver successful software projects is to build it as a set of Agile teams.

Here’s few things we’ve learned along the way.  Interestingly enough, in comparing notes with the some of the development leaders at salesforce.com, it seems they have learned many of the same things.

• There’s no replacement for a great technical leader in the Agile team – effective team leads are priceless.  You should always be growing and recruiting for leaders.
• Great Product Owners are hard to find.  I have the pleasure to work with some of the best, but to scale the teams, you need more.
• An Agile team must be composed of all the skills they need to produce a shippable result.  In our case, it is the product owner or manager, usability, dev team, QA team, and tech writers.
• You run into problems when you depend on other parts of the organization that may not be Agile.  Just for an example, if you have a supporting organization that is still working on the Hero principle, or the waterfall process, there is going to be trouble.
• Tool support is critical and everyone must adopt. For large teams, roll up views and quick reporting is absolutely essential.  Rally gives us this capability.
• Test automation is absolutely key to keeping the product shippable.  As each sprint there is significant new functionality being delivered, the QA team must at the same time deliver automated tests so that doing regression testing onthe whole product is a swift process at the end of the release.  There’s just not time to regression test the whole product.

We have even been able to extend Agile to expose our feature teams to end clients through the Rally Agile tool.

Recently, we evaluated several Agile Project Management tools.  Having used XPlanner for years, it was time for a change.  XPlanner is great in some ways – fairly lightweight and easy to use for developers.  It really falls apart though when you start to consider multiple agile teams working together to deliver a release.  It is just really problematic to get a group view of where you are, what progress is being made by the team, and where the hot spots might be.  To accomplish this, you need to drill into the details of every scrum team and study the metrics / charts.  I even went so far as to change the source code to build a dashboard – that’s when we started to approach diminishing returns.

The other shortcoming of XPlanner is the management of the product backlog and release planning.  Yes, you can work around this, but intrinsically, the tool does not support building a backlog and then moving stories into a sprint.  Yes, this can be done, but it is arduous.  The interface also is stuck in Web 1.0 land, making data entry into a form submit after form submit affair.

So then what?  Surveying the market and talking to many of my longtime friends developing software with agile process, we quickly build the short list to replace XPlanner. We looked in detail at Rally, VersionOne, and FogBugz.  Though FogBugz had some very interesting capabilities around predicting the accuracy of estimates, it didn’t really seem to support agile planning methodologies and the scrum process.  Also, though the predictive capabilities are interesting, this really isn’t a huge benefit in my opinion if agile is really used and you know your people.

So, it was down to VersionOne vs Rally.   Both companies did extensive demos for our leadership team and key stakeholders.  Both tools intrinsically are built around the scrum agile process.  Both were priced around the same level with VersionOne being just a little less per seat, per month, but Rally matched and beat this price point in our negotiations.  The huge gaping hole in VersionOne for us was that it really didn’t assist with resource planning at all.  That is, they don’t enable you to enter the amount of available resources in terms of hours, days, etc, and then in the planning cycle show you where you are in using those hours as you take stories from the backlog and add them to the sprint.  Both tools track burndown during the sprint of course, but only Rally lets you know if you are planning too many stories in the sprint.  Even XPlanner supports this, so it is a big miss for VersionOne.  We can only assume they are working to add this capability.

Also, the rollup reporting for an entire release is more powerful and flexible in Rally.  This was a big plus for us.  To be sure, Rally isn’t super sophisticated in resource planning.  It doesn’t allow the individual team members enter their availability and then sum it up for the sprint.  (I would like this feature – I need to add this to the Rally Community.)  Rather, it just allows you to add the total number of hours available for a sprint at the beginning of the planning cycle.  How you figure this out is up to you.  After you add the total number of hours available, it shows you hours remaining as you add stories.

In coming blogs, we’ll talk more about the pros and cons of Rally as a Agile management tool.