11 September 2006

Remembering

On Tuesday morning, September 11, 2001, I had arrived at my client's office around 8:20. This client had some of its employees on strike at the time, and I waited while they politely talked to everyone passing through the picket lines. It took about 2 minutes for each person to pass which wasn't too bad, I thought. After I made it into the building, I went straight to the cafeteria to get a coffee rather than going to my desk first. I got the coffee and made my way to the elevator. Someone said that a plane - they thought it might have been a 737 - had hit one of the World Trade Center towers.

But it's such a beautiful clear day.

That was my first thought. Then I remembered that a B-25 Mitchell bomber had crashed into the Empire State Building in 1945.

It must be crappy weather in New York.

I thought briefly about what a monumental rescue operation that was going to be, and headed up to my desk. It was about 8:50 AM.

A few minutes later, someone came out of their office and said that a second aircraft had hit the other tower. I, and many others, knew right there and then that this wasn't an accident. I remember someone saying, "This is war!". I didn't realize how right that person was at the time.

We tried in vain to check some of the web sites such as CNN and The Globe and Mail, but they were overloaded with traffic. We eventually found some French-language sites that were still available, and news came that a third plane had hit the Pentagon. I went down to a boardroom where a TV had been set up, arriving just in time to see the South Tower collapse. I know my mouth fell open, and so did those of many others in the room. Shortly thereafter, my manager came by and said that there was an evacuation order. No one knew why, or even knew if it was real, but no questions were being asked. I headed for the parking lot around 10:30 AM. On the way home, reports came in that United 93 had crashed in Pennsylvania.

I'll be honest - I was scared. At the time we lived relatively close to the airport in Ottawa, so I was watching for anything strange in the sky.

I picked up my son from day care, and went home. He was 3-1/2 at the time, so he didn't really know what was going on. So, the rest of the day with him was spent acting "normal", with occasional glimpses at CNN or the Canadian networks to get updates.

After all North American air traffic was grounded, it became eerily quiet except for the occasional 747 passing overhead on it's way to quarantine at Toronto Pearson.

Five years later, it's once again a clear, cool day in Ottawa - quite similar, in fact, to this day in 2001.

The world isn't, though.

6 September 2006

Americans

In Canada, at least, Americans have a reputation for being loud and rather obnoxious. I have an uncle in San Diego who fits that stereotype perfectly, right down to smoking a cigar! Of course, the loud part could possibly be attributed to hearing problems, but why break a good stereotype? ;)

I've had the chance over the past few months to spend some time in the U.S. in Missouri and Colorado. One thing that struck me immediately was how friendly people were. Walking down the halls of a place where I had never been before, practically everyone said "Hi" or "How are you doing?" or, in Colorado, "Howdy!".

Canadians, I'm told, have a reputation for being friendly, polite people. I walked into the office this morning, and had only one person say hello, and that was someone I knew. Everyone else was doing their best not to make eye contact in case they then had to say something.

Of course, some of the people in the U.S. who said hello could be serial killers and those who didn't in Canada could be the nicest people in the world. However, such a small, simple thing certainly makes me feel more "at home". Maybe it's owing to my small-town roots, maybe not... I don't know. Perhaps the places where I was staying were more friendly than others. Again, I don't know.

What I do know, though, is that it's something very simple to do and I'm going to continue to do it myself.

5 September 2006

Transitions III - Way Cool!

I've had my new MacBook Pro for over a week now, and despite a few quirks learning how to translate 16 years of PC keyboard habits, it's going very well! I've installed FireFox, Eclipse, Skype, etc., with hardly a hitch. I connected to my wireless network at home effortlessly, and transferred a whole whack of stuff over from my other laptop and desktop machines.

After using just the mousepad for a few days, I decided that I'd get the add-on BlueTooth mouse. However, I didn't find the time to go out and get one, so I tried my little Microsoft wireless USB mouse. Lo & behold, it worked perfectly including right-clicking! Funny how Apple doesn't advertise that. :) It does feel a bit strange using MS-branded equipment on a Mac, though.

I haven't yet tackled the task of installing BootCamp or Parallels to allow the use of Windows XP. There is some software I need that only has a Windows version at the moment, so I will have to sully my otherwise pure Mac with that other operating system.

More to come...

22 August 2006

Transitions II - Back from the Dark Side

I mentioned in Transitions that I'm starting with Industrial Logic in, well, a week! As part of my new job, I'll need a new laptop. I was given the choice of an IBM tablet, and IBM ThinkPad and a MacBook Pro.

Waaaaaay back in mid to late 80's and into 1990, I used a Mac alongside 3270 terminals and UNIX workstations. The Mac was for the managers, so that they could do their spreadsheets, etc. in something more user-friendly than the mainframe spreadsheet application. It also meant the they could print immediately, rather than having to wait up to 2 hours for a print job. I wrote a couple of support applications on the Mac, and just loved it! I guess I was predisposed to liking Apple since my first experiences with computers were on a 48K Apple ][, and my first machine was a 64K Apple ][ clone.

So, I was quite excited at the chance of actually using a Mac once again. I did have some trepidation, though, about whether I would have a significant learning curve after 16 years on the Dark Side, and wasn't sure if I would be able to use the same tools I do now. I consulted J.B. Rainsberger, Dave Astels and my good friend Jim Leask, all of whom are currently using Macs (although Jim isn't using one yet for real work). They assured me that not only are most if not all of the current tools are available in OS-X versions, but in many cases there are even better tools. Plus, with utilities such as BootCamp, Parallels or simply vmWare, I could still have that cheap Mac clone OS available if I needed it. ;)

So, according to Fedex, my shiny new MacBook Pro was shipped from Shanghai this morning... well, their morning, which would actually be yesterday here... or something like that. Regardless, Transition II will begin shortly. I can't wait!!

14 August 2006

