Legacy Teams

One of my more read books in my library is the very excellent Working Effectively with Legacy Code by Michael Feathers. The book is a great resource when you are plopped down in front of a bunch of legacy code, and need to figure out just how to move forward.

This evening I was writing a post to a mailing list and realized that the current team I'm with has a legacy team problem. We'd like to be collocated, we'd like to have product owners onsite, etc, etc. However, due to some very specific circumstances, that isn't possible right now.

How do you deal with legacy team challenges?

Project versus Program Management

Glen Alleman has a great post on the differences between project versus program management. Some of the highlights:

* The project manager tries to keep change to a minimum while Program managers expect change and even embrace it

* Success is measured by budget, on time, and products delivered to specification versus Success is measured in terms of Return on Investment

* Leadership style focuses on task delivery and directive in order to meet the success criteria versus Leadership style focuses on managing relationships, and conflict resolution.

Dilbert for Management

Over on the Agile Project Managers list, Jonathan House proposes the following:

I think that it's high time that a new school of management emerges that uses Dilbert as it's cautionary statement - if what you are proposing as a manager has ever appeared in a Dilbert cartoon, you need to re-think your proposal. Of course this assumes that said management can grasp the highly technical nature of Dilbert content.

http://www.flickr.com/photos/cote/63914774/

TDDing .NET's FileSystemWatcher

I'm working on a project where we are automating the notification of a project management system. The storage mechanism is all XML files, so we're using the FileSystemWatcher. Since I wear a green Test-First wrist band I wanted to find a way to write this test-first.

The logic that we are working with is that when a notification is fired, we have to ensure that the file is on a watch list, and if it is, we bubble the notification up. The first test ensures that all notifications are bubbled up if there is no watch list:

