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!

Popular posts from this blog

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.

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 applicable) and your analysts at the beginning of the project, as always, b…

The Agile Business Case

Many agile teams have never seen a business case, ever, and they may even be proud of it.

Our mantra is that we deliver "business value," not just "software," quicker, better, and faster, but if so, we certainly don't spend a lot of time reporting on value delivery, and in fact we may be scornful about "analysis paralysis."  As software developers, we consider ourselves to be doing quite well if we can deliver the software every two weeks (or continuously).  And this is particularly if we've enabled this frequent high-quality delivery through automated testing and automated build-and-release techniques.  We've reduced business risk by making results visible more often, and allowing the business to change direction more frequently.  We assert that along the way of course we're also delivering value.  But how would we prove it?

I've recently posited that we shouldn't even think of doing agile projects without capturing and recording s…

Requirements Traceability in Agile Software Development

One of the grim proving grounds for the would-be agile business analyst (henceforth "WBABA")  is the "traceability conversation."  Eventually, you will have to have one.  You may have seen one already.  If you haven't, you may want to half-avert your eyes as you read further.  It gets a little brutal.  But if you close them all the way, you can't read.
Dialogue:
WBABA:   ...so in summary, we complete analysis on each story card, and then we support the developers as they build it that same iteration!Corporate Standards Guy:  but how do you do traceability in agile?  You have to have traceability.  It's broadly recognized as an important factor in building rigorous software systems. These software systems permeate our society and we must entrust them with lives of everyday people on a daily basis. [The last two sentences are an actual quotation from the Center of Excellence for Software Traceability website!] WBABA: [cowed silence]Corporate Standards …