Transitions

A number of months back a posting on the XP Job list caught my eye. It was for an Agile Coach position with one of the companies at the tip of the agile spear, so to speak.

Despite the fact that I have been an independent consultant for over 12 years now, I thought that it was an interesting enough opportunity that I should look into it. So, off went my resume. I heard back from them after a day or two, and we did some interviews over the phone. Next thing I know, I'm on a plane to the Bay Area with a Led Zeppelin song in my head (that would be Goin' to California for the younger readers! ;) ).

After my first real interview since about 1990 or 1991, I was set for a bit of contract work over the summer. During that work, I was officially offered an Agile Coach position, and I accepted it.

So I'm quite pleased to announce that, beginning in September, I will be an employee of Industrial Logic!

It's with mixed emotions that I'll be closing up the store, if you will, for Mayford Technologies. I started the company shortly after I had heard about Extreme Programming, and have ridden the highs and lows of the agile adoption curve here in Ottawa. I have tried (and I hope succeeded) to get Agile on the map here, and will certainly still be involved in the local Agile community.

It has been a good run for the past 6 years with Mayford, but it's time to move on to bigger and better things and this position with Industrial Logic is certainly that.

Many thanks to all who have helped me to get to this point - you're too numerous to mention - and I'm really looking forward to being the local presence for a great company with great products and Agile training services.

4 August 2006

Professionalism

My disgust at the quality of the code on a project I joined in March came to a head a few weeks back. I remember when I started, looking at some really crappy code. I thought, "Wow - this is a real opportunity to do some good, cleaning up this mess!" I didn't realize that after 18 years in this business I could still be naive!

I had heard the almost apologetic comments from some people on other projects who had been around for a while... the original developers were hired right out of school, and their designer didn't pay much attention to them because that person was involved in a few projects, etc., etc. However, what gradually bothered me to the point of blowing was that not only did the original developers have nary a clue about O-O development, but later, more experienced people just exacerbated the problem.

I can't remember ever seeing code as tangled as this is. I would like to use the term Big Ball of Mud to describe the code, but that would be unfair to mud. Coupling doesn't begin to describe it either, and code reuse was strictly through copy and paste (there was a lot of "code reuse"!). A transaction from a business perspective could consist of several different interactions with the database, each of which using it's own Connection, and some with autoCommit set to true! This created many situations in which data was left in an inconsistent state that was, at times, impossible to fix.

In one case, we detected a logic error in some code that determined if a database insert or update should occur. I fixed that error and suddenly 3 more cropped up. Other code had been written that assumed the error was there!! AAAAAAAAGGGGGGGHHHHHH!!! My early naivete was quickly overcome by the pressing need to just keep the system afloat so that the Customer could do their job. As a result, many relatively straightforward but "deep" refactorings kept being pushed back owing to more pressing work.

The data access was all pure JDBC, with no abstractions to simplify the code. I found several instances where PreparedStatements and ResultSets were being created and accessed within loops, but only closed outside the loop. I'm not a really deep bit-twiddler, but that just stinks to high heaven of a memory leak! On top of that, the DAO's consisted entirely of static methods, meaning I couldn't just pull out an interface and use a mock for testing.

Two weeks ago, another developer joined the team. He had been working on another project at this client and sat close by, so I knew him a bit and knew that he seemed like a decent developer. After he saw the code for the first time, he said he was kind of excited because it looked like a real opportunity to do some refactoring. The first thing he was going to do was change the DAO's to no longer use static methods, extract an interface and start using mocks to allow testing. :) Two weeks later, he now understands my frustration!

My real frustration, though, is that people were paid to produce this shit. I'm sorry for the expletive, but that's what it is. I even sent off the link to Uncle Bob's We Will Not Ship Shit article on Artima to the rest of the team. The people who worked on this system were supposed to be professionals. However, they didn't have a bloody clue about the principles of object oriented development. OK, so the original developers were young and inexperienced. I guess they skipped a few too many classes during the OO lectures, or whatever school they attended didn't venture much further beyond Hello World in the labs. However, those developers were replaced with experienced people. Those people should have known better. When I see work such as this system, even I start to believe that the software development aspect of the IT industry needs some sort of accreditation system that requires an apprenticeship period in addition to education.

After about a month on the project, I sat down for a chat with the team's manager. I talked about the state of the code, and how in terms of technical debt this was way beyond the Hired Goons stage. There was a full-fledged hit out for this piece of crap. He asked what I thought about re-writing the application, and I immediately agreed that it was about the only way to make progress. Fortunately, that's about to begin in the next few weeks. Unfortunately, I'm leaving that contract at the end of August. Maybe the other developers will be more productive after I leave because they won't have to listen to my incredulous remarks from my cubicle, "Oh my... what the... what the hell were they thinking?!!" I'd like to put a smiley beside that last sentence, but I do that almost every day.

Ironically, in the Customer's eyes the members of the development team are gods! They've been dealing with a dysfunctional system for so long that any improvement is seen as a breakthrough. I can just see it now... once the properly rewritten system is in place and has few if any production defects, the developers will be mere mortals again and will be in the dog house if even a single bug is found!! Remember, you heard it here first. :)

24 May 2006

Getting a Clue

A post on TheServerSide.com entitled Java Succumbing to .NET in my Organization this morning had a little clue in it about why I believe that good Object-Oriented systems are relatively hard to come by.

In the post Neil Chaudhuri the author states:
After talking with some of the developers who are in the trenches, most of them are happy to move to .NET. This even includes some who, like myself, have been certified in and built a career on Java. Apparently, Java is just too hard and too intimidating, especially for beginners.
Interesting. It's also quite enlightening. What that tells me is that there is a metric crap-load* of developers out there who simply don't get OO. They prefer the development model of sticking code behind a form, à la VS2003 and its predecessors back to VB 1.0. Perhaps they might get fancy and use helper classes to encapsulate some business logic, but generally I believe that a majority of programmers out there don't have a clue what OO is really about.

