An XP Diary

Wyatt

wyatt@yellowcello.com

Week One

4.15 Today was my first day with a small web-centric solution services company with approx. half-dozen clients. I'm part of the financial dev team building apps for a new company targeting the secondary market. There's six of us, they all seem like good guys and very bright, and I worked with one of them several years ago. Today I reviewed the requirements and discovered some holes and also that the application must be live on June 1. Worst of all situations, the stakeholder is not available. This is going to be an interesting situation. The client is nowhere to be seen, and the requirements are not 100% clear. I'm told that nearly 200 hours were spent up front gathering the requirements. I went out and bought 4x6 cards. White for stories, pink for tasks and purple for test scenarios. I got a bunch of round stickers, red for stop, green for go. Today I pulled the team together and we broke out the requirements into stories. It's unfortunate the client's client could not write the stories, I have to figure out how to fix this situation, it's going to create unnecessary problems if we don't get them involved. We wrote several tasks for the stories that were completed, and estimated each of them. We should be able to translate the requirements into stories and come up with the tasks by tomorrow. 4.16 Off-site with the team. We finished writing the stories and tasks. We reviewed the rules. Everyday stand-up meeting at 10:00 and all email and phone calls must be done before 10:00. Task gets a green sticker when it's complete, green on the story when all the tasks are done, green on the test scenario when the scenarios pass, otherwise red on both the story and test scenario. Already we have about 4 spikes and the pairs break up into solos to R&D the spikes. I learned today that the tester is not the user of the application; it's going to be my client who's going to test the functionality. Maybe there's something that I don't understand, but something is foul with this arrangement. I need to ask more questions. It was a long and good day. 4.17 We had our stand-up and nothing to report except for how the process works. We needed someone to set the priorities for the stories. The client is not part of the team and the project manager is telling me that their relationship with the client is difficult and that's why they keep her at a distance. The project manager sets the priorities and we start designing and developing. We agreed to 3-week iterations. I drove today with my partner bringing me up to speed on the current frameworks. The PM is bright and a very decent person but I think he's not very experienced with management, or managing client relationships. I downloaded and installed the testing framework. The team hadn't written unit tests before. I insisted that we all write tests in parallel while we write our biz code. We gotta get on top of this. The team I'm working with is embracing the XP approach. They're a good group. I'm really lucky to be part of this bunch. 4.18 Off-site and we did our stand-up via IRC, I'm not too keen on this approach but it was short and we did manage to cover what we needed. I've been in senior management enough to keep me out of development, I need to come up to speed fairly quickly or I'll slow us down. I don't anticipate it will be too difficult, but I do feel rusty. Thank goodness I've a good partner and at least I know this dev environment. 4.19 Stand-up meeting and the CTO gives the team an odd look. I invite him over to observe. I explain the process and when I think back I must have spoken Chinese. There were no questions, only a scowl. I drove today. Today we worked on the model and a new display component. We're a little more than one-third through the first story.

Week Two

4.22 Stand-up. Today we made good progress and we should wrap up the first story by tomorrow, the other guys are still spiking. Man this is a tough schedule. The number of task days left do line up to hit June 1, however I don't think we're going to hit the target. I don't have the needed data to raise a flag, but my gut tells me we won't make it. I'm thinking of changing our iteration cycle to 2-week cycles. If I can calculate velocity data sooner I'll be in a better position to determine how close or far we'll be to June 1. 4.23 Off-site stand-up via IRC and we report that we hope to complete our first story. I'm still not up to speed but my partner is telling me that I'm getting faster. Damn I'm more rusty than I thought, sure wish I could let go of the handlebars. 4.24 Stand-up. We're a day off target and the other guys are still spiking, hell they're spiking this entire week. We finished our first story in the afternoon. My pair partner and I each take a task and we go solo. We'll pair when we need support. For the second time, I ask for a much larger corkboard, the PM says he was told that it should arrive any day. 4.25 Off-site stand-up via IRC. The first story still hasn't been tested. I ask the PM about the test scenarios and he says that he's tied up writing code for another project, he promises to test before Monday. I bite my IRC tongue, but I'm thinking we need to get the client involved...we're going to finish the iteration next week and I've never met the users. Feedback too late in the game can potentially derail us. I turn to my pair partner and say we have to fix this situation. Somehow we must find a way to get the right individuals involved. He's in full agreement. 4.26 Stand-up. The PM asks us how we're doing. I point to the board, trying to train everyone to look to the board for progress information. I review the green and red sticky thing again. He's not asking the right questions, all he wants to know is if we are on schedule, to which I reply "barely." I inform the PM that based on the completed story and how we're going on the current stories, I would estimate we are approx. 20% off. We might be able to make up the difference somewhere but I'm not sure where. Which leads me to ask the team if we can change the iteration schedule to 2-week cycles. I explain that we need supporting data to help us determine how close or far we are to hitting June 1. Everyone is in agreement so we'll end the first iteration next Wednesday. We have 4 days to complete 2 stories. The PM reminds us that the date is fixed and that all the features must be completed by June 1. I say I hear what he's saying, but the worst of all situations is to NOT communicate to the client if we are going to miss meeting their expectations. Several words are shared but nothing convinces me that we cannot go to the client and reset their expectations. I do not budge, I tell the PM that I insist on telling the truth. Eventually the client will learn the truth, better sooner rather than later. This situation can't get any more ridiculous. I ask for help with my task. A teammate says he can give me 30 minutes, I say that's fine but I need a bit longer, maybe 1-2 hours. He agrees. Stand-up adjourned. I'm starting to feel myself getting faster. I was asked to give a presentation to a major financial firm on Agile/XP, now crunch on something else, this should be fun. It was a good week.

