Jeff Sutherland covers the familiar Scrum metaphor about pigs and chickens:

I got kicked out of the pig pen today! We just started our first official Scrum project today with the first day of the Sprint. Unofficially I’ve run two Scrum projects already though I’m working more from book/blog knowledge than deep experience with Scrum.

We have a fairly knowledgeable consultant on hand coaching us on the process. The best thing of course, the whole reason you hire consultants, is that she has a lot more experience than we do with Agile methodologies with several large clients. So I’m pretty desperate to get any help I can get, especially help we’re paying for.

I sent a friendly email to the Scrum Master for this pilot project asking if I could attend the daily Scrum with one of my employees as chickens. I was very explicit that we would just be observers hoping to pick up some tips and tricks, and that we would probably only attend 1-2 per week. After about 4 hours I got an email back explaining that it was the Scrum Master’s role to protect the team from distractions so they don’t want us to attend since the team is very fragile. Clever argument since it is a central role of the Scrum Master, too bad we hadn’t proved we would disrupt the team in any way.

I think our organization has a long way to go to get Agile. Right now we’re too scared to share.

My team has been running automated builds pretty for well over a year now on at least one project, but the bulk of our projects weren’t being built on any regular basis. I’ve been gently introducing the concept and adding all our current projects to the build cycle. This is the week where we jump in fully. Tomorrow I have a short Keynote presentation to the team explaining cruisecontrol and how it works on our little build box. The message is essentially faster feedback and faster failures is a better way to build software. I’m interested to see the feedback I get tomorrow when I present this at the weekly staff meeting.

This Friday despite spending the entire day firefighting some production deployments I got pulled aside into a twenty minute or so discussion with three of my developers. They were griping and asking about what they needed to know for their next projects.

The bulk of them have learned Java within the last year, Struts, iBATIS, JBoss, ant, IntelliJ IDEA, and JUnit. So they’re a bit tired of picking up new technologies and are just becoming profcient with the current set. The problem is management is asking them to learn the Websphere toolkit:

• RAD 6.0
• Portal and Portlets
• JSF
• Websphere Application Server
• Attunity (a SQL interface to Natural/Adabas

They’d all just gotten out of an IBM RAD class which wasn’t bad, but apparently the labs were just step by step demos and not very challenging. ‘Something a trained monkey could do.’ Anyway all of them were a bit overwhelmed with all the options in RAD and confused as to how it was going to really make them more productive.

I did the best I could to explain my personal philosophy that I pretty much agreed with them. Adding much more than one major tool or framework per project was a bit much to be expected. One of them explained that they could code something in JSF, but they just now were feeling comfortable in Struts, so doing it in JSF would take much longer.

So now I’ll go back to upper management to explain the craziness of adding so many tools at once and expecting reasonable productivity. My personal agenda is to greatly expand our use of unit testing with growth in refactoring and design experience to follow from this. Just tossing new tools on the heap doesn’t seem to help. I’m afraid though the push to use the expensive shiny new tools will override the fairly obvious logic. Sometimes you’re sort of like a second lieutenant in Vietnam as a line technical manager.

Sometimes your inadequacies hit you over your head. I got a call on my cell phone about 4:00 today. The developer on the other end asked if there was anything for him to do. I had to answer no, and I’m fighting so many fires I don’t have time to stop and help him figure out what to do. Lucky for me he’s conscientious and just taking the day off tomorrow. I’ve been a manager several years now, but I still find delegation difficult in many circumstances.

Once again this development anti-pattern reared up and bit me. I lost the good part of an afternoon because I didn’t get around to insisting that every project be build-able from it’s ant build script in any environment.

The problem all started at lunchtime. Pretty much my entire development team is in some sort of training this week, but some of them are just in the next building over. It turns out that one of my contentious developers stopped by his desk on his lunch break and worked on his current project, though nothing was checked into CVS. He then deployed the war to the development integration box and went back to class. Unfortunately the WAR developed a nasty issue pretty much right away and since one of our mainframe developers is using it to test the integration to the mainframe we had a problem.

I don’t really believe in pulling a developer out of class unless it’s a true emergency so I vowed to deal with it between bites of a microwave burrito. Two hours later I was hunting for my fourth dependent jar. As it turns out this project only builds on two developer’s desktops. There are tons of dependent jars that are just supposed to be magically installed in JBoss’s default library directory. It only took about half an hour to find the ones I was missing on my machine, but I kept getting failures from our cruisecontrol box. Turns out I have so much extra stuff installed that it was finding what it needed, but on a base install with a base JBoss it didn’t have nearly enough.

I really, really dislike non-self contained projects. And I despise hunting down dependencies just to get an application to compile. After the jars got resolved another hour later it turns out theirs some properties file that appears to be nowhere in CVS. I guess I was supposed to know about this magic. Since it contains the connection parameters to make an RMI call to our legacy mainframe the application bombs real fast.

So by the time I had to go pick up my daughter, the application was still failing on the buildbox so I still can’t fix it on the integration server. I’ve had to check in a lot of things into the project to get it to this stage which will probably cause the developers some grief, but at the end of the day I think they’ll understand how their current practices have led to a fairly untenable situation:

• The project has two developers so if they’re both out no one else can build the system without hours of pain.
• Leaving dependencies on jars on app servers is great until someone deletes one, upgrades it, or just wants to port you to something other than JBoss.
• If your automated build tool can’t build the project from scratch, neither can anyone else unless they have some tribal knowledge.

OK, enough ranting.