My guideposts

When I talk about Organizational Transformations or Agile Transformations, I am talking about the engagements as I usually see them. Some company - often a market share leader in their industry - wants to be more like what they imagine Google, or Facebook to be. They talk to their consulting supplier of choice or maybe several and decide on a framework to become Agile and awesome.

By the time I come along, there's usually a project plan - sometimes disguised as a backlog - that includes milestones and payment triggers etc. There will be planning meetings and a sorting of the workers to become agile teams of one type or another, decisions about whether a particular function should use scrum or kanban, whether we should use Jira or Rally, how many columns to represent todo, doing, done etc.

What's often missing is the universal understanding of why we're doing this and what we hope to accomplish. This often leads to dark scrum and a general sense that the people in charge and the consultants they've hired are full of shit.

I assume the point of these engagements is to become capable, high performing, learning organizations that delight customers and take all the market share from their lesser competitors. The goal of the exercise is not to become good at performing the ceremonies and practices of any framework or method - methods and practices are probably necessary, but are not sufficient.

Here are some things that I think are important:

• Increase capacity/capture value everyday - any day might be the last day for the project.
• We should never be one-deep in a skill or position - people should be able to go on vacation or take a promotion without leaving a gaping hole.
• We must be able to make a simple software change to production in one day - shorter is better.
• Teams must be capable of independent action - if three teams are required to make a change to your three tier app, you gotta fix that.
• Teams have discretion and authority for their work - keep friction and approval processes down
• No out-of-band reporting - the natural by-products of the activity must tell the story. 
• You must always know what your apps are doing - I never want to learn from a customer call or twitter that our website acting weird - same for internal apps.
• Every component or activity must fight for it's life - extra is extra if it's dumb get rid of it.
• We should always minimize complexity where we can - Keep your stack short.
• No resume driven development - we'll make time for learning and playing.
• Keep up with the tech - play with the cool stuff enough to know if/when to adopt it.
• Working here should make you more marketable - learn and grow, I'll help.
• Behave - nobody wants to work with a jerk and they don't have to.
• It's not OK to suck - if what we do sucks, we have to fix that.

There are other things of course but these are the big ones for me.

Thanks for reading - Mike