Week Three

4.29 Stand-up. We're having problems with our unit tests after we made changes to the model. The tests for the many2many relationships don't work correctly. We made too many changes at once. We had tons of refactoring to do. One of the other pairs is having troubles writing valid tests. We spent what felt like too much time in the land of unit testing. We got through most of the problems. Spikes are over and the other pairs will start developing on the main branch. Celebration. Their stories will overlap an iteration, hopefully they will have something to show by the end of the next iteration. The CEO, a very pleasant person, invites me into his office. I'm thinking this is interesting. He thanks me for taking charge of the teams and wants to understand the meaning of the 4x6 cards and the corkboards that I've brought into the company. So I explain the daily stand-ups, the progress board, the purpose behind the white, pink and purple cards and the significance of the red and green stickers and I explain the pairing, to which he says "cool!" I explain it as a lightweight approach to software development and that it's called Extreme Programming. He stays with me and seems to understand. After I'm done with the explanation he asks if we're on schedule. I say "barely," and that I'm nervous about June 1, but I'll have better information after we complete our first iteration, and more accurate info after iteration #2. He informs me that we can't mess this up, and how important it is to deliver all the functionality by June 1. He says again how important it is, and he's dead serious. He then pulls out the contracts and goes through the schedule and the features, and explains to me the penalty amount he takes for each week his company is late with delivery. He's not showing me anything that he hasn't already told me, he's insisting that we get it done or he's going to lose his shirt. He asks me what I think. I say, it's a mess. (now I've done it) (here I go) It was silly to commit to a set of features and a delivery date before checking with the engineers. And now you have it in a contract? Why in the world would you set yourself up for failure? He said that he spent nearly 200 hours upfront gathering the requirements and he even went over it with his CTO and lead engineer. I said, that's fine. But they are not the one's who are doing the work. He asks me, so are you telling me that we cannot get all the features in by June 1? No that's not what I'm saying because I don't know that for sure. What I do know is that during development "shit happens," and if the client is expecting a definite set of features by a given date, and because the client isn't involved with setting priorities, then it makes it extremely difficult to reset the client's expectations. Because the client isn't in touch with the project, they do not understand the difficulties involved with writing software. As far as the client knows, they probably have an image of everyone sitting on their thumbs. Do you think they even for a second think you and I are having this sort of dialog? Already we are delayed because the stories completed haven't been tested. If they aren't tested soon then that will delay us, more than likely there's going to be something that we developed that the client doesn't like. Without their input, we are going to get it wrong. But we have everything in writing, says the CEO. Yes I said, but then at the end of the project you and the client are going to argue over the interpretation of the features, and you're not going to win. You want a collaborative relationship, not an adversarial one. The approach you've taken to this project is that the client's input is not welcomed. If we don't change this, then you might as well go to Home Depot and buy the biggest shovel they sell and start digging. The CEO says to me, what you are saying makes a lot of sense. We've failed on the first two projects and this is our third try, and we have to deliver on time with the entire feature set or we won't have any more work from this client. (I think to myself, we're lucky they gave us a third chance.) Okay, now that I have your attention, I'm going to draw some lines, circles and boxes about timelines and the value of responding to change and how the market changes. Wow, immediately he says that he gets it. I guess I shouldn't be so surprised, but I am. The CEO says, so you're saying all the effort I put into gathering the requirements upfront really bought me more trouble than it's worth? I say, kind of. Not entirely but you didn't have to spend 200 hours. We could have been developing during most of the 200 hours, and you could have been generating revenue sooner for your services and the client would be able to get their business on the wire sooner. You both would be winners. He admits that he built the Chinese Wall between he and the client, mainly because the client was always changing priorities on them and essentially they could never get on top of the scope. He says he wants to do it right, and asks what he has to do. I tell him the first thing is that we need bring the client into the project, not isolate them like an alien. Second we have to be honest with the client and we have to teach the client how to drive. The client needs to feel the effort it takes to develop an application, they need to feel the power of being able to change lanes. They know their business better than we do, and especially because they are a new business, they are going to change their minds many times, and we need to respond quickly. I've seen this enough times. He says to me, you still haven't said if we're going to be able to get all the features in by June 1. I say, we will do our very best, we will work overtime and do everything within our ability. First you must let us develop a relationship with the client. Things will likely be different once the client is part of the team and has input. I can't tell you we will hit June 1, because I'm not sure if we can. But we will do our very best. He says, I really want to fix this, and what you said makes a lot of sense. Sounds like I need to get myself and the CTO and the others out of the loop, and let you and the team work things out with the client. I said, we want you to win. If you win, the team wins. I believe very strongly that the team and I can fix this. If we can't, then you'll know right away. 4.30 Off-site stand-up via IRC. We completed our first story. I'm still not up to speed but getting faster, sure wish I could let go of the handlebars. I write to the PM on IRC that the stories still haven't been tested, I ask when does he see that happening. He replies that he will test them later today and he'll have the CTO get the client to test as well. Tonight I did a presentation on XP to the WebObjects User Group. 5.1 Stand-up. We finished our first iteration. I look at the back of the cards (we write the date and time we pick the story, as well as the date and time we complete the story. Going forward I want to do it at the task level as well.) We inform the project manager that we're off approx. 20% and that in theory we should choose 20% less days because that's our current speed. The PM proceeds to inform us about the deadline and how all the functionality has to be completed by June 1. One of the team members presents the image of 9 women in a room having a baby in 1 month. We don't take the conversation any further. Everyone is kind of quiet. We go to work. The client still hasn't tested the completed stories. I ask the CTO if he could get the client to be more involved. He says that he'll try to convince her. 5.2 Off-site stand-up via IRC, working the stories. 5.3 Stand-up. No real issues, we're working the stories and making progress. So far we're on target. The CTO informs us that he twisted the stakeholder's arm as much as he could. He says that she can't come down to the office to test. I'm thinking..........hmm.