This is where there is a very important distinction: there are programmers who can use objects, and programmers who can build OO systems. The former are the ones who like to put 500 lines of code in the onclick event of the OK button on a window. The latter are those who can build practically an entire system with any particular user interface. Of course, there is a spectrum of talent for both of these groups, but I firmly believe that there's a disconnect, a chasm if you will, between them.

I can say that I was in the "uses objects" camp at one point. I first started working with OO languages around 1991. Looking back, it took a few years before I made the leap across that chasm to the "builds OO systems" group. Today, 15 years later, I'm still learning on a daily basis and suspect that I'll continue to do so until I stop coding (which will likely coincide with a cessation of vital signs!).

So, with respect to the post on TheServerSide.com, it's just another symptom that many, many developers don't get object orientation. Given an object, they can write some nice procedural code around it, but they don't understand the abstractions. They believe that OO is simply inheritance for the sake of reuse. They think that patterns are something for making clothes. They believe that domain modelling has something to do with figuring out what the next group of suffixes such as ".com" will be.

They need to get a clue, or Object Oriented Programming with all of its benefits will eventually die.


*Jim Shore also uses this term. I swear I didn't steal it - I've been using it for years!!

15 May 2006

Cool Kent Beck Quote of Bruno Schmidt

In an XP Yahoo group messsage, Kent Beck relayed a paraphrased quote from Bruno Schmidt of Intelliware:

"Bruno pointed out the effects of water. If you have a mountain and water in conflict, bet on the water. The water knows where it is going--downhill. It actively works at getting there. If it gets blocked, though, it doesn't hammer away at the mountain, it flows around. Eventually, the water gets where it is going."

Definitely food for thought, especially with teams or managers that manage by crisis.

13 May 2006

Spiccoli Stories

I was pair-coaching at a client this past week with with Curtis Cooley of RADSoft. The client had a great team room, with whiteboards and flip-chart sized post-its everywhere. They had a section for prioritizing Stories that was divided into 4 levels - Low, Medium, High and Most High.

Curtis mentioned that the top ones were Spiccoli Stories. It only took a fraction of a second to hear a voice from 1982 saying, "Most high, Mr. Hand!"

Henceforth, really important Stories will be dubbed Spiccoli Stories. Thanks Curtis!

26 April 2006

Vindication!

I first learned about Extreme Programming back in late 2000 while working on a large federal government system called the Global Case Management System (GCMS). We were starting to build the framework for an "army of Java developers" to use, but were stopped dead in our tracks after a few weeks when management was told they had to evaluate COTS products for the system, or they wouldn't receive additional funding.

Essentially, the decision had already been made by the time we performed our first demo of the framework. There was talk of using the framework to handle other applications that "didn't fit in" and such. Management had seen the shiny, flashy demos, and actually believed the promises that 85% of their functionality would come right out of the box. We warned them that those promises were BS, but I suppose we were seen as having a self-interest in the system being built in-house.

The main thing was, we told them that it would be a disaster. In the ensuing 5 years, we have also watched it be a disaster although with other elephants such as the Firearms Registry dancing around, this project wasn't noticed. Well, today one of my colleagues from that project sent me a link - the project has been noticed!

I'm sure there are people over there who are... well, I can't say that in a family forum, but suffice to say that they're not happy. They have been hiding this fiasco for a good 3-4 years, and now they're going to be called out on the carpet for it. What's even worse is the fact that the project was Citizenship and Immigration's 3rd attempt to replace its legacy applications, each previous attempt ending in failure. I suppose at least this time they put something in production. However, the new system that is in production only replaces a fraction of the functionality in the 2 main legacy applications.

At any rate, I feel a certain sense of vindication since we warned the top manager of the GCMS project in February 2001 that a COTS solution wouldn't solve their problem. Along with that sense of vindication, though, is anger at the waste of money and the stress that the people on that project have been under. The people who made the high-level strategic decisions, i.e. those who should be accountable, are long gone and someone else will have to clean up the mess.

2 March 2006

XP and Goal-Directed (c) Development

I started a new contract this week, in a group that is using XP merged with Alan Cooper's Goal-Directed development (c).

I must admit that it's very refreshing coming into an office with multiple teams, and hearing people having standup meetings, talking about Stories and acceptance tests, etc. There seems to be a real sense of buy-in from this development group for agile principles and practices. It's also gratifying in the sense that I was brought in to do an XP presentation at this client a little over 2 years ago, and I can see tangible results of that work!

This group has for several years now worked on many smaller projects with only 1-3 programmers. What's different about them is that they have almost always had an interaction designer work directly with each team, and this seems to have made a significant positive difference in the quality of the systems. The ID also acts as a tester for the application, although some of the larger systems have testers as well.

At any rate, I'm intrigued by the way they have consciously merged XP with Goal-Directed (c) development in a way that seems to use the best of both worlds. As I understand Goal-Directed (c) (and Alan Cooper's rants about XP), it suggests doing Big Interface Design Up Front. This development group, from what I've seen so far, does Medium-sized Interface Design Up Front and tweaks the interface during development based on Customer feedback.

It seems to be an interesting mix, and I'll keep my eye on it over the next month that I'm there.

21 February 2006

Agile, circa 1988

When I first heard about Extreme Programming back about 5 years ago and poked around its practices, I recognized the On-site Customer as one that I had done before back in 1992-1993 and found it very beneficial. So, I decided to get together with my manager from those days to discuss the motivation for co-location, when conventional wisdom at the time was to keep the bloody Customer as far away from the developers as possible in order not to disturb them!

I started off the "interview" with a request for a history lesson on the creation of the Whole Team. What ensued was a description of Agile Development that was only missing automated tests.

