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!
This post is from Pragmatic Agilist by Elena Yatzeck. Click here to see the original post in full.