Week Four

5.6 Stand-up. We're working the stories and making progress. One of the engineers is having trouble with a story. It's scheduled for 14 days and it's a daunting story (broken into 2 stories), very complicated. I can't offer assistance because my tasks are too tight, but another will pair with him. Practically all of us suggest that we not try to code everything. We can do more later but we only need to give the client enough functionality to let her test drive it. Let's get feedback first before we assume too much. I talk with the CEO, because he's very approachable. I say that it's extremely important that we get the client in to test the completed stories. I say that if we do not test and interact face2face, we will definitely not hit June 1. He says he'll call and get her in to test. Starting last week I felt my progress increase significantly. I'm much more confident and able to move around the environment with ease. Look Ma' no hands. 5.7 Off-site stand-up via IRC. We're cranking away at the stories. We stop early so we can work on the XP presentation for tomorrow morning. It's for a significant financial institution and I'm told they know very little about agile and XP. I'm also told they have a CMM specialists who turns his nose at agile. Wait till they read the quotes I have from Mr. Paulk. 5.8 Out of the office. XP presentation in the morning till afternoon. It went very well, good crowd and excellent dialog. The CMM guy had a lot to say, but had no remarks to Mark Paulk's quotes. There were many questions about fixed bid projects with XP, the steps during an iteration and how to get client buy-in. It felt like a good morning. I'm all charged up. 5.9 Stand-up. There's a meeting being called by the CEO, with the CTO, PM, two senior engineers (my partner and myself). CEO wants to set the expectations for tomorrow's meeting. The client is coming in and he wants us to say we are on target for June 1 with all the features. We all express that we understand what he is asking. He says that he's got himself in a tough spot. If he doesn't hit the target date, he won't have any future business with this client. My partner afterwards says he's not going to get wrapped up with the CEO's mess. I can't argue with him, he's mostly right. But I feel a need to help out, perhaps it's my weakness that I can't let it roll of my back and let it be someone else's problem. I look at it as, work for my client means work for us, the current climate sucks and none of us can afford to sit idle. If we can turn this project around in a positive direction, then our client will have a higher opinion of us. Perhaps I'm expecting too much. I heard one main theme from the CEO, if the project fails, we all fail and there will be no more work. The question that keeps coming back to me, how do we change the perspective of failing? Late tonight I get an email from the CEO, he thanks my partner and I for teaching him a better way. (In my mind I'm thinking at least the CEO is open to a different way.) I respond with a thank you, and that it's not better unless it yields better results. What we're trying to do takes time to cultivate, it requires constant tending. 5.10 9:00 am, the client visits us today for the first time. She seems like someone I can talk to. She sees our white, pink and purple cards and asks the question. The CEO and CTO start explaining, but it's not second nature to them so they stumble a bit. A team member jumps in, he explains the setup and we take her to the board to explain the steps. She makes an agreeing motion with her body. We sat down and reviewed the completed stories. We totally got one of the stories completely wrong. It couldn't be more wrong and she points it out right away. No surprise here since this is the first time the client is visiting us and giving input. The CEO sits with us and sees that she's not too pleased. (I don't blame her upsetted-ness one bit.) She remarks that the CEO said last week engineering effort was 40% complete on this particular story (the one we got wrong). She told her boss, "how can they be 40% complete when I gave them 0% information." (hmmm, someone got caught with their pants down.) I say, obviously there's a misunderstanding, perhaps we communicated it poorly to the project manager. (I feel we [the engineers] have to take the heat off the PM, CTO or CEO) Engineers are known to have poor communication skills, so it must be the engineers, right? I ask her, what is it you want this story to do? I remind her it's the same as a feature. She begins to explain what she wants and I pass her a white card. I say please put your voice here on the paper write exactly what you want. She writes. The engineers read the story and we discuss it for a couple of minutes. We have a good understanding and mark it as 3 days. But that's 3 days in addition to the story that we got wrong. The CEO (damn I can read him like a book) asks if the 3 days are going to hurt us. I said that it's not in our favor. I comment on the written story and that it's best to explain only the wants, and to let the engineers decide on the how-to. I'm trying to develop contact with her, she's responding and even taps me on the arm a couple of times. Body language (kind of like dating), we make good eye contact. She's either flirting or extremely demonstrative, she's constantly touching my arm. I repeat what I hear so I don't misunderstand what she's trying to express. I ask how important is the feature she just described. Very important, almost critical she says. I ask her to please write it as a story. After a little more than an hour we're definitely in a groove. The CEO says the new stories are not part of this iteration. He continues to say that they have to wait until after June 1, and we have to stick to the current stories that are in the contract. The client acknowledges by nodding. I agree and I say to my client's client, _BUT_IF_YOU_DID_ have the option to add more stories, you would simply write as you've been doing, and then you would prioritize them with the other stories. Eventually what we want you to do is drive. If your business goes in a different direction then we will change lanes with you. You're a new business so it's almost a guarantee that your ideas and business direction are going to change frequently. She seems to get it. She looks at the board and comments that there are still many stories yet to do. We all agree. We adjourn the meeting and the client departs. It was a non-confrontational meeting from which we will build. The team was pleased that we received negative feedback sooner. We should've had interaction with the client weeks ago. We all learned something today. We work and already we have questions for the client. They will have to wait until Monday. It was a good week.

