Skip to main content

Monatizing Transparency

As a budding agile coach at a new site, you are probably poised to champion "transparency."  You eager to introduce your friends to "information radiators," open lines of communication, and fortnightly project showcases.  But not so fast!

From some blogger who borrowed it from Dilbert without permission.
As a wise mentor of mine once said, "the truth is something to be very careful with."  The control of information directly and indirectly translates into control over budgets, income, and even job security.  Sadly, if you are working in any organization which employs humans, you need to be careful.  You will run into a world of pain if you misunderstand what will happen to the flow of money in your company when you change the flow of information. 

Three patterns to look out for:

1)  "Good news up; bad news down."  Are there people in your organization whose entire job it is to make sure that the people at the "coal face" stay in a perpetual state of concerned stress that the project, the division, and even the company is on the brink of disaster, in order to "boost productivity?" Do these same individuals simultaneously feed their bosses a steady stream of nothing but good news, so they can bask in a shared sense of "good management at work?"
  • Double check:  I suggest that if you think this isn't happening with your teams, you should double check.  You will likely NOT know about these people, because they will look exactly like the people who are actually excited to work with you. Once you leave the room, they will order their teams to disregard everything you have said, and try to minimize further contact.  
  • New strategy:  Whenever you start working with a new team, ask yourself what each member of the management chain above the team has to gain or lose if information flows freely from the bottom to the top and back.  Plan accordingly.  Trust, but verify!
2)  "Let's keep the meeting small."  How many times do you hear this?  As an agilist you believe in having face-to-face conversations with small groups of people, preferably in person.  So you may be inclined to accept the "small meeting" suggestion at face value because you already think it's a good idea to set up a meeting that fits your mental model of how a meeting should be run.
  • Double check:  who wants to keep the meeting "small," and what is the reasoning for who gets included and who gets excluded from the meeting?  Who would you have at the meeting, all things being equal, and everyone being available?  
  • New Strategy:  "Small" is never value-free.  "Small" means that the person who wants to "keep the numbers down" wants to build a consensus strong enough to overwhelm the "extra people" who aren't being allowed to slow things down at the meeting.  That can be something you agree with or disagree with, but please be aware of it.  "Knowledge currency" is being actively controlled every time someone plays the "let's keep it to just us three" card.   
3)  "It Depends."  Are you an agile consultant, or do you work with consultant helpers who answer questions with "it depends" as a standard response?   If you are on the giving end of the "It Depends" response, please consider the ramifications.  You likely feel you are speaking from principle, from the heart, and from the Agile Manifesto.  "Don't lock anything down!" you say.  "Make them think for themselves."
  • Double check:  where are you or your consultant friends making their money?  I don't think there is any bad faith going on here, but I do think there is sometimes a "principled" withholding of practical information which is a pattern perpetuated by professional people who make their living doing a bunch of specific things very well.  
  • Double check:  if you are on the receiving end of the "It Depends" thing, and you aren't getting enough useful factoids from your consultants to let you do something in particular better than what you were doing before, why are you paying them?  And if you agree that what you are buying from them is that they keep you "hungry" for continuous improvement, why in the world is that happening?  Were you really not hungry before?  Why did you decide to hire them in the first place?  Where did you get that money?  Seriously!  
  • New strategy:  Parties on both sides of the agile transformation consulting contract need to remember that important concept from the Agile Manifesto:  people are more important than process.  If the people being trained on agile are already empowered, thoughtful, careful, intelligent and prone to continuous improvement, then they should set up an agreement to be trained by their consultants on new techniques with a minimum of philosophical lecturing or Socratic game playing.  If the trainees are in a broken culture which doesn't allow for individual initiative, then there still needs to be a combination of long-term strategy for fixing the culture, which can take a long time, and short term tactics for working with teams within their current limitations.  In neither case should the words "it depends" ever be uttered except as a preface for one or more options, and re-usable advice on choosing between them in the future.
So I guess that was a bit of a rant.  Sorry.  At any rate, I don't mean to be all "Mayan End of Time" here, but you know what?  There is no innocent use of information, and there is no innocent refusal to provide information--every communication is an act in the world.  Please be very thoughtful in your communication choices.

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 …