"You want me to lie to you, and I refuse."
I sat in a large-ish meeting room with the project manager and a senior consultant coerced into "diffusing the tension" on our small project team. We were all technically consultants - working for the same company even - just in different roles. The Project Manager was PMP certified and he actually knew how to manage projects, something all too rare in his field. He was, in my opinion, confused about his role - fancying himself a developer.
His contention du jour? "See what I have to put with? Andy won't give me firm estimates! I can't go back to the client and tell them what he says - they'd fire me on the spot." I saw his point. In fact, the idea of him getting fired had appealed to me several times already in our short relationship. And things were getting worse between us: I had progressed from realizing his crap was crap to not taking it to openly identifying it as such, though never in front of the client - that would be bad form - but in front of the team; which was not only challenging his leadership but openly defying it.
So here we sat. Diffusing.
I felt really bad for the nice young lady suckered into this impossible task, this unwinnable battle. She was (and still is) very good at her job. Hearing a portion of 50% of the story, she had already decided the best way to handle the situation and was prepared to hold the meeting as an outlet for her suggestions to "make things better." Sadly, portions of the remaining story were revealed that challenged, then undermined, and finally negated her plans. I could see it on her face, but it was really visible on the face of the PM. His plans were unraveling before his eyes. I wasn't reading from the script he had carefully crafted for me. He was losing.
No one likes to lose.
But if someone must lose and the choices are you or me, guess which option I will select? So in answer to his request for definitive time estimates on an extremely tight timeline, I said "I don't know." That's what set him off - this time.
"Andy, you've done this sort of thing for years. You are a respected software developer and database professional. Surely you have an idea how long it will take to accomplish these tasks" she said. Flattery. Nice, and appreciated, but ultimately as ineffective as the demanding tactics of the PM. "No one approached me and said 'Andy, how long will it take to write this project?' If they had, I would have said 17 weeks - mainly because it rarely takes less than 17 weeks to bring any idea from inside people's heads to a production-ready, distributed, smart-client application in a Fortune 500 company."
"How many weeks were estimated?" She didn't know this? And she was in this room? "Eleven," I responded.
"But you agreed to do the project!" squeaked the PM. "Agreed, yes. Promised a feature-complete date before the team was delivered a complete and unrevised requirements document? No.
"When will we be getting those requirements, by the way?" Her eyes widened and his face flushed. "You knew the nature of this project from the beginning and you agreed to work on it. You also know we don't have a complete requirements document yet, but we're close. Our client is not used to working this way." I could have pounced on him in that moment of weakness, but why? Everyone in the room knew this was new information to our facilitator - you could see it on her face. She was smart and was putting it together: the PM had witheld facts about his performance.
In addition, I wasn't raising my voice or even being unreasonable in this meeting. I'd done both in recent team meetings with the PM and developers. I was calm, cool, polite, and collected. I didn't interrupt. I looked everyone in the eye. Most of all, I was right. So her experience was not lining up at all with the expectations she had upon entering the meeting.
"I can't promise you I'll deliver on time unless I know what it is I'm to deliver. I gleaned from your description of the client that 'they aren't used to working this way.' I knew the risks going in. I like a challenge and I believe it's possible we'll finish on time. But all I can promise is that we will continue to do our level best as a development team to bring the project to some semblance of completion on or around the due date.
"I'm not sure we'll make it so I won't tell you we will. I can't tell you when I will know a date to tell you because I don't know all the details at this time of what we're building. I can tell you that I will be able to provide an estimate sometime after feature-lock, in writing.
"For now, the best I can do is state that we're roughly half-way through our 8-week development cycle and we've addressed roughly half of the show-stopping issues this project - as we now understand it - has posed. We also have a good feel for the historical three-day-change cycle that seems your modis operandus. Taking all that into consideration, I'd say there's a better than 50/50 chance we'll bring this in on time.
"What I won't do - ever - is lie to you. I won't tell you 'this will happen on this date' until I know that to be accurate."
Calmy delivered, without interruption. To his credit, the PM had figured out interrupting wasn't working for him. It was having quite the opposite effect.
A few seconds of silence. Our facilitator broke it with "Ok, we've all learned more about the issues with this project. Andy, I will talk to you offline about suggestions to make the project more predictable. Thanks for your time. [PM], can you stick around for a few minutes?" I never heard from her. It was obvious from the change in tone that our PM certainly did.
It was March 2006. Professional SQL Server 2005 Integration Services (Wrox, 2006) had hit bookstores a couple months before. A quirk of Wrox's placement of author photos on the cover and a ten-author writing team combined with the fact that "L" is about halfway through the English alphabet to place my photo front and center on the cover. To the outside world I appeared to be an SSIS guru.
I didn't feel like a guru.
I had moved my family from Jacksonville Florida - our home for three and a half years and the city our first two children were born - back to Virginia to be closer to both Christy's and my families. I'd taken a contract-to-perm position as a DBA / web application manager in a small software department in Richmond. The abbreviated version: The job did not work out. When I realized they weren't going to hire me permanently I started looking for another position. Having a book with your picture front and center on the cover is a great visual aid for interviews.
I'd taken a job with the company I felt was the best fit. It was a good decision - then and in hindsight. I made friends there that I will remain in contact with for the rest of my life. Good people.
The Fortune 500 gig sounded promising. It was my first opportunity since joining the firm a week or so prior. There would be an application. It would talk to a database that needed to be created. Right up my alley.
It got better. As we plodded through the initial thoughts on the application, the developers wanted to use the new SQL Server 2005 XML data type. We requested, and were granted, permission to stand up a SQL Server 2005 development server. What's more, the DBAs were instructed to make me a local administrator on the server. This is a minimum requirement - making the lone database developer / DBA a local admin on the server - for any successful development effort. We were off.
The client wasn't used to working with a methodology. I have no idea how the PM managed that relationship, and I don't think I want to know. He was belligerent and demeaning to all of the team with one exception. And there was very little respect shown from him.
None of this helped the project. It was high-profile and so receiving lots of attention. But it was also changing - often, and a lot. A bad combination. An example of this: in one decision we lost a database tier. Yeah - decisions of those types and magnitude were being made daily. The one thing that didn't change? The deadline. The worst of all worlds.
And yet I'd been here before. The landscape, though treacherous, was familiar.
The Dev team gelled. It's always nice when that happens. We fell into our roles naturally. There was broad common ground with respect to humor. We laughed a lot and that kept the tension of the deadline at bay. We helped each other and worked well together.
And we did amazing work.
You can learn a lot from observation. My first clue that things were going to be diffcult with the PM? I had no good ideas. None. My ideas were good thoughts, mind you, but they all needed tweaking before being presented up the chain - as his ideas. An example was project development methodology. But first, why was I concerned with project development methodology? Shouldn't that fall to the PM? It should, but nature abhors a vacuum. Someone needed to make the decision so I did.
"Scrum suits this crazy-timeline-loosy-goosy type of development," I said. "No one here knows what Scrum is. We can't do it that way" he replied, and then boarded a plane for a conference in Vegas. Our overgrown closet had two large whiteboards. I returned to the "war room" (I wanted to hang camouflaged netting from the suspended ceiling but was overruled...), commandeered one of the white boards and converted it into our burn-down board.
"We're doing Scrum" I announced to the team. "What's Scrum?" they asked, and I told them in about five minutes. That's one of the beautiful things about Scrum - it takes about five minutes to introduce to a develolpment team. We started meeting each morning at 10:00 AM for 15 minutes.
While the PM was in Vegas, the client's primary stakeholder popped by to see how we were doing. He asked about the project and noticed the burn-down whiteboard. "It's Scrum" I told him and we explained what we were doing and why. He smiled and nodded and asked if there was anything he could show his boss. One of the developers had just completed a small demo application demonstrating a critical part of the functionality. He non-chalantly said "Sure" and proceeded to show off his handiwork.
The stakeholder was impressed, to say the least. He borrowed the machine to show his boss, and his boss showed her boss, and so on and so on. It stopped at the CEO. I am not making this up. Later that day we were visited by the Director of the Project Management Office. This Fortune 500 company had decided, that morning, to adopt Scrum as their project development methodology.
When the PM returned from Vegas, he learned about all this. His response: he scheduled daily Scrum meetings on all our calendars at 10:00 AM. What a brilliant idea!
There were many, many more episodes like this throughout the first half of the project. But like I said, things got better after that facilitated meeting.
The project ultimately came in 10 days late.
The client considered it a stunning success. Stunning successes, like beauty, are in the eyes of the beholder. If the beholder happens to have a large checkbook and a willingness to part with some of the contents of said checkbook in exchange for stunning successes, we can have a working relationship.
The PM was hired away from the consulting firm to work full-time for the client - no doubt a reward for his obvious talent at delivering results. I was happy for him. Things had been better since the meeting four weeks prior.
Instead of insisting he was a developer and demanding we write code to his specifications, he took his hands off the day-to-day internal workings of the team, allowed us to do our jobs, and then went and did his job. He even went above and beyond about a week after the meeting, offering to jump into debugging an issue working with me (of all people). To my surprise we worked well together. And since the team worked in an overgrown closet, everyone saw us working well together. There was fresh respect all around. Kudos to him for realizing and then seizing the opportunity.