Week Five

5.13 Stand-up. We finished a couple of stories today and will be ending our second iteration on Wednesday. I have several questions for the client. Since the test scenarios failed last Friday I want the client to review the system as soon as possible. Besides I need to keep the pressure up with the face2face interaction. I'm going to push forward with getting her involved. I talk it over with my team and suggest that we take a trip to the client's office. They agree and I send an email message to the CEO, CTO and the PM. I inform them that I will be traveling with three members from my team and we'll be off-site all day. I'm sure the CEO will be supportive but he'll likely hear something from the CTO and/or the PM. Just in case I poke my head into the CEO's office to make sure I have his approval. I do. I give the client a call and let her know that we'll be coming up. She gives me directions. We finish as much as we can for the day, deploy to staging and wrap up. It's nearly midnight and I get the following email from the CEO:

"I know you already know this but humor me one more time! No matter what...we need to complete, deliver and deploy all the features agreed to by 6/1. I have no room for error. I have huge penalty clauses in the contract for missing the date."

(without a doubt the CEO has fear, and I am careful with my reply, but at the same time I must make my point.) To which I reply with the following:

"[name snipped] (CEO),

As I write this my team and I are still awake working to help secure the success of the project.

I will continue to do so, and I believe I can speak for the others as well that we will do everything within our power to meet the predetermined date. However, I cannot tell you enough how difficult it is to find _success_ in a situation that defines up-front a variable (the schedule) without having the client involved fully understanding the scope with long feedback loops. The client needs to drive the priorities and understand what they are asking for. The fact that we are almost over with the second iteration and solving problems that were part of iteration one, demonstrates how much the project has dragged. For this very reason is why we are driving up to the client tomorrow morning. We need to shorten the feedback loop and get the client involved, and we need to teach the client how to drive.

As long as people agree to up-front schedules without the engineering staff being part of the initial discussions to fully understand the scope, and also having late client feedback and lacking participation, then you will find those situations will most likely result in wedges being driven between the client and solution provider. This has been the routine for many years, I've seen it too many times and it does nothing but create fear and angst. It's a "Days of our Lives" episode with everyone pointing the finger at the other.

However, I must acknowledge and credit your willingness in letting us take charge of the situation. I've managed clients and projects for many years, and our use of best practices will only improve your client relationships.

We totally understand that there is no room for error and we promise that we will do our best to meet the expectations. After we complete this iteration I will be able to give you accurate data that will tell us how close or how far we are with hitting the 6/1 date and with what features.

I will not give you false expectations; it is the only way I know how to do business with professionals such as yourself.

And I will look for opportunities where we can cross/up sell your services to help fill your client's voids.

We will keep you up to date with all activity essentials and otherwise.

Good night (morning), and thank you again....

Regards,

Wyatt "

5.14 Early morning drive during Chicago rush hour. Not something anyone looks forward to participating in. *yuck* Off-site to meet the client on her own turf. Three of us from the team drive up. I have two objectives:

1) establish a closer relationship with the user and her boss (President of the mid-west office)

2) get feedback concerning completed stories.

