Fear

I've had to confront my fears in adapting XP. My final conclusion was that I was just going to be uncomfortable, but I was willing to wear that for the sake of improvement. I've been set in my (bad habit) ways and change for the better was going to feel uneasy, emotionally. But intellectually, I can see the benefits of giving up the old ways.

Once I had surrendered to being uncomfortable, everything got comfortable. Weird how the pysche works. The flip side of this, is that I now get to watch people at work hit their fears and discomfort areas.

Just before the X-mas break, we were discussing amongst the developers how things were going to work. I had just started reading Test Driven Development and getting an even better feeling for how Simple Design really works. We've got User Stories for our project, but everyone knows that the content of the stories does not make a complete application on the other end. There is some uncertainty of business value for different document management systems that will be used by the application. And this is were the discussion turned to in light of Simple Design.

We need persistent data in regards to sets of documents. We do not currently have stories for the document management systems. Therefore, the simple solution would be to just store documents in a directory. The persistent data? Just write it out to a flat file in the same directory. I think everyone was on the same page up to this point.

One of the developers then suggested that when we move to a document management system that supports custom properties, we move the contents of the flat file to the custom properties. I challenged this, because it already works in a flat file. If something already works and it satisfies the customer's functionality, there is no need to change it (unless you are refactoring and I can't see a flat file being sucked into a database as a valid refactoring, at least for this project).

So, here comes the fear. Our company is full of technically savvy people and this project is an internal project. Developer: "What do we say when we are questioned as to why we aren't using the capabilities of the document management system?" Can you smell the fear? Probably not, as I'm a programmer and not a writer, but let me tell you it was obvious that we had struck a big wide vein of fear at that point.

My response was to say, "Tell them to talk to me. XP is about simplicity. If we don't have a business value for moving the persistent state, there is no need to do it. It's more time and more time means less money." (very paraphrased) Basically, I tried to say that's my responsibility and I'll wear that decision.

Fear is all around some times. You just need to sniff it out. So while courage is something to aim for, fear is some times hiding and not so obvious. As is Simple Design. To reach the goals, I'm keeping my eye out for the opposite bits creeping in.

Cruise Control Gotchas

Well, I just got Cruise Control working properly with two gotchas that held up the process.

1. CVS Update

Cruise control uses "cvs log" with lots of options to determine if a repository has changed. I didn't have the full repository checked out for some reason in the build space. I was changing that file, but it wasn't firing off a rebuild. Once I figured out what the problem was (by executing what cruise control does to determine if something had changed) it was a simple fix of checking out the entire project for the build. Apparently the log command only works for files that are present in the local copy of the repository. Presto, changes are now seen.

2. <junit> task

The <junit> task was failing for the cruise control build, i.e. ant didn't know how to run the task, but it worked fine when I ran ant independently. I eventually chased it done in the configuration documentation. <junit> is dependent on the junit.jar library which I've set up correctly for Ant. But cruise control will use its own version of Ant (which isn't set up to use junit properly), unless you sent the antscript attribute for the cruise control task of <ant>. First I tried adding the antscript attribute for the <ant> task in the Ant build script. Dun-dun! Wrong answer. Once I realized this was a cruise control configuration issue, I added it to the <ant> task in config.xml and all was good.

Now, we have continuous integration. And I like it...

Work Happiness

How weird, I'm actually happy at work. I'm noticeably happier as a few people have commented on my mood. There is only one explanation that I can find, it's this XP thing.

Now, I'm not generally an unhappy person, though work can drag me down. But now I don't think it is so much work that is dragging me down as the idiocy of how things are done. XP seems to be a ray of hope in a world of gloom.

We have user stories. I have an Ant build script that does building and testing. I've set up cruise control (though at the moment it is not recognizing when there has been a change to CVS) and I've started reading and driving along with Kent's TDD book, Test Driven Development by Example. I must say, I'm very impressed with Kent's personal and informative delivery style. He's invited me, not only into his world, but into his brain. Entertaining, educational and I'm happy. Life seems good.

Planning...

I gave my copy of Planning Extremem Programming to my manager to read. To my amazement, he returned it to me the next day declaring that he had read it and that he was disappointed. His main gripe was that it was condesending and that it didn't talk about budgets.

First of all, I don't think you can read a book like this in less than 24 hours and get what it is about if you mindset isn't aligned with the subject. I'm committed to the idea of XP, but even then I find that some points miss me. On reflection, I find that this is so because of some old assumptions I have that have been addressed within the book, but that I glazed over them because of my (incorrect in the light of XP) assumptions.

Budgets?!? Isn't that about time? XP can make estimates, whether rough from the onset or more accurate as iterations are started and completed. These estimates can then be put into the "budget equation" and a price estimate falls out the other end. How difficult is that? The main point isn't about budgets really. The real underlying point is about trust. Customers want a fixed price to protect themselves from the developers stupidity. I.e., the customer doesn't trust that the developers have the customer's best interest at heart. It's about social change and not budget and money and bottomline. The change will affect those things, either positively or negatively, but by applying change at the higher level of culture and society within the industry, we get more leverage and control over the whole situation.

And after all this described to the manager and him agreeing with me (at least I think so), he still didn't like the book. C'est la vie...

Comments...

Seems I had a restrictive setting on my comments. I've turned that off, so if you wanted to comment in the past or feel the need to do so in the future, I hereby invite you to do so (or not)...

First steps

We now have User Stories, yeah!

Very interesting and a different way of getting things done.

I think I must have unconsciously taken on the role of coach for this organisation, which makes sense, but surprised me a bit when it dawned on me. I've never done anything like this before, but I've got the motivation and a grasp of what we should be doing, so my job is to keep things on track, i.e. be the coach.

Anyway, we had a planning session yesterday afternoon. 2 developers and 1 customer. A bit of a substitute customer (for an internal project), but a customer all the same. We walked out with 30 story cards. In my naivety and wanting to tackle things in small bites, we (the developers) didn't do any estimations with the stories, though we did ask questions and tried to break up general stories into stories that we felt we could then estimate.

This morning we set about giving these stories estimates. I started quickly on my own just dividing the stories into 4 separate groups. Then we sat down and started estimating. My initial feeling about the first group, the easiest to do, were about spot on. I was off on everything else. 8)

