Get All These Documents Approved and We’ll Put You Down for Next Quarter’s Release

10 10 2011

How does Agile fit into a company where getting your data supplier to add a field to the data being supplied takes a month?  Where you share read-only access to the development environment with several other teams, and you have to fill out a service ticket to have a change made to it?  Where new technologies and tools have to be approved by department heads before they can be used?  Where development machines cannot be reconfigured by developers, but must be maintained by tech-support personnel?  Where your production hosting service requires six weeks of notice before a production release, and it takes two weeks to assemble the documents describing that release and two more weeks to get them approved?

It doesn’t.  Obviously.  There’s no succession of small changes you can make to a company culture like that that will result in the company becoming Agile.  You can make your team completely test-driven with continuous pairing and everything automated through CI and the most beautiful retrospectives in the industry, and the best it’ll do is get you out to the line you have to stand in a lot quicker.  The line will be just as long and just as slow, and by the time your carefully prioritized stories finally get out to the customer, many of them won’t be of use to him anymore.

That sort of a culture results from layer after layer of process and ceremony being added to catch bad, buggy code before it hits the customer.  By the time it begins to constrain the company enough that it hollers for help, though, the process will be ingrained enough that the people ensnared in it won’t hear or won’t believe that a healthy Agile process produces code that isn’t bad or buggy in the first place.  They may actually be so riddled with Stockholm Syndrome that they like the process and believe the claims that it keeps them safe.

In a case like this, I believe you can’t change the process; you have to bypass the process.  Get a “hall pass” from a powerful ally in the company–perhaps the CIO or the CTO–that gives permission for this one team and this one project to do only what is physically necessary to get a bare-bones, hello-world version of this project into production just as fast as possible.

Hack together your own temporary data-translation code to give you what will eventually come from your data supplier when they get around to it.  (When they do, rip out the hack and use their more complete, professional solution.)  Bonus: if you test-drive the hack, you’ll have automated validation of their solution, when it comes, and if they like they’ll be able to look at your tests for a rigorous definition of what you want them to do.

Send somebody to Best Buy to pick up some machines to turn into pairing stations.  Download whatever you want onto them.  Decide among yourselves whether you’ll even tell the tech-support people about them.  Probably you won’t want to tell the department heads about them, at least not until you’ve gone too far to go back.

Set up your own development environment in a virtual-machine appliance and install it in VirtualBox or VMWare on each development machine and CI. (That idea comes from Justin Searls.) Have your sponsor tell the DBAs to provide you with a JDBC connection (or equivalent) and the necessary firewall holes and leave you the heck alone.

Deploy your code into production in the Cloud.  Provide your own production support for it: if you’re test-driving correctly and deploying automatically, there should be precious little production support to do.

Do whatever you have to do, but get into production!  Make a serious attempt by the end of the first week, so that you can have the bugs worked out and succeed by the end of the second week.  Thereafter, release to production every week at the latest and preferably more often–maybe much more often.

Users will love this–even if your application is really ugly at first.  Product owners will love it, because the short feedback loop will provide lots of guidance and energize the developers to produce massive volumes of value in amazingly short time.  By the time the rest of the IT crowd shambles together to assemble against you, you’ll have a lot of people on your side.

And once you’ve got that first project essentially finished, you will be in a very good position.  First, you’ll have established a proven way that things can demonstrably be done: the IT establishment won’t be able to call it hypothetical pie in the sky.  Second, if you’ve done it right, your project will be under budget, under deadline, and fraught by few or no defects–and the code will likely be the best code anyone in that company’s ever seen.  Finally, you will have presented all the forces for transformation with a terrific argument against all the forces of status quo.  All the product owners will be saying, “I want my product done the new way, not the old way.”  The developers will be saying, “That way looks like a whole lot more fun than this way.”  The CFO will be saying, “You’re telling me that switching everything over to the new way will save us seven million dollars a year?!”  The customers will be saying, “Wow: they sure got a lot more responsive and attentive all of a sudden.  Wait ’til I tell my friends!”

The IT establishment may hate you for that, sure enough; but if they do, they won’t be around long enough for it to be a problem.



Leave a Reply

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

You are commenting using your 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: