Random Acts of IT Project Management

Project Management for Information Technology

Webinar: Agile Cuts Costs

Posted by iammarchhare on 13 April 2009

I watched part 1 of a webinar called “Agile Cuts Costs” by Rally Software and GlobalLogic have a pretty good high-level Agile presentation that is free to view.  If you find yourself with the need to justify Agile project/program management or a high-level view of how to move into Agile, then I suggest you check it out.  The presentation is given by Jean Tabaka of Rally and Johnny Scarborough of GlobalLogic.  It is just over an hour long, so I picked out points that hit home with my own experience.

Signing up and getting the presentation going was more annoying than it needed to be.  I had  to fill out a form, which wasn’t totally unexpected.  However, I have no desire to give you my phone number.  Don’t call me.  It’s too early yet to know if I will get inundated with spam, but at least that is a normal question.  The player has a clunky interface (I didn’t know I could minimize silly audio control window which pops up right in the way and cannot be moved off the screen entirely).  Once I got beyond this, though, things got dramatically better.

Jean and John go into the importance of metrics, particularly productivity index (PI).  “Productivity is often the most difficult measure to improve in regards to software development.”  PI for large, distributed teams can be lower, but they do not have to be.

The presentation shows that defect count can be kept under control even though schedules are shortened more than 50% by using Agile.  This would depend a lot upon the maturity of the organization, though.  I should point out that I have seen other presentations that show it doesn’t always mean faster delivery or reduced cost, but even those presentations show that it raises quality.  Let’s face it, you do save time and money when you aren’t fixing numerous defects.  However, as a team matures, there is no reason to believe the schedule would not be shortened as efficiencies become habit.

They only briefly mention the importance of time boxing.  From surveying the literature and experience, I have found that this is at the heart of Agile.  Getting that “flow” is very important.  However, flow is just the first level.

Teams often think that meeting a 2-week iteration is next to impossible and that nightly builds and testing are too expensive.  However, the presentation points out that it is actually too expensive to not do nightly builds.  I have found that there are pros and cons with nightly builds, but if you want to point out bad habits and team weaknesses early on so you can close those gaps, there are fewer ways to find them than by doing nightly builds and tests.

I agree 100% with the importance of a “step-by-step approach” to Agile adoption.  This cuts to the heart of my personal experience moving teams and processes to Agile practices and processes.  Culture doesn’t change overnight, and Agile is usually as much of a culture change as anything else.  It takes about 3 months or 6 iterations to go from amateur (“flow” organization) Agile level and mature to intermediate level (“pull).  It takes 12 – 24 months to attain to expert level (“innovate”), in part because it takes maturity across the organization.  Agile cannot “sit in engineering” and be at the expert level.  I have to believe, however, that larger organizations could take longer to adjust than this, but I could be wrong about this.

The risk inherent in the waterfall method is something that often is overlooked.  I really appreciated this slide.  It also shows how the risk of failure rapidly drops using Scrum.  This agrees with other presentations I have seen where quality is higher in Agile than waterfall methods.  Quality and risk of failure are often an inverse relationship.

One thing that cannot be stressed enough is buy-in.  This was mentioned quite a few times in different ways, but it is vital to have executive interest in Agile.  The team has to buy-in on Agile.  Old habits cannot be allowed to resurface, and the retrospective meetings (“lessons learned” for us old-timers) must result in the implementation of needed changes.

Having tools that can provide measurements automatically will free people up to concentrate on the tools.  John says, “Don’t skrimp [sic] on the tools.  You have to invest in the tools, especially when you are going into distributed development.  Post-It notes don’t scale out across time zones.”

There is a lot more to the presentation.  I only highlighted the parts I found interesting or have suffered past pain with.  I suspect part 2, which covers scalability, will be just as good.


2 Responses to “Webinar: Agile Cuts Costs”

  1. John,

    Thank you so much for the succinct overview of the webinar Johnny Scarborough and I presented in March “Realizing the Promise of Agile: Creating Leaner, Meaner, and Faster Product Development.” As you pointed out, this was Part 1 in our Rally two part series on “Agile Cuts Costs”. Part of that move to “Step 1” of our 5-step adoption approach is indeed about the notion of Lean Flow and what contributes to Flow.

    I agree with you that timeboxing, while it may sound as though it creates fits and starts, helps force teams new to Agile to regularly inspect their ability to maintain Flow. New teams often delude themselves about how available they are in a timebox, or, how much complex work can be completed in the timebox. That is the greatest benefit of the timebox. Teams use the timebox to evaluate those two estimates they gave at the beginning of the timebox: team availability and the effort to complete item complexity.

    If you are interested in other ideas around how “Agile Cuts Cost”, take a look at Ryan Martens (who presented in Part 2 of our webinar series) blog post about productivity improvements using Agile and how that helps cut costs. It has some other nice links in the comments as well. Thanks!

  2. I finally did get a chance to view “Part 2: Scaling Agility with Lean: Proven Methods of Operational Efficiency”, and I think there are some important considerations in the presentation. However, I will state that situations don’t usually lend themselves to a one-size fits all type of solution. I believe YMMV depending upon industry and size of the company. However, there certainly are some valid principles in the video. Methodologies are only as good as their fit in the business environment, and company culture can alter whether or not a methodology will work in that situation. I’m not familiar with Lean, but I’ve seen Agile work in non-Lean situations. The difference, I believe, was that it was primarily software (“business solutions”) and a smaller company.

Sorry, the comment form is closed at this time.

%d bloggers like this: