Skip to main content

The Pirate Code: You and Your Official SDLC Process

Agile purists may be frightened to learn that in many enterprise environments, one of the first steps executive management may take towards agile adoption may be to establish an official agile SDLC process, and to post a diagram representing the process, along with its artifact templates, in some prominent place on the company web site.  There will be 3-D box diagrams and arrows on it for sure, along with many links and appendices.  The diagrams and artifact templates themselves will go through weeks or months of review before central posting, not to mention what will theoretically happen if your project adheres to the highly edited result.

One might think that leading with the official SDLC would seem to defeat the whole point of "self organization." Plus, one further conjectures, the kind of people who want to push agile from the top are just the ones who want to commit other anti-agile atrocities such as requiring an audit trail of changes to the plan or forbidding teams to spend company money on food.  "Run!" these pundits may tell you.  "Run away!"
http://talentedapps.wordpress.com/2008/09/19/investment-banks-and-hr-part-2-talk-like-a-pirate-day-edition/

Not so fast, me hearties.  In an enterprise environment, a posted SDLC sanctioned by your Chief Process Officer and/or your CIO may be exactly the friend you need to help move your pilot projects forward.  If I weren't so committed to the pirate theme, I would throw in a metaphor here about the baby and the bathwater.  Don't panic--the public embrace by a PMO of a new "agile SDLC" can be just what is needed to help trigger an organization's tipping point towards wide scale agile adoption.

How can this be?  Stop to ask yourself what the SDLC means in your context.  What's the worst that could happen?  Perhaps in your context, your executive management has indeed put the cart before the horse, the SDLC can never be followed by anyone in real life, and a swarm of "Quality Assurance Engineers" will descend on your pilot and shut it down before you even get out of Iteration 0.  You will be accused of orchestrating a flagrant violation the company's SOX and ISO policies, and ushered off of the premises with a small cardboard box of your belongings.  Kiss those Legos in the team room goodbye.

Okay, that's a pretty bad outcome for you.  You'll be forced to say things like "best thing that ever happened to me!" or "always glad to fail fast!"

The BEST outcome, on the other hand, might be the one where you get to write the SDLC yourself, and executive management agrees that just the Agile Manifesto will be fine without any further detail, and they give you a big raise and a trophy.  That might not happen though.

A pragmatic agile transformation consultant may instead want to embrace the emergence of a top-level posted SDLC as a signal that what you and your pilot teams are doing has the blessing of top executive management.  Believe it or not, in a large company, people do not want to have you show up, rub your hands, and say, "haha!  now we're going to break all the rules!  haha!"  What they want is reassurance that if they go through the pain of changing the way they do their work, the change will stick, others will learn from them, and their efforts will not be wasted.

A large organization is hard to change, and a small non-compliant pilot group runs the risk of being "first to contribute to reduced operating expenses."  On the other hand, a small pilot group on the vanguard of what is going to be the new standard operating procedure should be first in line to get those raises and trophies we were talking about earlier.

Most experienced corporate executives will tell you that the officially posted SDLC, like the Pirate's Code in the Pirates of the Caribbean movie, isn't the law on the ground, even in the case of an external SOX or ISO compliance audit.  It is, as several executives recently assured me with a piratical gleam, "more of a guideline."

Companies are always piloting new things, and teams on the ground are always deviating from central processes for reasons well understood by management and by those teams themselves.  If a process lists 150 required documents, every seasoned project manager in each line of business knows exactly which 5 they need to write out perfectly, and which others can be done largely by rote or cut and paste.  Even auditors will look for the de facto documentation on the process a team is using, and not start with the de jure information on the PMO's central web site, unless asked to do so.

You shouldn't fear a posted SDLC--you should do your best to contribute to it!  And you should be quick to mention to each new team that you coach that the corporate process now includes agile.  Send them a link!

Comments

Popular posts from this blog

How Do You Vote Someone Off of Your Agile Team?

One of the conundrums of agile conversion is that although you are ordered by management to "self-organize," you don't get to pick your own team.  You may not have pictured it this way, but your agile team members are going to be the same people you worked with before, when you were all doing waterfall!   I know I wasn't picturing it that way for my first agile team, so I thought I should warn you.  (I thought I was going to get between six and eight original Agile Manifesto signers.  That didn't happen.). Why "warn" you (as opposed to "reassure" you, say)?  Because the agile process is going to reveal every wart, mole, quirk, goiter, and flatulence issue on the team within a few hours.  In the old days, you could all be eccentric or even unpleasant in your own cube, communicating only by document, wiki, email, and, in extreme situations, by phone.  Now you are suddenly forced to interact in real time, perhaps in person, with written messag

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else. From http://www.yogawithjohn.com/tag/yoga-class/ Here's what you should think about: 1.        Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that: a.        You need your user experience people (if a

Your Agile Transformation Needs to Start with a Quiet Phase

From a really great blog post on agile adoption:  http://smoovejazz.wordpress.com/2011/02/16/an-agile-approach-for-adopting-agile-practices/ I've observed some different agile transformation patterns, and maybe you have too: Just Do Standups   (Shoot, then Aim):   some people feel that since you're "agile," you should just start doing stuff, like daily standups, and then build more of the the plan as you go.  Find a team and start doing some agile with them!  Start a revolution one practice at a time, one team at a time. Pros:   you're very busy from the start. Cons:   what exactly are you doing and why? KPI-Driven Change (Aim, then Shoot) : some people who have worked in large corporations for a while will tell you that to get the respect of the people, you need to start with a plan, support the plan with awesome printed and online collateral.  Then you "kick off," tell teams what to do, and measure them using "Key Productivity Indica