There was a recent online discussion I read about organizations trying to “engineer” their culture to improve employee morale – https://news.ycombinator.com/item?id=4210635. Note the discussion is on Hacker News, so it has its own nerdy flavor but setting that aside for a bit, most of the thread tears down something called “Corporate Culture Engineering”. Now I am not sure which consultancy is flogging this inspired offering to their clients, but I for one, believe some words don’t go together. A culture is something that grows organically from what the company stands for and does. Engineering a culture is an oxymoron.

potatolicious writes –  “Shortly before I left my I was given a plastic (code) ninja action figure, which was, supposedly, some kind of new corporate mascot. We were all encouraged to take pictures with this ninja in interesting places, as some kind of “fun” thing. But of course, you can’t order fun into existence, and the whole thing smelled very obviously of stuffy suits failing to get it. A fun, exciting company invents traditions like this, not vice-versa.”.

His experience was typical of large organizations trying to “invent” culture by going through the motions, it just ends up feeling weird…

potatohead on cubile wall Fun times at the office [1]

You can’t “engineer” an Agile culture by just “doing” Agile things out of context

Which brings me to organizations and teams that want to start Agile by “doing” things like iterations, daily builds and continuous integration. Organizations going through the motions of doing a scrum and so on when they haven’t started with the underlying principles nor bought into them run into insurmountable problems:

1. Daily builds keep failing as the team has not learned to test first

2. Continuous integration keeps breaking as the environment and tools have not been structured for automated build

3. Iterations get delayed as teams focus on getting all functionality in, instead of throwing out functionality to keep time-boxes

4. Risky functionality gets postponed to later iterations, instead of being tackled early on leading to very waterfall-like late stage problems

5. Functionality developed in each iteration is not demonstrable to customers, instead IT ticks off each iteration as complete

As with any framework, it’s very possible to go through the motions but never really buy into it.

What does work when you are building Agile IT teams?

Lets look at the Agile manifesto.

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more. [2]”

Any meaningful adoption of Agile has to start with the manifesto and buying into the principles. Just like a buttoned down manager handing out stuffed ninjas is counter productive, organizations starting with scrum without understanding (often without trying to understand) the underlying principles are not going to go anywhere. So many good frameworks and methodologies have failed miserably in an organization because they starting by blindly “doing” instead of seeing whether there is an underlying cultural fit.

Some things you can do to help get things aligned first:

Restructure your status reporting to show swift progress

IT status reporting is still stuck in the dark ages of “percentage complete”, risks and issues, which is largely driven by waterfall thinking. In a waterfall project, all we have to show for our efforts at the end of the week is a written status but for a well-run agile project, the deliverables come out at least twice a month. Make your status reporting more pictorial, with screenshots of how the application is progressing in production (or any environment where business customers and end-users can use and work with the application e.g. pre-prod) and the screens added each iteration.

This form of status reporting creates excitement for and helps build an Agile culture. While you are at it, throw the progress reports up on a blog so people have a nice reverse chronological view of how the project has progressed.

Build Agile infrastructure to support the process

You should be able to automatically build and deploy your application anytime to any non-prod environment from a central, version controlled code repository. You should have an effective workflow and tools setup for code review and pair programming. Your team should understand the development environment and able to set up and/ or clone the development, test or any other environment at the push of a button. Your team should be able to write tests as easily as they write code and along with writing code.

Use a modern version control system that allows your team to collaborate over a network. Give your team adequate training so they are able to use version control and the development tool-set effectively. Get help from someone who has been there, if your team is still using a monstrosity like harvest for version control – http://stackoverflow.com/questions/26176/why-is-harvest-being-purchased-at-all, get rid of it and setup an agile environment, hopefully working with someone who has experience setting up and working in such environments.

Agree whats success looks like and how to track it

Don’t set things up to fail by not agreeing beforehand what success looks like! Wandering around aimlessly into a methodology without any success criteria agreed up front is like setting things up to fail from the get go. If your organization does not have a way to measure success, you have to work on that first. Before adopting any methodology; work on creating an infrastructure to measure progress – use cases per person month, screens per person month, anything. While Agile cautions against forcing productivity measures such as “function points per person month” without understanding the teams velocity first, there has to be a way to measure success that is acceptable to the project sponsor (you know, the one bankrolling the project :-) ) and all other stakeholders.

There are many more things you can do in addition to these steps that will help align your culture with the Agile mindset. I am sure you will discover them as you progress on the journey.

Follow me @krishnakv for more technology, culture and Agile.

References

[1] Image courtesy Pukka Dave

[2] From Agile Manifesto

{ 0 comments }