Change the company culture first

I’ve been involved in quite some agile consulting gigs in my work life.

There’s one lesson I want to share: if you want to change an organization you have to change their company culture first.

If you are trying to employ a consultancy firm try to get ready your people to start with, avoid wasting money making sure that your employees are ready to embrace the change.

Make sure that you communicated well and straight that things are gonna change now.

If you are a consultant, make sure that you will have enough slack on the project to work on the company culture, plan, discuss with the client when and how that work will be performed.

Otherwise change won’t work: people will work in micro waterfall iterations, they will use continuous feedbacks to drive others people carriers, they will still micro manage their teams, they will eventually fail and all their effort to “change” and your effort to make them “a better” place to work for will vanish without evident benefits.

Promote environments not artifacts

Lately I’ve been working quite a lot with environments and release issues.

On my last project we had eight environments: development, continuous integration, test, performance, pre-live and live plus a couple of demo boxes.

This over-engineered  situation caused few issues but at the same time made me think and write this blog post

What we did to improve deployment

Well, automation is the key, even if we are in a windows environment we wrote remote deployment scripts to do remote deploy in the machines using psexec and robocopy.

We template our config files and we have one config per machine.

So far so good, old school good practices.

What still doesn’t work

Your software is done, finished, all the test are passing, unit and integration on the development boxes, acceptance on the CI box, the QA is happy in the testing environment and the product owners are happy on both of the demo boxes, the performance test team is happy on the performance box, the security team is happy with their tests executed on the pre live box.

But still your sofware may not work on live. Or most likely in any of those environments.

Configuration is vital

Your application without configuration doesn’t neither start or with a wrong configuration won’t log or work properly. There’s test coverage on all the aspects of your application but not on environment configuration. You may misspell a name of a server or simply forget that something is different from environment to environment. Your application won’t work as expected.

The configuration of the environment itself may cause serious problems. The most different your live boxes are from your test/integration/performance ones the higher is the risk that your software won’t perform as expected on the target servers.

So, my humble recommendations

Move fast

Moving fast is essential in any aspect of software development, when talking about releasing software is essential that you should be able to continuously deploy and redeploy in a repeatable stable way your application as fast as possible. Use remote scripts, even if you are not working with the cool kids in the ruby world do something similar to what capistrano does.

Have a look on the heroku website for a good example of moving fast…

Reduce as much as possible the number of environments

It’s clear that in the above example we have too many environments, if you have full control ask yourself why do you need them and just take them off. If an environment doesn’t produce any value it’s just a waste of time and resources. Environments can be recycled, most of the applications won’t need two demo environments and a performance environments available for the whole project life-cycle.

How would I cut down the number of environments on my previous example?

Development, continuous integration, test & performance, that’s it, four, it’s a 50% cut down!

A good rule is that your environments should be the same number of your story wall lanes:

1. Story in dev > development environment
2. Story dev complete > CI environment
3. Story in test > test environment
4. Story ready to sign off > performance environment

The performance environment can be used as stable build environment for showcases, demonstration of the software and indeed performance tests. But also for one last, more important thing, which is the whole point of this blog post:

Promote environments not artifacts

Imagine that you’re happy with you software, it has been signed off by the product owner and it’s performing well.

Probably you made some changes to the performance environment, maybe you started with a cluster of two machine and ended up with a cluster of four. Now you want to go live, but the live environment that you have is different, you may have some problems.

My idea is to promote the whole environment. You are probably using cloud computing or virtualization, just move this stuff to the live environment, clone it and you are done.

Promote the environment with the artifacts, all together.

Try to define your environments as executable scripts (in the *nix world won’t be that hard) and version control these scripts with your environment configuration, the creation of the whole environment should be scriptable, repeatable and should evolve with your code.

Mark told me that Chris Read has been talking about this stuff for years, you may want to check out his blog or his presentations, he’s anyway way much better than me explaining and making these things real.

on putting tasks on the story wall

Somehow it happened, the wall was full of cards, literally there was no more space for adding anything anymore. I didn’t count them but probably we had more cards this week than in the last 2/3 iterations summed up together.

I went mad, I started grouping them. Then I realized why I hated so much all those cards sticked on the wall: it seemed impossible to make it.

Putting tasks on the story wall is a very dangerous activity, basically you loose in the blink of an eye all your knowledge on the team work load and on the team todo and done.

A card is like a tile, the lanes on the wall have fixed size, it’s a constrain, it’s a choice, you cannot change the size of the smallest story while the project is ongoing, you will loose track of what’s going on.

Extending this then I thought about our bigger story cards, we are currently using three sizes, 1 story point (S), 2 story points (M), 4 story points (L).

In theory you may try having three different sizes of paper cards, probably in that way you will better understand the load on the wall, or even better try to split those huge cards in smaller ones, as much as possible (always good).

Putting tasks on the story wall using the same card format/color as stories is seriously dangerous, use a dedicated swim lane, group them or write a card that contains similar tasks all together.

Learn practises and Learn how to live without them

Agile is hard to embrace, agile is hard to teach.

“The problem” (and the strength) of agile development is that it never defines strict rules to follow always and in any occasion.

I can imagine myself being a consultant preaching RUP (IBM I am not impressed with you guys preaching agile), I’ll give to the client the book, I’ll tell them to follow my rules, end of the story.

Now, let’s forget the manifesto, let’s forget all the blog posts, the white papers, the conferences.

What the world agile means? I’ve searched on the Mac Dictionary application

It says:

agile |?aj?l|
adjective
able to move quickly and easily : Ruth was as agile as a monkey | figurative his vague manner concealed an agile mind.

That’s all you need, be agile like a monkey.

Embrace iterations of two weeks? Fine, after some time if you feel like you can go faster without, take them off.

Embrace a retrospective per iteration? Fine, after some time if you feel like they are not making you go faster, take them off.

Embrace the iteration planning meeting? Fine, after some time if you feel like they are not making you go faster, take them off.

And once you took off all the practices, start from scratch, try to understand if re-introducing them will make you go faster, be agile like a monkey in the jungle, don’t follow pre defined paths.