I was asked recently by my boss, the Assistant Vice President of Application Development to review and give feedback on the most important impacts of Agile good and bad.

Good Impacts

• All three projects had production quality software that the users could see after one month. Any other projects of this size would be lucky to have a rough draft of the BRD (Business Requirements Document) done.
• All three of these projects have no real issues with communication between team members. Even though friction between QA, developers, business analysts, and PMs is pretty commonplace on large non-Agile projects we’ve seen none of this on the Agile pilot projects.
• The product owners on all three projects are very happy with the process. They all feel that the feedback every 30 days is much better than our old waterfall methodology.
• The projects have very low defect rates and have had no significant bugs at the end of any Sprints.
• The developers on the projects are more motivated and engaged with their team. The teams are actually having fun with things like one ScrumMaster being rewarded by their team with a rugby jersey embedded with a ‘Scrum Queen.’ Employees are more motivated when they come in to work.
• The use case approach results in much better requirements than our vague BRDs.
• Project managers are able to really have an impact and add value instead of filling in as a project admin role.
• Tasks on a project are broken down to 4-16 hour chunks. This has been a big help in two ways. First, team members can really commit to measurable tasks that are complete within a day or two. Second, teams become get better estimates because their actually forced to break everything into atomic tasks and they practice estimating every 30 days.
• Agile is forcing the organization to examine dysfunctional processes. Delivering every 30 days forces reexamining some decisions that don’t appear to be adding value.

Negative Impacts

• One of the benefits of releasing earlier hasn’t been realized. Product owners are still holding off for all possible features before releasing.
• It’s still hard to handle all the requests for smaller projects and leave staff dedicated on Agile projects.
• For a period of time at least one project was able to avoid following the normal migration process to QA servers.
• The business may not be ready to take on the faster pace of change and decision making that Scrum drives towards.
• The adoption of the entire Websphere stack at the same time as adopting Scrum has meant a painful level of change especially for web developers.
• Scrum is often sub-optomized because people aren’t solely dedicated to a project, or good collocation space can’t be found.
• The pace of change has proved difficult for a few team members requiring some substitutions on projects.

I think it’s a pretty good list, but it worries me a bit that I can’t come up with more negative things, makes me think I just may be drinking a bit too much Kool-Aid.

One of the big advantages of Agile software development and Scrum is that you have potentially releasable software at the end of every 30 days. That’s been a really hard sell so far with our product owners.

I attended the Sprint review meeting today for a project that has two of my developers on it. The whole team did a great job and delivered a good chunk of functionality that’s already running on our QA environment. The project is building on an existing application and adds functionality they don’t have right now and compacts information from 3-4 mainframe screens into one web page view. My guess is it would save quite a few of our employees a good chunk of time right now.

It wasn’t really suggested, but our Agile consultant/coach and myself both asked if there was enough value here to release it. The product owner explained that they didn’t plan on releasing it on this Sprint, but that maybe in another Sprint or two. That’s actually really progressive in general for our organization.

My recent experience would suggest that we are adverse to releasing anything that doesn’t have every possible feature the customer imagined:

• We just launched a 9 month long project that could have easily been broken into 3 releases based on the features.
• Another Scrum project has been through 4 Sprints and surpassed the functionality of the applications it’s replacing after Sprint #2. They still have at least another Sprint before they can release. The last 3 Sprints are totally focused on an admin interface for configuration which approximately 1 user will use a few hours a month.
• We’re working on an intranet project that may be releasable with one more Sprint, but the customer is currently thinking of releasing it this summer or maybe even September.

Apparently one of our more difficult challenges will be moving people to ship early and often.

I launched a Basecamp project today. Nothing fancy, just a little project site for our company’s core values committee. Yes, we fall into the Ken Blanchard Managing by Values type corporation or at least we’re trying. Anyway I’m a sucker for trying to make things better over just complaining and besides the theme this year for our annual employee offsite was Teamwork.

So far the coolest feature is that Basecamp lists the people on the project by the last time they logged in so you can get a sense in real time if people are actually using it. They just tuck it away in the right column after you log in, but I really enjoy that feature. Anyway these things often end up not being used so much so we’ll see how this goes. Since the majority of the committee aren’t IT folks, I’ll be giving a 10 minute demo on how to use it. Seems a bit odd, but then I spend a lot of time using various web applications so much of it is second nature to me.

Anyway it’s free for a single project, so it’s a great way to try it out.

Up until we brought in the suite of IBM Websphere tools and many of the developers migrated over to Rational Application Developer 6.0 (RAD), we were doing all deployments via ant. I confirmed last week that we’ve switched over in the last 9 months to almost complete reliance on building WARs or EARs from RAD via a right click on the project option.

I was reminded of the danger of this approach recently when on one project the tech lead was out on vacation and the other developer hadn’t been involved much in the setup of the project. It turned out we needed to create an EAR of the project instead of a WAR so our sysadmins could deploy the application. It didn’t need to be an EAR because there were zero EJBs involved, but that was the hard requirement.

Anyway next problem turned out to be we needed to rename the EAR file created by RAD. Turns out it relies on the name of the RAD project and you can’t actually change the name of the EAR file generated. To change it you have to change the name of the project. Since this is checked into CVS that would result in a top level directory name change. We tried a few workarounds, but the problem wasn’t resolved until a day later when the developer came back from vacation.

Just a small warning that it can be very easy to fall into some reliance on a tool and end up in these sorts of situations. The fix is luckily pretty easy as well.

• Require ant or maven build files.
• Add projects to cruisecontrol within the first day or two and include a deployment target. (Actual deployment may be harder as we don’t have a license to run Websphere on our build box.)
• Test that any developer can checkout a project and deploy the project without any reliance on RAD.

I’m going through installing MySQL 5.0 on my G5 iMac so I can progress through the Agile Web Development with Rails book. One of my brothers is going though it and wants to bounce issues off me as he comes across them. Anyway I knew the installer had gotten very easy and that it included a control panel in the System Preferences, but now there’s a GUI Administrator tool as well, nice.