So the other day I'm sitting there, doing Software Engineering Manager things, when along comes one of the ladder rungs above me.
"Got a sec?"
I immediately raise my shields. Not much good has ever come from one of the higher rungs seeking to speak directly with me, or, heaven forbid, and actual developer. It usually meant the rung has just finished reading some industry article and has a brain stuffed full of 'best practices' and 'industry standards' which they now want to 'leverage'.
I sigh without trying to look like I'm sighing and turn away from the WAR (weekly activity report) I was putting together. "Sure."
"What's our development model?"
Ouch. Even worse than I though. Beyond tech and into processes.... I begin formulating an answer that won't make more work for me or my team.
He continues. "I just got this call from [corporate HQ] and he said all our competitors are using Agile development. He wants to know if we are too."
I shake my head regretfully and with great sorrow. "Our official process is about as far from Agile as you can get. Officially, our documented process is Waterfall, except that we skip the design and verification steps."
He looks disturbed. Obviously not the answer he wanted. "Really?"
I continue, relishing his discomfort while I can, because in the end, I'll have to give him an answer that makes him, and corporate happy; it's the only answer he will accept. Trying to lead him to the truth is, ultimately, pointless. But I can have fun making him step in some dog-doo on the journey.
"See, in Agile, you foster a cooperative relationship with the customer. The developers work directly with them to build functionality as required in quick, modular releases." He nods like he understands what I'm saying.
"But we don't do that. We make the customer submit a requirement. Then our requirements section looks at it and decides if it's valid."
More nods.
"If it is, then they validate it and pass it on to System Engineering."
More nods.
"System Engineering looks it over and then passes it to Project Management. Project Management assigns a Project Manager and then passes it to us."
More nods.
"I grab one of the developers and we call the customer and schedule a review."
I wait for him to ask why the PM doesn't do this, but he doesn't, so I continue.
"At that meeting, we take their initial requirement and begin fashioning a v-1 functional requirements document based on their immediate need."
I wait for him to ask why the requirements section doesn't do this, but he doesn't, so, I continue.
"It takes a few meetings, but we eventually complete the FRD and come up with a tentative delivery schedule."
I wait for him to ask why the PM doesn't do this, but he doesn't, so I continue.
"I pass that schedule back to the PMs."
"And then?"
"Well, then we build it. We schedule milestone reviews for the customer to look at sandbox installs as we complete the various modules. If they need changes, they can let us know right then and we can work that in for the next milestone. Along the way, we keep a test install up and running so the customer can review it."
I wait for him to ask why Systems Engineering doesn't do this, but he doesn't, so I continue.
"If there are changed to the schedule, we coordinate with the customer and pass that back to the PMs. Once we get acceptance, we deploy it to the operational network."
I again wait for him to ask why Systems Engineering doesn't do this, but he doesn't. Instead he asks, "So that's Waterfall?"
"No, I said our official process was Waterfall. What we actually end up using is closest to Iterative."
Fear shines in his eyes. "So what should I tell HQ?"
Well, I've had my fun.... "Tell them we're using the Iterative model, which is just like Agile only better because we satisfy more of the user's requirements with the first release."
He beams and goes away happy. He'll probably get a raise. Isn't software development grand?
No comments:
Post a Comment