Adding Agility to a mature Java product.

Having heard Dave Hussman give the lectures on Agility at the NFJF conference, my supervisor and I came back fired up to see how we could introduce it into our organization. I'm just now at the point where I can do some reading on the subject, and have a couple of resources that are a good read.

First, my supervisor handed me some printouts yesterday of a whitepaper entitled "Making Agility Stick", Cutter Benchmark Review, Vol 7, No. 7, July 2007. With that many sevens, how could it be bad? Actually, it's quite good. It has a contribution from N.C. State's own Laurie Williams, from the NCSU Laboratory fo Collaborative System Development, among others (but I have to hype the local talent!)

My point with this entry is to journal my experience introducing Agile into my organization. I'm a lead developer, so I have a peer relationship with my teammates - so I am really not at a position where I can mandate anything, I can only encourage. This is fine by me, it fits my leadership style.

As of today, I am not that familiar with agile development at all. I've experimented with XP in short bursts. My current officemate and I work well together in pair-programming situatiuons, but the activity is usually reserved for crisis emergency-fix situations. I know that the goal is smaller relases with rythm, incremental/iterative development that focuses on making progress "burning down" your stories in "sprints". Yep, that's all I know, and I don't know that I have even that correct. Laurie said in her article, "Agiliy is not an option - you just nee to determine how to go about being Agile." And with that, my study begins.

Agile is not a single methodology, but a category. The well known Agile methods are:

• Extereme Programming (XP)
• Crystal
• Feature Driven Development (FDD)
• Dynamic Systems Development Method (DSDM)
• Adaptive Software Development (ASD)
• Scrum

TODO: link those to synopses

My biggest suprise was not that there were multiple, but how little overlap there is among them.

Making Agility Stick

Having just read this whitepaper, I wanted to take down some impressions. I think these will be worthwhile to go back and review as we make progress. Here are some quotes from the articles that jumped out at me.

People involved in a change need to be able to answer the quesiton, "What's in it for me? (WIIFM). Within a single software organization, WIIFM is different for each role (tester, developer, architect, manager, director, CIO, etc), if not for each person. Depending on WIIFM, a person may initiate change or resist change." -Laurie Williams, Stickiness of Agility.

We need to find out what about Agile works for each role and make sure it is communicated clearly. Everyone needs to understand what their "win" is supposed to be, and then fire them up to deliver it.

Rather than the organization's goal being "Transition to Agile", you must set a concrete tangible busines goal. Position that goal to be most achievable through the use of Agile methods, shrouding the often-disdained software process transition with the emotion of striving for unexpected and unprecidented success. -Laurie Williams, Stickiness of Agility.

We don't currently have a big, high visibility feature that will unify across development. There are a few medium sized projects, so it would be interesting to see how can umbrella them ala Five Live. "Five Live" was a push where a company adopted an agressive goal where it probably couldn't be achieved without moving to an agile methodology.

I am a firm believer that the relentless focus on speed mitigates many of the risk sources of projects: scope creep, changing priorities, mounting technical and defect backlogs, lack of dedicated resources, and so on... The concept here is simple, the less you sign up to deliver in one release, the less there is that could go wrong.
-Sam Bayer, Seven Rules to Making Agility Stick

Agile touts the ability to deliver the right thing faster, and that quote sounds like a reasonable assertion to me. With all the focus on faster, as a developer (and probably QA would react similiarly) it sounds like it may begin to feel like a vicious-treadmill-of-death. What is built in (if anything) to help people not feel that way?

"Regardless of changing conditions throughout the project, the team would never be allowed to adjust it's initial estimates, which in reality become the defacto committments to the organization.

In my experience I guess the "allowed to" would manifest itself in that the developer felt like they couldn't take the time to stop what they are doing and totally re-estimate if necessary. First, it makes them feel like they look terrible. Second, most developers thing they are just another half-day from delivery all the time, so think that re-estimation would be pointless. Third, estimating software as a task is aweful, and is typically wrong anyway. It's hard to get over those feelings and do it.

Will Agile Stick?

How do we keep momentum in agile? I can already imagine people reverting to where they are comfortable. In our orgainization, that would be our current waterfall model. I think there is a bit of resistance to Agile because truly we have finally gotten the waterfall working relatively well, so I think there is perceived risk of fixing that whih isn't broken. I can understand that sentiment. We just have to communicate what they should expect to see as the ROI. You simply can't argue with ROI.