This project started in late 1987, and was for a public sector organization's HR system. It was intended to handle functions such as classification, staffing, staff relations, and training, and would be written in PowerHouse on a Data General mainframe. My old manager decided at the time that he was tired of having 2 roles in charge of the project - the Customer in charge of the requirements and providing the funding, and the IT group in charge of building the system. The Customer would throw their requirements together and hand them to the IT group to be implemented. When, 18-24 months later, the system didn't do what the Customer wanted, IT became the scapegoat.

Additionally this manager felt, and continues to feel, very strongly that a good overall multidisciplinary team was essential to success. So, he pushed hard to be placed in charge of all people who would work on the project. This wouldn't mean that people would change the actual reporting relationships, but rather that while working on the project they were part of his team. These people included the development team and the business or domain experts, which was the departure from the past. He was given complete control over how the team worked, and how the system would be developed and deployed. He had already realized that the absentee Customer was a non-started, so he insisted that the development team and Customer sit together - the On-site Customer.

The next step was to figure out what to build. The development team sat down with the assembled domain experts for the different parts of the HR process. They started by talking about the first event in the process of hiring someone, and then stepped through that process to retirement. This wasn't done at a ridiculously detailed level, but rather in terms of the titles of the different steps in the process. With these basic steps in place, this group then determined what part or module of the system needed to be built first. Bear in mind that most of these modules were quite dependent on the others - you couldn't build one and leave the others as manual processes. Regardless, the development was broken down into these modules so that development would be focused, and in order to minimize the risk that the system as a whole would never ship.

For that first module, the development team really didn't have a concrete idea of how big it was, or how long it would take to develop. They knew it wasn't too big, and that there wasn't much risk that they wouldn't be able to develop it at all. They communicated all of this to the Customer, which was another departure from tradition at the time. The development team, mainly the manager also explained that this first module would very much be a learning experience, and would likely be completely rewritten over time. They essentially performed the Planning Game, and Refactoring.

So, the team built that first module, and it took a bit longer to build than they anticipated. However, the Customer was kept in the loop at all times and could see the progress of that first module. When it was completed, the team and the Customer sat down to review how things went (a retrospective) and to plan for the next module (Release Planning). The team had learned quite a bit, and shook out a lot of issues along the way. Even though they hadn't actually shipped anything to production, they had already built up trust with the Customer.

When they started planning the work on the next module, they had the domain experts of the each of these modules in the room. The expert for the first module was asked, "On a scale of 1 to 10, how big would you say that module is in the overall HR process?" The person answered, "Three." They then asked the expert for the second module, "How big do you think this next module is?" They responded, "Nine." With that answer, the team then estimated that developing the new module would take 3 times as long as the first. Forget COCOMO, forget Function Points, they just tripled their time based on the Customer's evaluation of how big in a relative sense the next module would be. The time estimate and budget for the new module were based on Yesterday's Weather. And, they were right. Remember, this was 1988!

This process was repeated for each of the mandatory modules, and the system was placed into production in late 1989 or 1990. The full production cycle had taken 2 years, but the Customer (in the form of domain experts for each module) had been involved from start to finish.

I didn't actually join the team until early 1992, when I was hired on contract to evaluate the progress on a stand-alone interim version of the training module being developed in the same general group as the main HR system, but as a separate product. After a day or two I recommended a rewrite, and found myself the lucky winner of the contract to perform that work! I was immediately placed in a desk in close proximity to the Customer for the system, and worked very closely with her over the next few months to build it.

The interesting thing about that training system is that it had been intended from the start to be included in the main HR system. However, it wasn't a core part of the HR process, and it never reached a priority level required for it to be incorporated. Again, the organization as a whole identified the modules, and prioritized them according to the overall business value. For the training module, it could provide equal value in an interim, desktop system while the main team focused on the higher value modules. (As an aside, that training system was called ITS - Interim Training System - and was first released in 1990. In 1995 or 1996, I finally convinced people that the 'I' should be changed to mean something other than Interim so it became the Integrated Training System!)

Meanwhile, the main system was having releases to production every 8-12 months. When the government department for which the system was built merged with a larger department in 1993, it was decided that this system would be the HR system for the new department. In 1995, PeopleSoft arrived on the scene and was to replace what was now perceived as an old, character-based mainframe system. The head of HR (the Gold Owner) made it abundantly clear that PeopleSoft wouldn't replace the system until it provided the same level of functionality. PeopleSoft, the last I heard, is slated to roll into production in 2007.

So, I came away from my meeting this morning with a renewed sense that I had been part of something quite special, although I didn't consciously know it at the time. Many of the development practices from XP/Agile such as automated testing and true iterative development weren't done, but the overall team practices were. We had the On-site Customer, Planning Game, Frequent Small Releases, Collective Ownership, Refactoring (although not in the modern sense), and Sustainable Pace (there was overtime, but not all that often).

We were successful. We were Agile!

16 February 2006

The Disengaged Customer - For want of a Product Manager

In The Disengaged Customer - Balkanization, I discussed how the Customer's organization began to work against itself as the system grew to incorporate different business lines (and thus different stakeholders).

A picture emerged from all of this where the team had originally built the system for a single Customer handling a single line of business. Using XP worked wonderfully in that situation. Then we added another line of business, with its user community. That process went OK, but not as well as the original line of business since we had a shuffling of our Customer, and no real feedback on the new work. Then we added another line of business, with its community including the old Customer mentioned above. As new lines of business were added and encompassed new user communities, the complexity of dealing with those people increased dramatically (I’d argue exponentially).

The problems came to a head shortly before I left. Again, the limited communication between the Customer’s organization and the development team caused a misunderstanding to occur, and the Gold Owner took it out on our Kevlar-underwear-wearing manager. I was pretty ticked at that point about the whole issue. Our manager met with the Gold Owner, and it finally became clear to her what was happening. There was talk of “a lot of crying on the floor” when the Gold Owner was done dealing with some of the people. The development team had been absolved of most of the blame, and we were going to get our Customer back and engaged.