[Fact]
public void CardWatcherFiresProjectCardChangeEventWhenFileCreated()
{
   CardWatcher watcher = new CardWatcher(@"C:\");
   bool projectCardChangedCalled = false;

   watcher.ProjectCardChanged += delegate { projectCardChangedCalled = true; };

   MethodInfo createdEvent = watcher.GetType().GetMethod("fileWatcher_Created", BindingFlags.NonPublic|BindingFlags.Instance);

   System.IO.FileSystemEventArgs args = new System.IO.FileSystemEventArgs(System.IO.WatcherChangeTypes.Created, @"C:\", "test.xml");

   createdEvent.Invoke(watcher, new object[] { null, args });

   Assert.True(projectCardChangedCalled);
}

First, I wrapped the FileSystemWatcher in my own class so I can expose what I need. I then expose a domain event - ProjectCardChanged - which will be the actual event bubbled up to the application. I then register as a listener for the domain event, and fire the actual event the FileSystemWatcher will raise using reflection.

This allows me to remove dependencies on things like file systems until I really need them for integration tests. It is a little longer test than I like, but really allows a good flow to be created with keeping the tests going.

Examples as Requirements

At the Agile 2008 conference this year, I had the chance to run into Keith Braithwaite after Ron and Chet's talk about agile practices. One of the things we talked about was Brian Marick's examples (a.k.a. "An Example Would be Handy Right About Now").

I've given lots of thought about examples over the past couple of years, but something different happened during my conversation with Keith. The idea that instead of collecting business requirements from the customers, we collect examples. An entire system spec'd out by the programmers and business analysts communicating in examples.

The reason that this really hit home was something J.B. Rainsberger mentioned about the 5 Dysfunctions of a Team, and how some of the agile practices are actual worse to start with if the team hasn't overcome some of those practices.

Combining those two ideas together - the thought of a collaborative environment where there is enough trust and communication to allow examples to be the defining language of the system - well, that just sounds like exactly what I'd want.

Right-Click mapping for CoRD on OSX

If you are using CoRD to connect from OSX to a Windows machine over RDP, you may initially be confused as to how to do a "Right-Click" - especially if you are on a MacBook like I am. Have no fear - do a "Shift-Ctrl-Click" to access all the Right-Click goodness.

Presentation: Adopting Agile

Last night I presented at the Agile Tampa meeting at the new Microsoft office here in Tampa. We covered adopting agile practices in an organization. The important take away was that you don't want to just adopt practices blindly. You have to take into consideration things like the adoption model (from Crossing the Chasm), the Dreyfus Model of Skills Acquisition, and the Five Dysfunctions of a Team. Then ask your self why you are wanting to adopt things - what you are wanting to change. Then you can prescriptively introduce practices. Finding out why can be as simple as asking or holding a retrospective.

The presentation is available for download here: XPAndScrum.ppt

Thanks a ton to Joe Healy and Microsoft for providing the space, and to AgileThought for the food!

Agile Tampa Meeting This Wednesday!

Just a reminder that this Wednesday (August 13th) is the next Agile Tampa meeting. I'm speaking this month on a talk titled "XP and Scrum: Tools and Practices for Making Your Organization Agile". Pizza starts at 6pm, and the talk starts at 6:30pm. Michael graciously says it will go till 9pm, but I promise not to talk for that long. ;)

Hope to see you there!

Off to Agile 2008

It's that time of year again! Agile 2008 starts on Monday in Toronto, and I'm looking forward to it. I do have some concerns about the quality given the number of people (1600) coming to it. They used an interesting stage concept this year, so we'll see how that goes.

I've also joined the Twitter world, so you can catch me on there at cory_foy.

Hope to see you at the conference!

Shining a Light on Processes

It's late at night. You've gotten hungry or thirsty, and have decided to pop down to your kitchen for a snack. You just want to grab it and go.

Halfway through the kitchen, you hear something skittering across the floor. You also hear a strange sticky sound, and what also sounds like water dripping. You grab a bottle of water off the counter, make a break for the stairs, and run back to your room - heart beating a little harder, breath coming a little faster. But you've got your water, and you drift off to sleep.

When the morning light comes, you discover that the water was a pipe dripping everywhere. It appears to have ruined your cabinets, and you are so furious, you don't think about the other things you heard the night before.

This scenario seems to play out time and time again on software teams I work with. They have a goal. They are doing everything that can to get to it. They know that there are bad things lurking around, but they'd rather leave it until the morning. Sure, their body may have to work a little harder, maybe some overtime (or a lot of overtime), maybe not sleep, or eat junk food. But all of that is better than turning on the light and facing the problems that are really there, right?

This past week I've been working with the team to prepare them for our first iterations which start on Monday. Previous to my start, they had done things a pretty standard way - dump a bunch of stuff down to do, wave their hands and say they can do it, and then make a mad dash at the end to get it done. And when it is all over, do it again. This group, thankfully, had begun preparing themselves with flashlights, but even with that, the throwing on of the kitchen lights has them still adjusting a bit.

To understand why, let's look at some key agile practices:

• Estimation - We've moved away from hour estimates to a relative, effort-based estimation system. So if something is twice as hard as another thing, the latter is a 1 and the former is a 2.

  This is challenging, because before, teams could just fake that they can accomplish things in a super human fashion ("40 hours to do that task? Sure we can have it done in a week!"). Using velocity, we have an objective measure of what they can accomplish. It still can be gamed - but mostly at a detriment to the team



• Iterations - The key here isn't creating some window to work on tasks in. It is defining "done" - what has to be finished in order for a task to count as complete. Previously, many teams would be code complete, and thrown it over the wall to QA. On the teams I'm working with, we've defined done as code complete, some level of testing from QA, and some level of verification by the customer/business. I've kept it somewhat vague because I'm working across 6 teams, and I want them to define their own version of done. But having to take accountability that just because you hit compile doesn't mean it is done is quite a shift for many developers.


• Daily Stand-Ups - Having to stand in front of your peers and say what you did yesterday, what you are doing today, and what is blocking you is scary at first. Most people just come into work, zone out on tasks, and head home at the end of the day without really thinking all that much about it. These meetings have the dual-effect of focusing the teams on what is going on, and sharing information that otherwise might not be shared. But keep them quick


• User Stories - This was an interesting one. Which task would you rather work on - "Add a form for choosing a user" or "When a user goes to the Foo screen, they can click on a button which pops up a People Picker similar to what we have in Ghazoo product". Identifying the weakness in communicating the requirements is helpful for a couple of reasons - it helps clarify what the devs are going to do (and how the customer wants it done), and it gives everyone a head start on testing, since you have an idea of how it is supposed to work


• Velocity - This is perhaps one of the most important one. Developers are an optimistic bunch, and will happily tell you they can build you a whole, brand-new auction site in a day or two. The business will happily accept that, even though they know there's no way it is going to happen. Velocity switches it around to say, "Here's what we're capable of - what can we fill it with?" instead of, "Here's what needs to be done, can we get it all done?"

I really applaud the team I'm working with right now for the great shifts they've made over the past couple of weeks. Some of the practices they were heading towards, but we've taken it further than I think they would have, and that can be scary. Because when you turn on the light, you might find a family of hamsters running across your floor, jelly smeared all over the counter, and a huge, watery mess. Or you might find out that the water leak has only just started, and with a turn of a wrench, you were able to fix it right then and there.

But before you can do anything, you have to turn on the light. Go ahead, do it. I'll be here with the Raid, a pipe wrench, and some paper towels.

(And if you are going to be in the Tampa area on August 13th, be sure to come to my talk at Agile Tampa where I'll be covering many of these and more)