Part 1 | Part 2 | Part 3 | Part 4

Wow, where to start…

Can I just start and end with “never trust a PM named Stan?”

This has been the toughest post to write.  I’ve started and stopped a few times, some of it good, most of it bad.  The fact is, I did learn some things from this project, some of it new, and some of it stuff I already knew and this just reinforced my already-held beliefs.

Honestly, while I thought the PM had a clue at the beginning of the project, by the end of the project, my feelings about PMs were reinforced.  Of course, maybe my idea of what a PM is supposed to do is wrong .  Maybe I just haven’t had the opportunity to work with a really good one yet.  The PM on my current project seems to have his act together, but only time will tell.

Before I get to what I learned, I want to list some of the mistakes I made:

- I should have gone with my gut feeling at the beginning of the project.  Unfortunately, money talks and I needed the gig.  if I hadn’t taken the gig, who knows what I’d be writing about right now.

- I should not have been so quick to assume the tech lead role.  When I interviewed with Dave D., the recommendation he gave to the HR people is that I needed to work on a project or two before assuming a tech lead role.  He said this for a reason.  It would have given me the opportunity to learn how the consulting company did things and fully understand their process.  He was pretty open with me during and after the project about how things should NOT have played out the way they did.  I have led teams before and I’ve done a good job.  My mistake was thinking that I had all the answers for this project and could easily fix the problems.  Of course, I’m not sure anyone could have saved this project…but it would have been nice to see how someone like Dave or James would have dealt with it.

- when I did take over, I should have gotten clarification on my specific duties AND requested an experienced tech lead at the company as a mentor.  By the time I got the clarification, it was almost too late to do anything about it.  For example, I was supposed to lead all UATs (user acceptance tests), but the PM set the precedent and I actually only led one of them.  A mentor would have helped as well, for what I hope are obvious reasons.

- I took shortcuts that ended up costing us.  As I mentioned, early on we were under the gun to produce results so instead of taking the wireframes and re-developing them, we simply did a cut-and-paste job and then renamed controls.  The unfortunate side-affect that really screwed us was all the nasty inline styles and javascript.  We *should* have taken the time to strip that stuff out when we first developed a page.  Instead, in the interest of time, we simply kept it all in and ended up having to hack around a lot of it later in the project. 

- I should not have allowed any development to take place as long as one-line requirements were coming in.  I’m not sure how far this would have gotten me, but I should have been more hardcore about this.

- I should have approached testing differently and setup something like Watir or Selenium.  The UI testing was pretty random and reproducing issues was really tough.

I think the biggest thing I’ve learned / re-learned is DO NOT BE A HERO.  There’s more to life than work.  If a project is doomed to fail as I believe this one was, no amount of overnighters or long weekends is gonna save it.  I look back over those months and all those long hours and I wish I had some of them back.  Hell, I wasn’t even getting paid for most of the extra hours I worked.  Yes, it did seem like the right thing to do at the time, so there’s not much to do about it.  I was coming off a couple months on the bench and I wanted to prove (mostly to myself) that I could do it.

I’m happy with my selection of NHibernate and NHibernateRepository though.  I can’t count the hours we saved by not having to write stored procs and wrappers for those stored procs.  I’m also happy with the wiki and issue trackers I setup for the team to use.  These proved to be invaluable throughout the project.  Of course, the issue tracker became less useful once the PM accidentally wiped the entire database, but luckily that was in the last week of the project.

I am a firm believer in continuous integration and having good test coverage, but I don’t necessarily believe in putting a stake in the ground and saying “we WILL have X% coverage”.  Our goal was 95% coverage (mandated by the consulting firm), but that was a tough number to meet given how loose the requirements were and how often they changed.