We arrive and setup. Nice, we can't get a connection to the outside world; we have to run off our G4's without internet access. Only option is to dial out and that's too slow for data transmission. This is not going to work; I feel that I should have thought these issues through before hand, or at least the PM/CTO should had said something. *sigh* I'm thinking we might use our FrontBase copy, but I don't believe the FrontBase tables are in sync with the Oracle tables. Nope, they're not. We have to use the staging server. We deployed a version last night, but I didn't test the staging version. She begins to test the completed stories and the system crashes, DAMN! This time I watched and she tried to use the system in a way that we didn't expect. She wants more of an audit trail and we didn't account for that. Now no matter what she does the system doesn't work, CARP! (hey, shit happens, but at least we know what she wants.) Well, we'll have to fix that obviously, I say with a smile. We show her the other features that are partially done and she gives us feedback. We then spend the majority of our time talking about the project, and I express how _critical_ it is for her to be involved, and that she needs to drive. We talk about the process and I describe how we're able to move quickly with her business changes. I give examples that might cause their business to take a different turn, such as additional VC funding, competition, management change, merger, etc. She listens to every word and without any hesitation she agrees. In fact she is willing to visit our office at least twice a week to help move the project along. (Hmm, this contradicts something I heard weeks ago from the CTO.) She continues to say that she and her boss were never asked to participate in the development of their product and just gave the instructions to my client. She continues to say that the relationship has not been ideal, and that my client has missed the mark on two previous occasions. (I don't agree nor do I argue. I'm there to build a relationship.) I say to her that's why we've come up today. We need her to steer this project. She knows her business better than we do and she knows immediately when there are situations that need redirection. We want her to be part of the team. She agrees whole-heartedly. Yes! I'm thinking this is good. Now if I actually get her to participate then this is going to be a great relationship. Today is Tuesday. I say to the client we are finishing our second iteration tomorrow and we would like her to come to our office to test and be part of the next planning session. She says that tomorrow is not good but for sure on Friday. I agree, thinking we could actually use an extra day to tighten some of the recent code changes so we don't have a crash repeat like today. Even though nearly everything we showed crashed, it was still a very productive gathering. On the way out I knock on the door of Mr. President. We chat a bit and he comments that the previous week we got a feature totally wrong and missed it by 100%. Yes, that's correct. That's why we're here; we need input from you more often. The sooner we get feedback the sooner we can correct the problem. There are consequences by not having your participation, and it wasn't fully realized until last week when we totally missed hitting your expectation with a particular feature. He said he's all in favor of a quicker feedback loop and more interaction. Great I said, we'll be up here more often and anticipate that you'll be down more as well. It was a good first "real" connection with the client. We invited her to be part of the team and now it's a matter of working the relationship. I'm not too concerned with the system not working correctly. That's something we can easily fix. The relationship requires more effort, and we are now for the first time going down the right path. I am very pleased with today's progress. 5.15 Stand-up. Officially we're done with our second iteration today. My partner is hoping to get his framework done before the deployment. I'm thinking get out of the clouds, no way in hell it's going to be finished. He keeps talking about another 2-3 days, he's not panicking just buying more time. We all say "do the simplest thing, don't make it complicated." One of the other guys is going to pair with my partner. We are all in the round so there are no secrets. We hear someone saying, "dude, keep it simple." Then nearly the entire team breaks out with "DUDE, KEEP IT SIMPLE." We finish and go home. It's about 9:30pm and I get the following from the CEO:

"Its late and here are my thoughts for tomorrow for your strategy meeting. I am out in a morning and won't be in until noon. By then I hope you all resolve what needs to be done. Don't send me email replies just think about what I'm saying and figure out how to complete the task. Bottom line I agree with everyone's feedback about how this project shoulda, coulda, woulda.

Fact- I sold a bad project with bad expectations with unrealistic deliverables based on our track record with the client. Set up to fail - therefore I'm not going to criticize anyone in the group if we fail. I take total responsibility.

I completely understand the XP methodology and agree as to its value. I even agree that we use some of the methodology in this project except that we need to keep the focus on the following:

Now.....

The client told us what user stories they wanted. I went through 2 months and 200 hours of redefining and prioritizing. I wrote them up and made copies and screen shots of the stories. They approved what they thought the user story was the day they signed that contract.

The document is the excel spreadsheet dated 3/27. It's the one that they signed as part of our contract.

It is our job to create that story. I know it's not what they may want now, but we can document what they want now and address in the next version of the software development.

To the best of all of your abilities you need to complete each of the stories, have them reviewed, test and deploy by 6/1.

I need a recap of the status of each story as of tomorrow morning with what it will take to complete including review and deployment.

I will assist in clearly explaining to the client what they agreed to buy and what they are asking for now if it's different than what we agreed they bought.

I also know that that will be a war of interpretation that I must fight.

I want you to get the client's feedback and document it all.

I also want you to tell her that the story you are working from is not what she is saying.

I need a day-by-day account from now till we are done on almost each instance that is not in sync with this plan.

In addition to the status tomorrow I need to know what it will take from the entire team in terms of working hours over the last 14 days. Nights, weekends, hotels in the area, whatever that means.

End of the day I have tons of respect for all of you.........

We will never cross this way again.

[name snipped] CEO"