I spoke a few days ago with one of my now former colleagues on that project. The Customer had been diverted to focus on a “problem child” project. Plus que ça change…

In all of this, the Gold Owner had her own vision of how all of these lines of business should be integrated to support the organization. This was a good thing, in fact an excellent thing, except that she wasn’t the Customer. I dearly wish she had been, since that vision was an excellent way to categorize and prioritize the work. It also would have meant that the Customer was in a sufficiently high position of authority to be able to deal with the Balkanization issue. That person would have effectively been what Jim Shore refers to as the Product Manager.

As a Product Manager, she would have been in a position to either directly enforce some discipline on the organization, or to escalate the problems very quickly to someone who could. With her vision, she would have been very easily able to establish priorities and to weed through issues that may have seemed important to individual stakeholders, but weren't all that important to the organization as a whole.

A healthy dose of financial oversight would likely have helped as well, but that's another issue.

The Disengaged Customer - Balkanization

Wikipedia states that, "Balkanization is a geopolitical term originally used to describe the process of fragmentation or division of a region into smaller regions that are often hostile or non-cooperative with each other." This was a very bad thing in the Balkans. It's also a bad thing for the Customer.

Sometimes, agile teams can be victims of their own success. The Gold Owner sees that all is going quite well with the project, and has the Customer disengage somewhat to deal with other issues. In The Disengaged Customer – A Funny Thing Happened… I spoke of the effect that this disengagement had on the team’s development efforts. Without the Customer being fully engaged on the project, communication became more difficult and much lower bandwidth and the team drifted. Eventually, the Gold Owner chewed out the development team’s management over her perception that the team wasn’t doing the work that they were supposed to.

At that point, the team took on new development to replace an old system by integrating its functionality into the system. This meant that they were dealing with new users, although with the same Customer who was still rather disengaged. However, by having an existing system from which to work we were able to move ahead reasonably well. This was when we began to realize that there were, um, some issues in the Customer’s organization.

The person who had been the Customer for the old system was retiring. She therefore wasn’t the Customer for the new system, although she was always sought out for input and information due to her experience in that business line. She did have some quirks, though. The biggest was that she insisted that the statistical reports generated from the system be clean. That is, the totals at the bottom of the report should equal the sum of all the data. That makes sense, of course, except that the data received in the field and entered into the system were rarely like that. Often data were from third-party providers who didn’t really have much interest in capturing the details of an event, other than it happened. As a result, the system contained a considerable number of fields with the value of Unknown.

The Customer for the older system didn’t like Unknown. It didn’t look good. To her, it meant that people weren’t doing their job. So, she had directed the developers of the old system to create default values, for example if a report came from a particular country but didn’t have any city information, the system would set a default city. She was also given the ability to edit the data after input, which allowed her to clean things up even more. This was fine for true data entry errors, but she used it to massage the data to better fit what she saw as proper. So, the statistics generated by the system were very clean indeed. They were also pretty close to fitting the saying, “Lies, Damned Lies, and Statistics”.

So, when we as the development team embarked on developing the new replacement system, we were dealing with a new Customer. This Customer didn’t know about the data massaging, but when told immediately directed that it stop. The new system wouldn’t default values like the old, and the ability to make edits after the initial data entry would be limited and audited. This didn’t sit well with the old Customer, and things became, um, tense.

Meanwhile, we were directed to look at revamping a small chunk of our system. No big deal, really, we discussed it with that particular user and in conjunction with our Customer created the stories to make the changes. Then that user left on stress leave. When it was deemed that we should start work on the changes, we ran them by the new replacement user, again in conjunction with the Customer. The new user indicated that the changes were all wrong, even though they had already been approved by her management. Those changes were on hold as of the end of January when I left the project.

The Customer was quite frustrated at this point, having to deal with her peers and not being able to get any consensus. She didn’t know the lines of business as well as these other people, so she didn’t feel that she could make the decisions on her own. Sometimes she did, and people went behind her back to the Gold Owner and complained. Other times, these other stakeholders would talk directly to the development team members, giving the impression that what they wanted had been cleared. The Gold Owner didn’t really understand that the development team needed the Customer’s single voice in order to be able to proceed. In essence, the Customer organization had become Balkanized.

Continued in The Disengaged Customer - For want of a Product Manager.

14 February 2006

The Customer Role in Agile Development

Lack of user involvement traditionally has been the No. 1 reason for project failure. Conversely, it has been the leading contributor to project success. Even when delivered on time and on budget, a project can fail if it doesn't meet user needs or expectations.
Software Magazine, Feb. 2001, Collaborating on Project Success
Based on the Extreme CHAOS 2001 Report from The Standish Group.

Agile development teams deal with the issue of customer involvement by having a person who is empowered to specify the User Stories, set their priority and to answer questions about them in order to clarify the real requirements. Ideally, this Customer is co-located with the development team, although an even better approach is to locate the team with the Customer.

The effect of having the Customer working so closely with the developers is twofold:
  • Communication improves dramatically. Verbal discussions provide much more valuable information than e-mail or hard-copy documents, and thus costs and the time taken to make decisions are reduced. This isn't to say that no documentation is produced, but rather that the documentation should be the result of a conversation first, and not vice versa.

  • Decisions are made more quickly. Because the Customer is readily accessible, questions can be answered and decisions made in very short order. This allows the team to keep moving forward, rather than waiting for answers or performing speculative work.

"The Vision Thing"

Because of its importance in ensuring the success of a project, the Customer role requires certain traits in the person who fills it. They must be able to make informed decisions quickly and not waffle on their answers. If they don't know the answer to a question, they need to be able to say so and then follow through with getting the answer as quickly as possible. They need to know the business that will be supported by the system quite well. They also need vision.

