Xp Atlanta

[If you're looking for XP-Atlanta, the ExtremeProgrammingUserGroup?, try AgileAtlantaUserGroup.]

This is my journal of an XP project taking place in Atlanta, Georgia.

June 7, 1999

I have been selected to mentor/coach a team developing that has decided to use XP. The team has a desire to have fun doing this project as well as try out XP. They have reviewed the information on the Wiki and I have sent a short description of XP to the developers.

We are developing a C++-based framework to be used by other developers in the company. In this way, it can be viewed as an internal product. This framework is viewed as an trade secret, so I will not be able to discuss its functionality in any detail. I will cover the parts regarding the XP process.

Currently the team has two developers. We have three customers, one available full time in XP style, one available one-quarter time, and one on the other side of the world. We will be working hard to make the local customers happy, as it is difficult to make the non-local customers happy (it is the easiest thing that could possibly work). On top of everything else, the two developers will be defining the concrete users stories (the customers have expressed no desire to do this) and writing the functional tests. It reminds me of TheInmatesAreRunningTheAsylum.

Of course, the powers that be want a document describing the framework as the first deliverable. This is our first UserStory. We are treating the document as a way to communicate the rest of the user stories. These will be moved to index cards at the next iteration planning meeting.

Our iterations are one week long.

A lot of this sounds very non-XP; please understand that this company wanted to use the FusionMethodology and this team has decided to supply the artifacts necessary in Fusion but to do it XP style. We will be ignoring Fusion as much as we can. As the process moves along I expect a more XP-style environment. Also, I would expect quite a bit of this to be taken care of by the customer (UserStory's, etc.). This is not the case here, so our first iteration's goal is to create user stories.

Great! Good luck! Keep us posted, ask for help!

Hank, in particular feel free to lean on me. My last project was an EvoFusion job for HP, and I'm trying to work my present consult XP, with some caveats. The group practices CodeOwnership and our pairs tend to be more permanent than the freewheeling XP ones. And we have some developers who aren't willing to buy in to the whole thing. Plus we have some other weirdo forces to reckon with - see ExtremeUnifiedProcess for a summary. --PeterMerel

June 8, 1999

Day two and people already want to change the process. By people I mean those that are in no way involved with writing the actual code and have no stake in the quality of code produced. The people have heard of XP (via articles in C++ Report, for example) and just can't see how it will work, let alone work on a team our size. But, I'm sticking with my guns, refusing to let our rules (the same as the ExtremeRules) change until at least an entire week of actual development shows our rules don't work.

Way ta go! Your responsibility, your rules. It's like an estimate: the only way someone else should get to change the project rules would be to take the responsibility. Not that you really want that ... but neither do they!

Also, someone made a commitment on behalf of the team. That someone made a promise that a deliverable (our only deliverable at this time, on our first iteration) would be delivered two days ahead of schedule. The entire team pushed back saying we made a commitment ("see the note card, see the outcome of our planning game") and said you will get it when it is due. If we are done earlier we will let you know. Way to go team!!!!

Way to go indeed!! Follow-up: June 9: The push back worked!

On the good side, I've gained one-half of a developer. We are up to 2 1/2 developers now.

June 9, 1999

Still trying to get one developer to let go of the notion that we need some big design up front. For example, this developer would like to work out how to enable the system to support by dynamically loadable and statically linked modules. Based on previous experience the developer already knows how to do dynamically loadable modules. But the developer feels it is necessary to the design of the system to figure out how to treat statically linked modules, otherwise he fears we will code ourselves into a corner. I have suggested just getting dynamic modules to work (when the story comes up) and later we can figure out static modules. Since we don't understand static modules, for now we will estimate them to take a long time. When it comes time to implement static modules, we can see if that estimate is wrong. This developer comes from a big design up front background and doesn't feel comfortable letting go. Any suggestions?

The overall project manager likes the PlanningGame and is leaving our spot on a detailed schedule open until we finish the game. Plus the manager likes that we will provide weekly feedback into the schedule. (I think I'm lucky in that he is an ex-Smalltalker that has heard of XP and is willing to let us try it.)

Great stuff, keep it up! (And, by the way, remind your friend that a statically linked module is like a dynamically linked module only not so dynamic.) --rj Thanks. That is what I tried to get at, but it didn't seem to sink in that it wasn't worth getting into until we had to do it. --hr

So is this style journal worth continuing? I know that XPerts know this stuff inside-out; but would this be worth a daily / every other day / weekly entry in a public forum? --hr

Please continue.

I concur, please do continue -- not everyone here is an XPert! --BrettNeumeier

About the static modules. If a team member sees this as being the greatest risk to the project you should listen. Perhaps you could give him a small amount of time and maybe a partner to do a SpikeSolution. Use what you learn to create a better estimate and get your team relaxed and able to focus on the problems at hand. --DonWells

Doesn't WorstThingsFirst cover this. If your developer is concerned about the risk of doind a task, that's surely a good reason to move it up to near the front of the schedule --JohnBurton?

Yes, Don and John are correct: if, after a bit of reasoned discussion, a team member still thinks something is high-risk, it needs to be considered for a SpikeSolution. I'd ask for team concurrence on whether to do the spike, would try to avoid someone going off on a tangent that the team doesn't agree with. And, of course, there's always one's free time, where one experiments with whatever's interesting. --RonJeffries

Thanks for the help. I'll be sure to address this in the next StandupMeeting. -- HankRoark

June 10, 1999

The suggestion of SpikeSolution worked. The developer did just that and the risk has gone away. Everyone, thanks.

June 28, 1999

Some frustration setting in. I need some help:

Do SpikeSolution's do UnitTest's?

Programming goes better with UnitTest's, so experienced XPers always write UnitTest's. But if your guys don't, just tell them that all production code has UnitTest's, so if they want to turn their SpikeSolution into production code, they have to write tests. It isn't the end of the world if they don't want to write UnitTest's when they are prototyping.

Is it okay to do CRC in Rational Rose (name your favorite case tool)?

Sure, if you are happy with it.

What do you do when the business won't make business decisions but, instead, expects the developers to?

You need to educate them, but I don't know how. Maybe you need to hire your own business person.

Hank- can you be more specific? Tell us a little story.

I'm sorry, the last question was probably too much of a rant. We have a lot of 'requirements' from out customers, other developers. Occasionally our customers are the end consumer (proxied via product planning/marketing/sales). Getting our proxies to make a business decision is difficult. It turning into one of those Dilbert cartoons where a marketing type asks Dilbert "What can you do with that computer? After you tell me, I'll write down the requirements for our next product." --HankRoark

General strategy- go on strike and tell a grownup what you're waiting for.

July 7, 1999

I have decided to part Melita and, as a result, this XpAtlanta project. --HankRoark