[Clearly the CEO, CTO and PM who were part of the initial project discussions are scared to death. Unfortunately the CEO doesn't really understand the process, but that's not the issue here so I don't even address it, not even at a future date because it's not necessary.] I respond with the following:

"Collectively, we all need to sit down and have an honest conversation. The development team will meet first thing in the morning and afterwards we will have the necessary data so we can better calculate our velocity, and this will show us the direction of the project and what we can do to alter its course.

I suggest that we make this the highest priority for tomorrow.

Regards,

Wyatt"

5.16 A carry over from the previous night, I get the following email from the CEO,

"Wyatt thanks. Keep in mind that the list we agreed to was already prioritized. I need to understand why the team didn't develop them in that order. We will come up with a solution...then change."

Stand-up. My pair partner and I agree that we'll stay in a hotel with a connecting door so that we can work late at night to meet the schedule. We'll start next Monday, that'll give each of us approx. 2-4 hours extra each day so we don't have to fight the traffic during rush hour. Even without rush hour it's approx. 45-60 minutes one-way drive home for myself and twice that for my partner. The PM comes by and asks if now is a good time for the strategy meeting. I say sure. We all get up and proceed towards the CTO's office. We sit down and the CTO starts talking about the project and that we must to hit the target with all the features. I ask him how he plans on doing just that. He pulls out a dry erase pen and draws a triangle. At each point he writes "Quality," "Budget," and "Date". At this moment I have a short fuse, and I ask what does this represent? He explains that these represent the variables of a software project. Hmmm, I ask what are you developing without a set of Features as in Scope? Oh that's assumed, says the CTO. I say I don't believe so; in fact most people discuss Scope, Schedule and Staff and overlook Quality as a variable. For this conversation I say let's consider all four variables because in my team's world we do. Okay, says the CTO. So he says that everyone already knows the Date and the Scope and we're not adding more Staff, so that leaves us with Quality. He says that the client decided they don't want Quality. I say, you honestly believe me to sit here and accept that "the client said they don't want quality software?" He says "yes." He continues, that the client knew the date was too tight and there was limited budget. I ask why did you accept this project? To which he replies, "we needed the money." I say, so at which point did you say, "hey it's not going to have any quality?" ...silence.... I say, look if you want crappy code we can certainly do that. Obviously we would rather not, but if you're giving us permission then that's what we will do. I insist that we all meet with the CEO and give him the same information. The CTO says all the client wants is a working application; they know that they won't be getting all the quality. I say, hold one minute, first you say the quality is out the door and you mix in the words "working application". To me NO quality means that I cannot guarantee a working application. You must decide what you want. Either it's code that works or code that doesn't. I say it's sort of being pregnant, you either are or you're not. There's not much between. The PM disagrees with me, he says you can have code that's not fully tested and works. I say yes, but we are not going to test. We are not going to write unit tests and we are not going to put the system through a battery of tests. We are going to code it, maybe run it once and check it in. That's all the team is going to do. If that's what you want you have lessened our burden tremendously, and sure it will be easier to hit the target date. The CTO thinks for second and says "yes." Fine I say we need to meet with the CEO and inform him of the same. Meeting adjourned. Five o'clock arrives and the CEO asks if we can meet. Sure. The CEO asks who's going to speak first? The PM says that we all met this morning and that everyone is on the same page and we all understand what we have to do to get the project done on time. I speak up and ask if we are going to talk metaphorically or directly? The CEO asks for my opinion. I say, yes we all met this morning and yes we are all on the same page and the CTO gave us permission to write code that is significantly less quality than the previous iterations. He asks me to explain. I draw a square box and put "Scope," "Schedule," "Staff," and "Quality" at each corner. I say, all of us in this room understand that scope and schedule are unchangeable, and that it's too late to add staff (that for sure will bust our target date) the only thing to compromise is quality and today the CTO decided that's what we will cut. I continue, the problem is this decision should be coming from the client, not us. From my point of view we don't have the right to decide what the client wants. The CTO jumps in saying the client understands that schedule and scope can't change, he says they set it. I say agreed but no one has proposed to them that as a result of the inflexibility to the scope and schedule that we are going to compromise quality. I bet you anything that if you go to the client and explain the four variables, and if you propose that we're going to write crappy software, they will definitely have a couple of words to express. The CTO says "it won't be entirely poor quality." I say, this morning you gave us permission to reduce quality, now it seems like you're trying to find wiggle room. The pants are tight and we better get used to them because if someone doesn't inform the client of the situation then we all might as well pack our bags on June 1. The CEO asks that I go over the four control points again (Project Management 101). I do and he writes them down. He says he's going to talk to the main chief who writes the check. I say that if it were my client, I would be as honest as possible. On June 1st the truth will make itself visible and from my experience I'd rather be on the side of truth instead of the consequences. The CEO says he's going to give the partner owner a call and go over the issues. I offer my assistance if needed. The CEO still worrying asks about the velocity data, I say we are off approx. 15.75% over the last two iterations, and with the remaining stories we will hit approx. June 7. He asked about working overtime, and I said the calculation was considering overtime. We adjourn the meeting. We extend the iteration until tomorrow anticipating that we'll get some things completed by tomorrow. The client is scheduled to come in on Friday. What a day. 5.17 End of the second iteration and the client is scheduled to arrive around 10:00 am. I review the process again with the client. I give her a purple card for each story and I say she needs to write test scenarios to support what she expects the story to do. "There will be some overlap between the story and the test scenario, but there will be things you don't want the system to do and they need to be documented, and there will be dependencies on other actions that you'll want documented as well." She writes and tests. All the completed stories on the board get green stickers. Everything passed. Everyone is impressed. Yes it does look impressive but that's because she's testing two iterations worth of stories. The client and I go out for lunch, the other team members stay behind, and generally we don't spend too much time on business. But I do review the aspects of driving the project and iterate again how important it is that she take control of the project. She likes hearing the message. [she even giggles at my jokes] I also said, let us pretend for a second that a big Greyhound bus hits my team members and me. If that were to happen and we were hurt so badly that we couldn't work, which stories would you want completed first? I ask her to keep that thought until we get back to the office. We're back in the office and we review the remaining stories and I say, "now remember the bus scenario?" The client says, okay if you got hit by a bus I would want the following done first. I say, and in what order would you _absolutely_ need them done? She picks and sets the priority for each story. I make it _very_clear_ that I'm not saying that we won't finish all of the stories, I'm simply pointing out that she has the power to chose which stories she wants completed next, and in the order of her choice. "And if you want, you can chose to add to the list and change its order anytime." I say to the client, "remember it's our objective to react quickly. If we respond quickly to your needs, then you get more value for your business sooner." Before the client leaves she meets with the CEO and the CTO. They both come over to congratulate the team. They said they don't know what we did but the client is _extremely_ pleased with the project and progress. [We're still not going to hit the target date with all the features.]

Week Six

5.19 (Sunday evening) This is going to be an interesting week. Tonight the client sends a CRITICAL FOR JUNE 1 email about a product that they forgot to include in the original requirements. I'm not surprised. It's hard to collect all the "wants" upfront. Besides it's to everyone's advantage if we can react to the change. I'm not the manager and I think I should hold back, but I'm not confident the right message will get presented, so I reply. Again, my objective is to get the client on the team, give her the opportunity to make decisions, and give her the opportunity to set the priorities. We've gotta give her the wheel, she has to drive. This is the opportunity we've been waiting for. I reply to the client, and the others CC'd, requesting that she come to the office around 8:30 tomorrow morning and we'll go over the new stories and she'll have the opportunity to prioritize the ones she wants done by June 1. I let her know that it is the beginning of our next iteration so it's a perfect time to CHANGE the priorities. I do not like email or IRC for reviewing details, something for sure is going to get lost or interpreted wrongly. I prefer dealing with people. She replies back that she thought I would say that...by George I think she's got it. The CEO writes back thanking me for jumping on the problem, "Wyatt excellent answer. I will need a full written recap so I can present info to owners on Monday with costs and impact on current plans," he copies the CTO. Hmm, I'm thinking the CEO understands for the most part, but there isn't going to be any impact to the cost. I think it would be a bad move to charge his client more money. I send a message trying to discourage him to charge extra, and I recommend that we focus on the relationship and show them how we can react to their change. It's the relationship we want, not a couple extra dollars; if the client wins, the money will come later. 5.20 The CTO and I first arrive to the office. He asks my opinion about the timeline. I say the timeline doesn't change, but the stores that are in the queue will likely change. We won't know the situation until after the client writes the stories and we come up with the tasks. Then she'll prioritize. (I remind myself that the June 1 date is etched in stone.) He says that the client cannot change the stories, that the features have already been determined and they are part of the contract. I think to myself, did I hear him correctly? I ask him, how so? He begins to inform me that the client is not the stakeholder and therefore cannot change the priorities. Well who can change the priorities? He says, the partner owner of the company, the person who writes the check. Well we need to get him involved, I say. No chance in hell, says the CTO. (this is a Mr. Can't Do if I've ever met one) I'm not too pleased with Mr. CTO...as a result of my frustration I say that I've heard through the grapevine that we (I speak as the voice of a team member), have failed on two previous occasions because we could not deliver what the client wanted. He says that he has tried to accommodate the client's changes before but he and the CEO consistently got screwed. As a result when the check writer/partner owner asked about the progress, the client would say, "the application isn't finished, it doesn't work." The partner owner apparently would get all pissy and demand that my client get it done or else! He says, "because of this history we don't let them change things." I say to the CTO, by not being able to change you are also creating risk on your part. He says, that's why we have to keep to the contract. Everybody understands the contract, it's signed. Yes I say, BUT WE CAN'T FULFILL THE CONTRACT, WE ARE GOING TO FAIL! I ask the CTO how they were tracking the change requests, resetting the client's expectations and communicating the effects to the project. I argue with him for about 1 minute and he says that I'm looking at him like he doesn't know what he's doing. (He's getting defensive.) I think to myself that arguing with him is only going to create more tension, which is not necessary. I realize that I've gone to a place where I really don't need to go. I already know the answer. I back off and simply inform him that the first thing on the platter is to have the client write the stories. The voice in my head reminds me that my objective is to fix the problem, not create conflict. All of us want to achieve the same goal. I tell myself that I cannot get righteous. [Personally I like the CTO, he's truly a _very_ decent person, in fact everyone in the company is very decent. I've worked other places where this is not the case, and I appreciate that I'm dealing with good people. Unfortunately the Chiefs are used to doing it the only way they know and they keep hoping they'll pull a rabbit out of the hat.] The client arrives, as do the other team members. We all sit down and review the extensive CRITICAL email sent over the weekend. The client summarizes. As she describes each new request, she realizes that some of the requests can be pushed off till after 6/1. There are 4 new features that float to the top and I give her 4 white cards to write the stories in her voice. She starts writing about pop-ups and pull-down lists, and I ask her to write only what she wants the system to do, not how it should be done. I comment that the engineers will determine the technical approach to best complete the story. She agrees and starts writing. One of the stories is part of an existing story and we combine it as supporting documentation for the additional task. The engineers gather together and determine the tasks and the client returns at noon to review the duration of each story. We lay the cards on the table for full viewing. We separate the original stories from the newer ones. She sees the stories that can and cannot fit into the schedule. She wishes she could have a particular story but the duration unfortunately falls after 6/1. I'm guiding the client to make sure she chooses the stories that give her immediate business value and to think about what she can delay until after 6/1. We finally finish and to everyone's surprise the client reduces our risk. She delayed 4 stories until after 6/1, and they are stories that were originally part of the requirements that were gathered upfront, before the start of the project. The stories swapped in are all entirely manageable and on paper we will finish on or before 6/1. I feel a sigh of relief. The client leaves quite pleased that we could react to her new priorities. Damn , this lady gets it and she is definitely driving and part of the team. The CTO and CEO are exceptionally pleased, and I think a bit surprised. They both say bravo. We didn't do anything more than build a relationship with the client and instill in her that the project is a collaborative effort. From my point of view, getting the client on the team and having them drive the project gives them control of their business. The client's participation is the key to our success. The CTO says it's not official until we get the okay from the client's partner owner. ( I wish this guy would learn not to be so negative; he's afraid of his own shadow.) [I should note that during our meeting, the client asks the CTO about a product that she was expecting to use by 5/15. The CTO bristles up and confronts the client in an antagonistic tone. I found the exchange interesting, and it was nothing that I could help mitigate, it was fully in motion.] The CTO comes by later in the day saying "we have thumbs up." We start developing the newer priorities. By refactoring a component we wrote a couple of weeks ago, we were able to finish a story scheduled for 3 days late tonight. Tonight's the first night in the hotel. 5.21 Stand-up. We all look much better after yesterday. I don't see any reason why we won't be able to hit June 1. Man am I a happy camper. Joy, joy, joy! We're cranking away. The CEO pulls me into his office. He's obviously very happy. He wants my team and I to interface 100% with his client and to manage the entire project. I say that it will be our pleasure. He asks me about the stories that were delayed, "when will they be finished?" I kindly say, let's wait until we're done with the delivery of this iteration, and the client prioritizes at the next planning game. She might have a different view of the priorities at that point. *sheesh* Second night in the hotel. 5.22 No stand-up today, client came to visit. We demoed 2 stories that we've been working on. Neither are complete but the client was able to see the direction and liked the direction for both. The team took her out to lunch. I asked about things on the horizon after 6/1, to which she commented, there's so much work you're going to be busy for quite some time. I just checked in a completed story and went to the board and picked another to start tonight. Tonight the team with the CEO, CTO and the PM has dinner out. The CEO's assistant comments that she has never seen the client so happy. My partner and I work late tonight trying to get ahead of schedule. We both comment how the weight has lifted from our shoulders. My partner remarks how different the project is now compared to 2 weeks ago. He admits that he didn't think we were going to hit the date. Fool I say, and you were insisting that we could do it; I'm sure glad I didn't listen to your barometer readings. Third night in the hotel. 5.23 Stand-up. We're on target and it looks like we will definitely hit June 1. However, the Access Control framework is crashing the system and it's starting to get a bit annoying. I didn't make as much progress as I had wanted today. I've got to pick-up some speed by this weekend. I get an email from a senior partner at one of the big 5 consulting firms, someone with whom I've stayed in contact for several years. They invited me to come in to do a presentation on XP to their staff and top brass for a couple of their clients. This should be fun. My client asks if we'd like to extend our contracts. I'm back at home, hugs and kisses to the wife and kids. First agenda item is to sit in the steam room. 5.24 Stand-up. Client came to visit. This is excellent! From zero participation to 2-3 times a week face time. This is a good client. She is definitely part of the team. The Access Control framework seems to be fixed. I have 1 more day left to complete my story which I will finish this weekend, and we have 1 story left worth 4 days and we'll be able to put 2 people on it. The team is feeling very confident about the project, but I'm not going to overload myself with joy quite yet. This was a very good week! The client is driving. The team is happy. I can't think of a better situation. ...the game isn't over...