Configuration problems with Ruby’s XmlSimple

I like Ruby gems, I can see the resemblance to Perl’s old CPAN idea. CPAN always drove me crazy since everything you pulled down then had say 8-10 more libraries that it required. Till this day I still avoid often avoid perl just because of the pain of constantly installing libraries to get simple things to work.

I ran into one of those too easy to go wrong type problems. Just two easy steps to use XmlSimple:

  1. 1
    sudo gem install xml-simple
  2. Run a ruby script with <div class="codecolorer-container text vibrant overflow-off" style="overflow:auto;white-space:nowrap;">
    require 'xmlsimple'

Two hours later I still get the same useless error that doesn’t really have any google hits:

`require': no such file to load -- xmlsimple

Shrinking Timeboxes

This week I scheduled a Sprint Planning Meeting to select the backlog on a project. Our normal time box for this meeting is about 4 hours. Since this is the 4th Sprint for this project and these meetings have generally only been going 90-120 minutes in the last few planning meetings I actually scheduled the meeting for only 90 minutes.

When the meeting happened we got into some important discussions around the Sprint goal and the largest feature for Sprint #4. Unfortunately much of this discussion really got going the last 30 minutes of the meeting. We couldn’t extend the meeting since the product owner had other meetings to attend, so we came to a quick conclusion and agreed to a slightly vague goal.

The lesson here is you’re better off sticking to a half day schedule for the meeting even if you get through it in less time for most Sprints. I compounded the issue with only setting up the meeting a week in advance so I really couldn’t find a 4 hour window for the meeting at that point. Lessons learned.

Early Releases

One of the greatest advantages of Agile is the ability to release early and often. It stands in stark contrast to the waterfall approach where you finally deliver at the very end if you deliver at all.

Though ROI is notoriously difficult to calculate with many IT software projects, releasing as soon as you have customer value dramatically shortens the payback period for your effort. So even given a project where the expected ROI is pretty much a guess by the sales team delivering some of the necessary functionality in the first few months is a big win. And despite the negative aspects delivering failing faster on a product thats going to go nowhere is also quite a benefit in reducing waste.

A subtle effect involves the ability to deliver much closer to the just enough target. If you release a product and find that it pretty much meets the needs of the customer base, then maybe you end up leaving out that long product backlog. This avoids building a lot of functionality that will never be used. It also makes maintenance and future enhancements easier because the base product is simpler.

With all of these obvious selling point it can still be a very difficult sell inside many organizations. The problem stems from a general lack of trust from customers. They have been involved in a contractual battle for years even with their own IT department. It works something like this:

  • Customer: We have this great idea for this new CRM product.
  • IT: OK, well just get the requirements together and signed off and we’ll build exactly what you want, but it may take a while.
  • Customer: No problem, we’ll put everything in so we don’t have to do change requests. I hate change requests.
  • IT: That’s good, but remember we need to control the scope. You know it costs 10x as much to change a system after you start coding, so it really helps to have the requirements fully defined. Give us a really good spec and we can produce miracles.
  • Customer: This is great so we can launch this in 6 months.

The unsaid part is that the customer is tossing in everything they might need in the future. If you know you have to wait a long time to get a new system, you have to protect yourself by asking for everything you might want even if you’re pretty sure many of them won’t turn out to be necessary. You really want to avoid the change control process.

IT on the other hand knows the customer will never define the requirements well enough because they never know what they want. They’ll produce some crappy wishlist with a lot of ‘system shalls’ and then we’ll have to be forced into a change control process.

This is a recipe for failure and both sides know it, but it continues because sometimes its hard to imagine something outside of the waterfall. Both sides have long since stopped questioning the value of heavy documentation. (Just yesterday I had a brief conversation with an analyst about what they were working on. They explained for a very small change to an existing product they were writing a 44 page requirements document. I exclaimed about how this seemed like an awful lot, and they just sighed and said “we’ll it’s not so bad, a lot of it is screenshots.” The worst part was the code had already been done and was ready to be QAed, so the document itself has almost no value.)

Iteration Zero

I ran across the idea of an iteration zero today reviewing Peter Schuh’s Integrating Agile Development in the Real World. He defines it as:

An iteration zero does not deliver any functionality to the customer. Instead the project team focuses on the the simple processes that will be required for the adoption and use of most agile practices. … From a management point of view iteration zero may include

  • Initial list of features identified and prioritized.
  • Project planning mechanism identified and agreed upon.
  • Identification of and agreement upon a team customer, essential stakeholders, and business users and the nature of iterative planning process, such as the time of planning meetings and the length of iterations.

I’ve used the iteration zero approach when setting up for a project before. A lot of times it takes a bit of prepping and planning to get some sort of initial product backlog together for the customer, finding a collocation space, and just getting some software installed.

There is a danger that you get too comfortable with this approach and you’re regularly beginning projects with an iteration zero that doesn’t really deliver actual value. I find most customers just aren’t ready to jump in day one on a Sprint unless they’ve spent some time thinking about the product backlog and what they probably want first. We’re using them less now that many of the teams are fairly familiar with Agile approaches, but they still happen.

Official Agile Evaluation

This afternoon we held an update on our Agile pilot projects for much of the executive leadership of the company including the CEO. It was led by our agile coach and championed by our CIO.

At this point I’m not sure what to make of the results, but we still have a green light to go forward. The executives were pretty quiet overall which may have just been courtesy of a Monday afternoon meeting. What concerns were brought up centered around two basic items:

  • Co-Location
  • Dedicating staff

I’m not sure these are the major concerns in other places adopting Agile, but they have been ours. At the end of the day they both involve giving up some measure of control, and that is rarely an easy thing to do for a functional manager.