There were mistakes made by others during the project, but I’m not sure they really matter anymore and I hesitate to bring them up now.  After saying that, I will talk about a couple of issues…In my opinion, the PM cultivated an inappropriate relationship with the client that essentially put him squarely on the clients’ side.  The CEO of the consulting firm I was working for was also an investor in the client.  Right or wrong, I didn’t agree with it and I think it cost us.  When issues were brought up to management, it was brushed aside.  As I recently told someone in an email, the company could talk the talk, but they almost never walked the walk while I was there. 

Just think about it…if they had supported the team and listened to us, I could be writing an entirely different series of posts.

Who is the most famous drummer from the most famous band in the world?

the reason I ask is that some news anchor asked this question and I was blown away (not impressed) by his answer.   I’ll post the anchors answer in a couple days.

Clarification: Living or dead

Update (8.29.2007 @ 9:50 EDT): Ok, so the news anchor said it was Ringo Starr, so most people that commented were thinking along the same lines.

I just ran across an interesting article on ABC News.

The Future of the Workplace: No Office, Headquarters in Cyberspace

I wish more companies would have this attitude.  Truly, outside of the occasional meeting (and even those are questionable), how often do you *really* need to be in the office when you have teleconferencing, IM, meeting centers if you do need to meet face-to-face and email. 

Related posts:
Tech jobs and telecommuting in 2006, 2007 and beyond

I AM 74% MEGATRON

Take the Transformers Quiz

I saw this at Keith Elder’s blog.  Not sure I agree with my results, but what can ya do?

I just saw on Jason’s blog that the Fall 2007 Ann Arbor Day of .NET will be on October 20th.  The Ann Arbor Day of .NET is always a good time and I’m sure this one will not disappoint.  Well, as long as that Mike Hacker guy doesn’t speak again (just kidding).

Sounds like a great way to spend the day before my birthday.

Ian Landsman had a link to a post by Andy Brice.  Andy submitted a bogus program (a text file renamed to .exe) to hundreds of download sites and actually received “awards” from many of the sites.  This mirrors my experience with a couple of shareware programs I wrote years ago.  In fact, I still get a few “you’ve been awarded 5 stars” emails every month, but I don’t even bother looking at them anymore.

Great job Andy!

Update: A great post by Bob Walsh discussing Andy’s experiment.

Part 1 | Part 2 | Part 3

The one thing our project didn’t have was a dedicated business analyst because the project manager was supposed to fill that role.  This was less than ideal, and in the end, cost the project in several ways.

At the start of the project, the PMs role was defined as:

• Responsible for overall delivery of the project
• Manage the release plan, Truth Plan, Project Log, Change Requests
• Regularly communicate project status to stakeholders
• Responsible for establishing project Cadence (scrums, status, UATs, etc)
• Work w/ SME to develop Use Case documents to be passed to developers.

Even though the PM was supposed to be the BA and develop use cases, our requirements almost always consisted of a “wireframe” and one or two sentences in our issue tracker. 

The process normally went something like this: the UI specialist to sit down with the client and the PM and have brain-storming sessions about the functionality.  The PM would take copious notes and the UI designer would make sketches of the proposed UI.  After the meetings, the PM would more likely than not scan his notes and upload them to our wiki and then forget about them.  The UI designer would spend days, sometimes weeks making “wireframes” from his sketches.  Most of the times he’d make his wireframes “work” using a variety of hacks and then he’d present them to the client.  What really sucked about this is that much of the time, the client would say something like, “cool, it’s almost working.”  :-\

In the whole scheme of things, there were probably 5 or 6 large pieces of functionality within the system, but by the time I left the project, we only had 2 use cases.  TWO.  That’s it.  Given the way the consulting company I was working for operated (or at least claimed to operate), we should have a few more than two.

From the day I took over as tech lead up until about a week before the project was done, I repeatedly asked for more use cases.  It’s damn near impossible to develop good software without knowing exactly what you’re supposed to be developing.  One or two sentences and a screenshot are far cry from a well written use case.  The lack of requirements and use cases didn’t just frustrate me – during the course of the project, there were 2-3 other developers involved and they let me know pretty bluntly that we NEEDED better requirements and more use cases.  I knew it.  they knew it, but unfortunately the PM didn’t see the importance.  I brought the topic up during almost every conversation I had with the PM.  At one point I even escalated the issue to the manager overseeing the project, but for whatever reason, it didn’t help.

One of the things I did was to tell the UI guy that he could no longer show the client the wireframes without passing them by me first.  Early on, before I intervened, he introduced some elements into the UI that were actually pretty difficult to implement and I wanted to make sure these things were caught before the client saw them and we were committed.

As I’ve mentioned, we were behind schedule almost from the very beginning of the project.  Behind schedule and under-staffed.  Behind schedule, under-staffed and under a LOT of pressure to get things done.  Even with the problems I’ve discussed, I was still very optimistic that with enough effort we could nail this project.  I was so optimistic that I worked 7 days a week for several weeks.  Most days I worked around 12 hours, but some were longer than others.  During that time, I only took a couple days off; one day to hang out with a friend in South Bend, IN  and the other to go to the Dayton-Cinci Code Camp.  The day I got back from the code camp (Sunday), I pulled an all-nighter to implement a piece of functionality that absolutely had to be in place by Monday.  It was not something I’d recommend to anyone, although I know some people enjoy working frequent all-nighters. 

It was shortly after that coding marathon that Will joined the team.  I didn’t know Will, but given who he worked with, I had every confidence that he could help us get ahead of the curve.  In the few weeks he was on the team, I went from overworked and panicked to less overworked and less panicked.  He helped me realize that in the whole scheme of things, the success or failure of the project really didn’t matter as long as I did the best that I could do in a normal 40-hour week.  Shortly after he joined the project, I had a great conversation with Dave Donaldson about my role on the project (I was never formally told what my role as tech lead involved until pretty late in the project) near the end of the project.  Between this conversation and almost daily talks with Will, I started to pull out of the “hero” mode and get my life back.  Life really is too short to spend every waking hour worrying about things that are out of your control and Dave confirmed that many of the issues were in fact out of my control.

In fact, one instance of taking my life back resulted in quite a blow-up with the PM.  A few weeks before Memorial Day, he took a 5-day weekend to go on a fishing trip while the other developers and I plugged on and tried to whittle our issue / feature request list down.  Not a big deal, right?  Everyone is entitled to some time off and I certainly didn’t begrudge him a little time off with his friends.  Fast forward to our 11am scrum on the Thursday before Memorial Day.   By this time, Will had rolled off the project due to monetary constraints, so it was down to John and I.  Anyway, the PM was filling us in on a meeting he’d had the day before with the client and a group of investors.  The gist of that meeting is that the client and investors “absolutely had to have” some features implemented by the following Wednesday at 3pm for a demo they were doing.

Did I mention this request was made the day before the start of a long weekend?  When he laid out the tasks that needed to be done, it was something like 40-hours of tasks to be completed over 5 days with 4 of those over the long weekend.  The conversation went something like this:

PM: “You guys need to get this stuff done for next Wednesday.”
Me: “but it’s a long holiday weekend.”
PM: “This stuff needs to be done.”
Me: “It’s a long weekend and I don’t plan on working.”
John: “I didn’t plan on working either.”
PM: “But this stuff needs to be done.”
Me: “It’s a holiday weekend and I have no desire to spend any of it working.”

After 10 minutes of back-and-forth on the subject, it came down to John and I saying we might work a little, but there was no guarantee that we would.  After all, we were given almost no notice, we had been working killer hours for about 2 months straight with NO overtime being paid AND it was long holiday weekend.   The PM seemed cool with that during the phone call, but not too long after that, he sent an email adding more tasks to the list — these new tasks brought the total up to 70+ hours to be completed by the following Wednesday.  It was at this point that I did something I normally don’t do.  I CC’ d my reply to a manager who was very cool about the whole matter.  He basically told the PM that he could NOT expect us to work over the holiday weekend with only a days notice.  Woohoo!  So, once again, we left it at “we’ll work if we have nothing else going on”.  Again, he seemed ok with it.

That was the most glorious, stress-free weekend I had experienced in a long time.  I played some WoW, I hung out with my family, I watched TV, but I didn’t work.  I didn’t even check email.  John pretty much followed suit and just enjoyed himself.

Fast forward to our scrum on Tuesday:

PM: “Well, I’m disappointed that you guys didn’t work that much over the weekend.”
Me: “I enjoyed myself.  It was a nice break.”
PM: “Ok, so what can we get done for tomorrow’s demo?”

It was at this point that things started to fall apart.  One of my jobs as tech lead was to estimate tasks and I learned early on that given our vague requirements I had to estimate high.  Out of all the tasks they wanted for Wednesday, only a couple were less than 8 hours.

Me: “We’ll get done what we can get done.”
PM: “Ok, so what can we get done by tomorrow at 3pm?”
Me: “We’ll get done what we can get done.”
PM: “Ok, so what can we get done by tomorrow at 3?”

Are you seeing the pattern?   In all seriousness, what other answer could I give?  We were having this phone call at 11am on Tuesday.  We had a list of tasks that were all at least 8 hours in duration and John and I were NOT going to kill ourselves to get this stuff done.  The fact is, WE didn’t commit to the Wednesday date.  The PM did assuming we’d work all weekend.  This was his problem, not ours and the manager was backing us up.

Me: “Look, we have X number of tasks, only 2 of which are under 8 hours in duration.  We’ll get done what we can get done.”
PM: “You’re being very non-committal.”

It was at this point that I lost my cool.  I won’t repeat what I actually said, but I will say my wife was in the room and she stopped doing whatever it was she was doing and looked at me like “OMG, I can’t believe you just said that.”  The phone line went strangely quiet for a minute or two.   In the end, he had to deliver the news to the client that they wouldn’t have most of the features he committed us to.

We had 3 weeks left on the project and there was no chance we were going to continue on the project due to financial constraints.  The PM wasn’t giving us good requirements, he wasn’t pushing back on the client when needed — in fact, he was siding with the client almost 100% of the time — and the fact is, I was physically tired, even after the 4-day weekend.  Week after week of minimal requirements, crazy deadlines and continuous demos had drained me of remaining “hero” I had left.

The last 3 weeks of the project were actually pretty quiet.  John and I did our best to implement the remaining key features and make the app more robust.  My final job was to assist the person taking over the project.  This was a guy I had interviewed for the team but had turned down due to him having NO experience with anything .NET or SQL Server.  Well, since he was a good friend of the PM, the PM convinced the client to hire him to handle the pilot and the rest as they say is history.   The 15th of June was a beautiful day — like a huge weight was lifted from my shoulders.  I honestly didn’t look back until I had a post-mortem with the manager a few weeks later.

Did I make mistakes?  Absolutely?  Did the PM make mistakes?  yep.  Did the consulting company we worked for make mistakes?  Uh huh.  Same with the client.  My final post of this series will talk about the mistakes we all made and the lessons I learned.

Wow, this was a long post.  Probably really boring for most people.  If so, I’m sorry.   I’ll try to post more interesting stuff in the very near future.

Too funny.  I’ve got a couple friends in Oklahoma that give me a hard time about my accent.  Oh, and BTW, of course all carbonated drinks are called pop.  What else would they be called?  soda?  I don’t think so.

My wife just confirmed that yes, it does indeed feel like 103.

So far I’ve written 3 posts that have been verbose descriptions about my experiences on the project.  Originally I thought about combining the lessons learned into each piece, but decided against it.  My plan is to publish the final narrative as part 4 and then part 5 will be the lessons learned throughout the entire project.  I’m actually more excited about writing the final piece than I am about writing part 4.