In the end, sitting down and thinking about the stories with another developer, we started to pull out the simplicity of the stories. We found that some were about state, some were about security and access, some were about functionality and some were about user interface. And finding these categories help enormously in finding the heart of the task and estimating that task.

Basically we had 1's which we saw as the simple things. There were fat 1's and skinny 1's, but in the end they were all ones. Same with the 2's, with one more 2 than 1's. And a couple of 3's. My feeling is that each story is one ideal day, but I've shied about from saying day or any time description on these numbers around anyone that isn't a developer. I don't need expectations just yet from outside of the team.

Ah, but the real reason for wanting to post this: seeing a "mistake" and learning from it. As I said before, we didn't estimate during the discussion with the customer. In categorizing stories, we actually found a few holes in the stories. If we would have been doing this with the customer, then we would have prompted for the need of these stories. Being an internal project, we just wrote them ourselves (but verified them with the customer later, to which the response was "D'oh, how'd we miss that! 8)").

I immediately pointed this out to the team (i.e. the other developer...) which sparked a bit of a discussion. His point being that with an onsite customer, not getting all the stories at the time we had the meeting wasn't a bad thing, because they would have come up later and we'd just go talk to the customer then and there.

My point was, yes, from a "make sure you get the full specifications" I'd agree, but there is another thing happening in the meeting, and that is allowing the customer to plan the iteration. Without the estimates they aren't going to be doing it anyway, but if we haven't flushed out all the stories, they are missing an opportunity to plan for the value in the stories, if needed. On retrospect, this point seems very moot, because they wouldn't be planning without the estimations anyway. BUT, it did illuminate how some of the priniciples do work together.

It's all very exciting, but it is moving very slow. It's all new practices and hence we still seem to have training wheels on, but I'm getting to grips with what to do and how it feels. NICE 8)

Straight from a horse's mouth

Just thought I'd flag this, an audio presentation from Kent Beck. Yeah!

Kinda illustrates a point about communication. I'd much rather talk to Kent about XP, than read about what he's read. This seems to be the next best thing...

3 outta 4 ain't bad

I love books. I'm a self-confessed bibliophile (like that's a bad thing...). The problem I have, is finding a justifiable reason to spend money on a book. This usually means that it must deliver to me some techinical value.

The last time I bought a lot of books was from 1996 to 1998 while I was learning Java. I bought 18 books on Java (Wow, I didn't realize just how many I had!). Most of them good, a few excellent and a couple that didn't last the distant for me from a value point of view.

Now, it's 6 to 8 years later and I've found a new excuse to buy more books. eXtreme Programming. I've bought about 5 XP related books in the last few months, three of which I picked up this weekend. Included in the mix was Planning Extreme Programming. As I flipped through it, I came to Chapter 7 - Four Vaiables. Damn, there's four, not three! 8)

Cost, how could I forget cost? Well, actually I didn't. I felt it was sort of implied in what I was presenting. Maybe I should go back a review if that is true. I was talking to business oriented people, so I think they would have got that, but then I probably should not assume that...

In reflection a few days down the road, I feel the presentation went very well.

UPDATE:
Talking to a few people in the office today, the presentation went far better than I perceived. I've been told it was entertaining, informative and that I knew my subject well. Marketing what's to have me give the presentation to potential clients. That's the best back-handed complaint I've ever had! 8)

Into the fire

So, I gave this XP presentation to the whole of the company yesterday. And I only found out that I had to do it 48 hours in advance. (There is a story here about miscommunication, but I couldn't be bothered...).

Firstly, the XP meme is well and truly established here as a good way to do things. The important step is to start doing it. Hopefully, well get an immersion workshop run on site here within the next month...

But back to what I thought I wanted to express. I mulled over what to present for some time and had some serious writers block while trying to pull my ideas together. In the end, the night before, I just jotted down a bunch of notes in some coherent order and threw them together for some slides. And in the process, I feel I've made some hasty dodgy points.

The talk was focused at the company to give them a feel for how our interactions with the customer would be different with XP. So I broke the talk into two parts: the first being a philosophical view of XP and the last being a practical view of XP. Practical was simple - User Stories and Iterations mainly. This gave a good platform for the discuss of scope and how to sell to new customers. But the first, I could probably done better or without.

The main point that bugs me from the talk was that I started talking about Scope, Time and Quality in regards to delivery value to the Customer. We have followed a waterfall-ish method in the past. Big fat documents that are written in advance of the actual work being done. To me, this says of the 3 constraints for delivery, we saw Scope as the most important. After that, we agreed with the Customer to a timeframe for the delivery of the Scope and therefore Time was the next important constraint. Quality is left as an exercise for the programmer. Nothing new there, you probably have seen this equation before.

Then I said that XP elevates Quality from the least important constraint to the most important constraint. I didn't comment much about Time and Scope, but my feeling is that we then had these to the Customer. Quality is now defined as exactly what the customer has asked for within an iteration in the simplest code and design.

I feel that I'm right here, but I don't think I really needed to present that to the audience. I'll have to sleep on that one a bit longer I think.