For a small system with a focused group of users, having an end-user as the Customer is fine. When a system is larger, for example it consolidates several lines of business, the Customer needs to have an overall strategic vision of how the system is going to be used to support all of its users. This requires someone at perhaps a management level, or they have a reporting relationship with C-level management. This is required because the issues faced by this Customer increase considerably with the number of lines of business in the system. Often, these issues require resolution from a higher level of management, and having a Customer either at that level or with a direct reporting relationship to that level will speed the resolution process.

Issues
More than One Customer

What happens when a system has multiple Customers or Stakeholders? Getting multiple Customers to agree on the time of day let alone User Story priorities is very difficult task. In situations such as that, there needs to be a higher level of leadership from whole organization, not just the Customer or IT groups. One strategy is to have one person appointed as the single Customer who can make the vast majority of decisions about the system on the spot. Another is to have a comptroller or similar person from the financial part of the organization to assist in determining the true cost and benefit of requested features.

A strategy that simply does not work is to have a Customer Committee (read Change Control Board) to determine the requirements and set priorities. In almost all cases, such committees are too slow to respond, and impede the team's progress. What can work, however, is to have a steering committee comprised of executive-level members (CxO, VP's etc.) to provide oversight for the project and a consistent means of escalation of issues from the Customer level. There still needs to be a Customer who will be the single voice for the project in order to provide consistency for the developers, but that Customer can rely on being able to obtain quick resolution of issues by having the ear of senior management.

Customer "Balkanization"

Different people have different priorities, they work differently and see the world differently. Some people may want reports to show the data with all its warts, while others may want to massage it so that it appears more consistent. Some people want a very spartan interface so that they aren't distracted by reams of data, while others want as much as can possibly be crammed onto a page in order to avoid scrolling. Also, although we're all supposed to be adults, personality conflicts can enter into the equation. I personally have witnessed situations where if person A said the sky was blue, person B would disagree as a matter of principle.

Resolving issues such as these is critical to the success of any project, but again it's even more important on agile projects.

Even when there a single Customer has been appointed, sometimes other people work behind the scenes (e.g. talking to developers directly) in order to have the features that they see as important moved up in priority. The best solution that I can see is to ensure that the leadership of the Customer's organization is aware of the issues, and that the development team needs the Customer to speak with a single voice.

To provide resolution, the Customer needs to either be or report to a sufficiently high level of management to be able to impose a certain level of order. There are times when a decision simply has to be made, and the Customer must be in a position to make it themselves or to escalate to their management to have the decision made.

Summary

The Customer role is the single most important and difficult on any type of project. It is especially important for an agile project due to the hands-on approach required. They need to be located with the development team (or the team with them) in order to facilitate communication.

The Customer must have an overall vision for the project, and how it fits into the business that it will be supporting. They must have the authority to make decisions required to allow the team to keep moving forward.

By having a dedicated person located with the development team and able to make decisions quickly, the chances for success increase tremendously.

The Disengaged Customer - A Funny Thing Happened

In The Disengaged Customer - Introduction, I spoke of a nice, rosy Agile Development microcosm in which dog and cats... er, Developers and the Customer were living together in harmony. The Customer was fully engaged with the project, and all were reaping the benefits of that involvement. Then a funny thing happened...

Well, it was funny in the peculiar sense. This client has a very large, dysfunctional project in the works. It has sucked up about a quarter of a billion dollars so far, with at least 2 years remaining. They are trying desperately to do a good job of using Waterfall to build this system. It isn't working. At any rate, our new Customer was directed by the Gold Owner to start working with the dysfunctional project team, while also working with us. After all, our project was humming right along, and didn't require as much attention as the problem child project.

Suddenly, the Customer wasn't available for meetings. Decisions that once took a couple of hours or a couple of days to be made were taking a couple of weeks. Where once the Customer attended our meetings, the Business Analyst on our team now had to go meet with the Customer when time permitted. All of these issues resulted in a critical loss of feedback.

We continued developing, assuming that the path we were on was the correct one. Of course, we had no way of knowing otherwise, since our Customer wasn't available to provide the feedback. We were able to get some feedback from a previous, interim Customer, but that person had a tendency to flip-flop on decisions (which is likely why she was a previous, interim Customer).

So, as a development team, we started to drift.

We weren't sure what our priorities were. We weren't exactly sure what to work on next. We pulled stories from the overall list, but there was precious little from the Customer in terms of what we should be working on. This went on for a few months.

Then, we found out that the Gold Owner was pissed - really pissed. We hadn't been working on what this person thought we should. Not being at the meeting in which my boss required Kevlar underwear, I'm not sure how much of a defence he put up with regards to the lack of involvement from the Customer. However, I'm pretty sure that it was a "read-only" conversation.

So, we were getting our knuckles rapped for not doing our jobs. However, from my perspective it was the Customer who wasn't there to steer the project. Similarly, the Gold Owner directed the Customer to focus on another project. The result was that our team didn't have the focus required nor was our work visible to the absent Customer. In the end, I don't believe that the Customer's organization fully understood the importance of the Customer's role.

Continued in The Disengaged Customer - Balkanization.

23 January 2006

Personal Responsibility in IT

A mention on the Ottawa XP mailing list of the division of workload between a commercial pilot and co-pilot reminded me of a post I've been meaning to make for a while about personal responsibility in our industry.

I'm currently in the process of getting my Private Pilot Licence. I flew my first solo back in August, and to do so I had to pass a written exam known as the PSTAR. It's similar in concept to the test you have to pass in order to get your Learner's Permit for driving, although you need 90% to pass. The good thing is, though, Transport Canada provides you with all 200 of the possible exam questions, 50 of which are used on the test.

