A Conversation I’d Like to Have

3 03 2012

Do you ever talk to yourself while you’re driving alone, playacting how things might go if you were able to say what you wanted to the people to whom you wanted to say them?

I do.  It doesn’t usually do me any good, but I do it anyway.  Especially these days, since I have a much longer commute than I used to have.  For example:

“Would you stop screwing around with your Agile teams that way?  You can’t just keep breaking them up and stirring them around and re-forming them and expect any decent velocity from them!

“People are not commodities.  They’re not interchangeable.  They’re unique individuals, with unique aptitudes and unique skills and unique strengths and unique weaknesses. Put a small number of them on a team and leave them there, and they’ll learn all those things about each other and grow to be able to combine their strengths and cancel out their weaknesses.

“A brand-new, immature Agile team that has only one or two projects under its belt isn’t particularly valuable, true, except that it has the potential to grow into an experienced, mature Agile team, which is particularly valuable.

“For example, here’s a challenge. I am under no illusion that you will take me up on this challenge, but I’m not bluffing. Take Kevin and DJ and Gabbie and me, and put us on a team.  I don’t mean add us to an existing team: I mean make a new team out of us.  Give us two of your better QA folks—say Matt and Kay—and a product owner who’s in a bind.  We will blow the frickin’ doors off anything you folks have ever seen in this company before.

“Why—because we’re superintelligent?  Hey: you know me well enough by now to say definitively and with confidence that I, at least, am certainly not superintelligent.  Because we’re expert programmers?  No.  Because we’re an experienced, mature Agile team.

“We know each other; we’ve worked with each other long enough that each of us knows how the others work.  And we won’t stand for any frickin’ bullcrap.  Our overriding concern is not following IT’s established rules and processes: our overriding concern is creating business value for our product owner as quickly and efficiently as humanly possible.  If your IT people support us, we’ll work with them.  If they get in our way, we’ll bypass them.  We will have something in production by the end of the second week, come hell or high water, and at the end of every week thereafter.

“But I warn you: after experiencing a team like ours, that product owner will be forever corrupted.  He’s no longer going to be interested in waiting for approvals from committees of architects or waiting for monthly releases or waiting for weeks of big design up front to be complete…or really in waiting for much of anything, for that matter.  He’s going to want what he wants, and he’s going to want it right now, and if you tell him you can’t give it to him on his time schedule he’s going to point to us and say, ‘They can.'”

Later:

“Yeah…listen, I heard something a little disturbing yesterday.  Do I understand correctly that you have an application you want us to put into production?  Because we haven’t heard anything about this application: it’s not in our process or on our schedule.”

“No, you don’t understand correctly.  The application is already in production—has been for almost two months now.  We hit 200 simultaneous users last week.”

“[indulgent chuckle] I’m afraid your information is mistaken.  I would certainly know if your application was in production, because—as you know—I oversee the deployment process; and I haven’t put it in production.”

“It’s your information that’s mistaken.  We talked to you folks—what, ten weeks ago or so now?—about our application, and you told us we’d have to write and submit a proposal to the proper committee and have it discussed and approved at the next quarterly meeting, and we simply didn’t have time for that; so we hired a hosting service in the Cloud and deployed it there.”

“No—you see, in order to do that you’d have to…wait.  Wait.  What?!”

“I told my team that I needed the application in production as soon as possible.  They talked to you guys, then decided it was possible to put it into production sooner than you could, so that’s what they did.  They’re Agile, you know.”

“But you’re not allowed to do that!  We don’t host our code on third-party servers, we host it on our own servers, under our control.  You’re going to have to take it down and have us put it up on our farm.”

“What did you say to me?  I’m not allowed?  Listen, let’s talk for a minute about what I am, rather than what I’m not.  I am the business.  You’re IT.  I’m your reason for being.  You exist to serve me, not to tell me what I’m allowed to do or give me orders.  My team is leading me to really understand that for the first time.

“But look, I’ll tell you what.  You’ve got a proposed requirement for our application.  Fine.  Write me up a story card, and I’ll put it in the backlog. I’ll prioritize it among all the others written by my team and me.  If you get fast enough to give me the same level of service my team gives me with our hosting service, or if the application gets mature enough that we change it so seldom that your latency doesn’t really matter, your card might get somewhere near the top of the backlog.”

“It’s not a good idea to talk to me that way.  Since the application didn’t go through our established processes, we can simply choose not to take the responsibility for supporting it.”

“We’re not interested in having you support it.  My team is doing a fine job supporting it themselves.  As a matter of fact, the defect count is so low there hasn’t been much in the way of support to do, anyhow.”

“They didn’t consult with any of our senior architects.”

“Or the junior ones either—yes, I know.  That’s one of the reasons they were able to move so quickly.  Another is that they wrote it in Scala, which enabled them to use a couple of new frameworks they say really gave them a boost.”

“Scala?  Scala?!  We don’t support Scala!”

“Yeah, we noticed.  You don’t support git or IntelliJ or Jenkins either.”

“We can’t maintain that—none of our maintenance people know any of that stuff.”

“We’re not interested in having you maintain it.  My team is going to maintain it.  They’re the ones who wrote it, after all—it makes sense for them to maintain it.”

“Well, okay, what are you interested in having us do?”

“Hey, I didn’t call you; you called me.  You just go on doing whatever it is you do—make a rule, require an approval, establish a process; I’m just guessing here.  I probably won’t have a lot of time to talk to you for awhile: I’ve got about two more iterations of stories on this project, and then I’m going to have my team start another one.  I’ll tell you about it if you like, but I’m not interested in having you support it or anything.  My guess is that we’ll have it serving users before you could have gotten it through your process.

“This Agile stuff is really cool.  You should try it sometime.”

Advertisements

Actions

Information

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s




%d bloggers like this: