Skip to main content

4 Step Knowledge Base: Jump Start Your Enterprise Culture Change

If you're reading this, you may be attempting a large scale organizational change of some kind.  And perhaps you are feeling overwhelmed at the huge amount of literature available in "the Google" about how to change a large organization.

Please, just stop it right now!  You are setting yourself up for the classic organizational change mistake:  letting the "perfect" get in the way of "the good."  Or even "the existent."  If you've even got a small idea that is a good one, just do it.  Stop pondering the big picture and try something.  Let's start with the concept of "culture change."
http://www.bizcoachaustin.com/services/jump-start-your-business/

Ask anyone, and they'll tell you, "oh a culture is the hardest thing to change."  Then ask them what they've tried.  Sometimes the culture is ahead of you, and you don't need to send out individual missionaries to personally convert and baptize new recruits one at a time.  Who died and left you and your hand-picked cronies as "the only ones who know what's going on?"

Re-imagine your cultural change effort as a cultural "channeling" effort, where what you're proposing makes sense.  If it does, and your enterprise is a fairly large one, then I guarantee at least one person, and probably many more (all of the smart ones, for sure!), has already had the idea you are trying to propagate.  You don't need to teach people--you just need to put like-minded people in touch with each other, so they can drive the culture change for you.

Practically, try the following:
  • Set up a "knowledge base:"  a website, shared file depository, or wiki of some kind which is read- and write-accessible to the population whose culture you want to change, and provide a curator of some kind to keep things relatively neat.
  • Recruit everyone you already know to be allies to put "seed content" on the site which will reward visitors for stopping by.  As you encounter new allies, send them to the site and request that they post something in particular that you think is great.  Encourage your allies to do the same type of recruiting.  Encourage everyone not only to post, but to comment and add questions.  If you find good designers or good editors, encourage them to help with the curation and organization of the site as it grows.
  • Set up a distributed email list associated with the knowledge base, and post to the list whenever anything new is put into the knowledge base.  Encourage people to ask questions on the email list, and post the questions and their answers on the site.  Set up an email archive of questions with answers, if you have the technology to do so.
  • Drive traffic to the site with every presentation you give, and every good interaction you have.  Host virtual and in-person get-togethers, and publish artifacts which come out of these meetings to the knowledge base.  Post your training materials.
Not to switch metaphors too close to the end of this post, but culture change really is a matter of "if you build it, (and it's a good idea that you're forwarding), they will come."  Latch onto your local evangelists and get them to get their peers involved. They have the contacts, and you don't!

http://utahrepro.wordpress.com/2011/02/22/if-you-build-it-they-will-come/

You do not need to master an encyclopedia's worth of "the literature" to make a difference in your company.  All you need is courage and one idea.  If Solstice could become Christmas this way, by comparison, enterprise cultural change seems like a walk in the park. 

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 …