When I was studying, I noticed that fully 10% of the questions were along the lines of, "If a controller clears you for XYZ and you do not feel that it's safe, do you...", or "In a control zone, whose responsibility is it to...". In every case, it came down to the pilot in command being responsible for the aircraft, even if a controller has given you an instruction or clearance.

In October, I went over to the airport on a nice Saturday morning to practice takeoffs and landings, known as circuits. I did my pre-flight checks of the plane, with the flying school's owner there helping me move the plane out to be ready to taxi. Everything looked fine, and I taxied out and did 7 circuits. The rather odd thing was that I made 7 of my best landings ever, and was quite pleased with myself! After my last landing, I taxied off the runway and back to the ramp at the school.

As I pulled off the taxiway and onto the ramp, I heard and felt a thump below me and felt the plane dip a bit to the left. I thought I had hit a rut in the pavement, but realized very quickly that I had blown a tire! I killed the engine immediately and got out to have a look. The owner was on his way over to see what happened, and we looked at the tire. There was an enormous bald spot where the tire had blown, that had been worn right down past the rubber to the fabric lining. I missed it on my preflight, and the owner didn't see it either. We figured that it had been facing down when I had a look at the tires. Regardless, it was solely my responsibility to have ensured that the tires were safe for use.

If that tire had blown on the takeoff run or on landing, it would have been quite serious, with the plane and its sole occupant (that would be me) probably departng the runway to the side rather than up! In any case, it would have been a completely avoidable accident if I had just taken a better look at the state of the tires while we were pushing the plane out. Since that time, I have questioned another bald tire (though not as bad), and returned from a practice flight when an engine RPM gauge was acting wonky (that's a technical term). It turned out that the gauge was just affected by the cold, but it also could have indicated an oil leak.

For me, the analogy is that we as programmers need to have the same level of personal responsibility. If we see something that isn't right, we question it publicly or fix it. If we see code that doesn't have tests, we should write them. If we see opportunities for refactoring we should do it. If we see issues with our team, we should make them known and try to have them fixed.

If I didn't question the wonky RPM gauge and there was indeed an oil leak, I or the next person to fly the aircraft could have had an engine failure. Depending on when it happened, it could have been catastrophic and led to the loss of life. While most IT projects don't have the same life-critical implications, we still need to engender a sense of personal responsibility in our work.

20 January 2006

The Disengaged Customer - Introduction

What happens to a successful agile project when the Customer is no longer engaged? This is part 1 of a series of entries of how important the Customer role, specifically, an engaged Customer, is to agile development.

In the next couple of weeks, I'm moving on from a client where I've been working for a little over 2 years now. When I joined this team in October 2003, it was was what I would consider to be a successful XP/Agile project, incrementally delivering value to its Customer. One release had been made to production, and I joined just as a second release was being made. I thought that it was a good sign that by 10:30 in the morning on my first day on the project I was writing production code while pairing with one of the other developers.

I did note that the system's Customer was only present twice a week for meetings with the team. We had a business analyst who met with the Customer more often, but she wasn't really in a position to make yea or nay decisions about the system. However, the Customer, when she was with us, was quite engaged and provided good feedback. She had bought into agile development after a couple of iterations, and seemed to enjoy working this way.

This continued for a few months until this particular Customer was moved to another project, and was replaced. The new Customer was quite laid back, but had a tendency to waffle somewhat on issues. It wasn't unusual to make a suggestion about a story and received, "Sure, that's fine with me." as the answer. A couple of days later, she would change her mind. A couple of weeks later, she'd change it again. This was a little aggravating, but we were able to accommodate it.

This started while we were developing a web component to our system. About a month into this, we were directed by the Gold Owner to work on a new priority project. No problem, we said! This project came with a new Customer, who was as engaged as the first. Her answers were either definitive, or she would go back and get a definitive answer very quickly. We also decided to crank up our agility somewhat, changing to one week iterations from two, and using point-based estimating rather than using actual time. We cranked out that new part of the system very quickly, with few problems, and the team really clicked. I was quite happy with our progress, and figured that we were approaching XMM Level 5!

Continued in The Disengaged Customer - A Funny Thing Happened.

14 January 2006

The Last Straw

I had always tried to be a "good" programmer - analysing, designing, coding and testing in separate, discrete steps. However, I always found myself subverting the process and getting something tangible in front of the Customer in order to obtain their feedback. I actually got in quite a bit if trouble for doing it once. However, one project turned out to be the Last Straw for my attempts to follow conventional wisdom of the time.

A thread a couple of months ago in the XP Yahoo Group reminded me of how and why I came to be a part of the Agile development movement.

A post by Brian Nehl referred to two articles about the development of the Canadian Firearms Registry:
From June 1998 to December 2000, I worked on that project. The article in Baseline magazine is, in my opinion, quite balanced and accurate. Dwayne King, who was one of my colleagues, describes quite well the environment in which we worked. Some things that weren't said:
  • The program was backed at the very highest level of the government and would be implemented come hell or high water.

  • The estimated total cost of the system was based on the development cost of the system that was in place at the RCMP at the time. However, that system only captured the licencing information for people using Restricted firearms, which is only a fraction of the total number that were to be contained in the new system.

  • The application was developed using PowerBuilder 5.0 and Oracle 7.3, which were somewhat long in the tooth in 1998. However, this decision was made in order to minimize the technical risk, and was something with which I didn't have a problem.
The methodology used for the project was straight waterfall, although we were using OO techniques for the design and development (I believe they may have moved to RUP shortly after I left in December 2000). The requirements for the system were drawn from the legislation and the associated set of regulations. The problem with this approach was that quite often we needed legal opinions from the Dept. of Justice over what was meant by certain parts of the legislation. Equally as often, the same question could elicit multiple different answers from different people, or would result in hours of discussion over a single, minute point.

Since there were so many major stakeholders for the system (14, I believe), there was a group that handled all of the requirements definition and management. They were essentially our Customer, but they acted as an insulating layer between the development team and the real Customers. Their 'product' was a big binder called the BPE - Business Process Engineering, and it contained page after page of decision matrices, some of which were even up to date. In retrospect, those matrices could have been great FIT tables, although they often weren't consistent.

From a contracting perspective, it had been a real dogfight among the big SI's to land the development contract. It was eventually won by EDS, with the testing contract being awarded to Systemhouse. The Baseline article suggests that EDS and Systemhouse worked together, but nothing could be further from the truth. There was a lot of bad blood between the companies over the bidding process, and there was a very adversarial relationship between the teams at the management level. It was downright petty at times, although the people in the trenches (i.e. developers like myself and the individual testers) got along fine.

When I joined the project, the development team consisted of approx. 25 PowerBuilder and Oracle PL/SQL developers. This eventually grew to about 35-40 people, although the total number escapes me. Of the developers, almost all were contractors - EDS subcontracted the development to the company through which I was contracting at the time - with a few employees. There was a lot of talent on the team, with decades of combined experience at the analyst/designer level as well as at the developer level. It was, essentially, an all-star team, and the contract paid well. As Dwayne King suggests, the project was well within the technical capabilities of the team. With the benefit of Agile Hindsight, the team could have been considerably smaller, and still produced better results using an agile approach.

When I joined the project they were ramping up for an initial release to production in December of 1998. They had just undergone what they called the 'Alpha' release, which was a proof of concept intended to verify that the system would be workable and to expose any technical risks. There were some substantial performance problems in the application, but these simply required some optimizations of the code which were eventually performed. I was also surprised to find out that the database schema had been determined before any other development had even started.

The development team itself was split up into groups that focused on particular areas of functionality, and were led by an architect/designer. Despite the fact that we were all located in the same place, there was a surprisingly low level of communication between these groups. This led to some significant issues:
  • Different approaches were taken to developing different parts of the same application in terms of class hierarchy, separation of logic between application layers, etc.;

  • Different coding standards were applied between the groups;

  • Different groups at times used the same database columns for different purposes;

  • Code integration was anything but continuous, occurring usually just before a release to the test group. This happened about every 6 months.
Needless to say, integration was a mess. The application would compile on individual workstations, but the whole thing rarely did. The last week before shipping the system to the test group was usually spent just getting the bloody thing to build, let alone perform our own testing.

Once those problems had been ironed out (or just hidden), the system was tossed over the wall to the testing group. They used the (frequently out of date) BPE document as the basis for their tests, and many inconsistencies quickly became evident. Sometimes the code was wrong, sometimes the requirements were wrong. In the end, it always becase a battle.

So, here's a project that had the following issues:
  • The powers that be believed that they could "nail down" the requirements based on legislation and regulations that were still in a state of flux;

  • A group insulated the development team from anything resembling the Customer;

  • The initial estimate of the project was based on "a similar project" that was only similar in that it had information about firearms and ran on a computer;

  • The estimate was not made by anyone from the team that would have to implement the application;

  • The development team was split into multiple groups, each one working almost in isolation;

  • Code integration was infrequent;

  • There was no automated testing of any sort, and no formal unit tests;

  • Acceptance testing was manual, and performed after the fact by a group completely separate from either development or the Customer;

  • Iterative development was not practiced;

  • Releases were typically once every 8 months to a year;
And this system caught the eye of the Auditor General? What a shock.

For a while, I just figured that this was what life was like on large projects with large teams. I did get a reprieve in early 2000 when I was tasked to build a small satellite application that had very focused requirements and an accessible Customer. Once that was finished, though, I had had enough. I actively sought out a new contract, and in December 2000 one came my way.

A funny thing happened during the interview for that contract. About halfway through, I realized that it was for a Java developer position! At that point, I had about 6 months of playing around with Java, but I certainly wasn't in any position to be marketed as a Java consultant. Fortunately for me, this was still during the tech boom here in Ottawa, and companies such as Nortel and Alcatel would hire anyone who had Java on their CV and could fog a mirror. That left a significant void in the contracting world for Java developers, and the manager who interviewed me explained that my O-O experience was what they were really after and I could learn Java while I was working! Uh... OK!

I started working with Jim Leask, a consultant from Sybase. Jim had a couple of years of Java under his belt then, which was pretty impressive considering that Java itself was barely out of diapers. Our mission was to create a framework that would be used by "an army of developers" to build a big, honking case management system for this government department (which is another story unto itself!). The goal was to simplify things such as data access, GUI building, etc. so that they didn't need expert developers to build this thing.

We started out by handling one of the most critical aspects of any system built for the Canadian federal government - bilingualism. We began doing some modeling in Rose, but after a day or so we decided to validate our designs in code. Since I was a Java newbie and Jim was an expert, we decided that I'd do the typing and he would look over my shoulder to guide me as I figured out Java. We threw some classes together and realized that something in our design wasn't quite right, so we switched to his machine and updated the design based on what the code told us. While there, we added a bit more to the design, then switched to the other machine and I again hammered away on the keyboard. This back and forth activity continued for a couple of hours, at which point Jim uttered the immortal words:

"This reminds me of that Extreme Programming thing I heard about."

Once the images of Mountain Dew-swilling snowboarders with laptops cleared away, I did a quick Internet search (I can't even remember what search engine, though I know it wasn't Google). I believe the first site we visited was either Ron Jeffries' XProgramming.com or the C2 Wiki. The next day we hit the bookstore - Jim bought XP Explained, and I bought XP Installed. The rest is history.

So, I find it interesting that my disgust over the classic waterfall practices and the inherent dysfunctionality of a team using them led me to the Agile Promised Land. I will never go back.