Andy's Mind

Software development is a very peculiar industry. If work is not fun for those doing it the products will be mediocre at best and so will be the company – it can make money but it will never be a great company attracting talented people.

This is so because software development is not really engineering – it only looks like it because it is so technical. If done right it is in fact a fusion of art and technology – very much like a craft only requiring mental, not manual abilities. If people are not emotionally attached to their craft (like those who code&test solely for the money) they will not care if they produce a mess of spaghetti code rather than an elegant solution, they will not care what the user experience will be and they will not really care what happens with the product after they no longer work there. The only way to make them care is to make sure work is fun for them and they see a reason for the product’s existence other than the revenues it will bring.

Of course, this rule is more universal – happy people work better in general. For example Southwest Airlines’ happy flight crews deliver a better passenger experience, happier dialysis providers at DaVita provide better treatment etc. However, in software development the difference has a more profound effect – an unhappy flight crew will get you from A to B as effectively, keeping development teams unhappy will in the long run ruin the products/systems they create if not the whole company. This is so, because the less fun their work is the more technical debt there is (of all kinds: bugs, low code readability, C&P programming, suboptimal ad-hock solutions limiting scalability etc.) – and technical debt is as lethal for a business as any other unpaid accumulating debt.

Why it is so? I could bring up some theories, but I think it is less important than realising it and taking notice. Big players do. Take Google for example. They go to great lengths to make the experience of working there as fun as possible. The most visible aspect of this is their offices (each is different, BTW) but it goes way deeper – the way they treat their people, the way they allow them to access all of their code for example, all of that shows that people running this company have a profound understanding of what makes development teams tick. And they are not alone in this, almost every leading business now goes to great lengths to ensure the work itself and environment make the experience as enjoyable as possible for the employees.

Just to be sure – “fun” means a lot more here than just a nice working environment, cool perks and good atmosphere. It also means a shared sense of purpose in what you are doing as a company and as a team. And it also means dedication to technical excellence – a policy of zero tolerance for makeshift solutions and lack of craftsmanship. This mixture means people working in such a company can be rightly proud of what they do, proud of where they work and want to continue investing their time&energy there.

The notion of seeing the workplace as fun is sometimes dismissed as childish. It is so because there are many jobs that simply can’t be made to be fun (think of garbage collectors, people working in slaughterhouses or on assembly lines – by now mostly Chinese – assembling over and over again same parts) and historically practically all work was “serious” – not fun at all. Luckily for us that idea is slowly eroding as people search for self-fulfilment. Spending at least 8 hours a day on a job you hate is definitely not self-fulfilment.

Globalization and shortage of talent, especially in software development and other high tech sectors, make it very easy to run away from jobs where the “fun” part is gone (or wasn’t there ever).

Therefore one of the key duties of executives in an IT company is to make sure people working there have fun at work. And that means not that they can play computer (or traditional) games in a special room or have fancy office furniture – this means ensuring they are having fun doing the actual work as I’ve already explained above. I’m joking sometimes that there are companies that badly need a CFO – Chief Fun Officer – to shake the boat and bring some fun back. But seriously I don’t think one such guy can make a difference – I think that rather this attitude must be at the very core of company’s culture.

How this looks at your current place? Is working there fun? If not – take my advice: don’t waste your life, move on.

I have been leading a two day workshop a couple of months ago and it was an interesting experience in servant leadership that I can now share. The workshop was about the overall systems architecture at the company I was working with at the time. My mission there was transforming their IT department into an agile organization and the workshop took place three months after the change effort started.

The catch was that I was doing it as the company’s CIO – effectively being the boss of all the other people in the room. Given the culture that existed there before it meant there was a real risk they will stay silent and expect me to tell them what architecture I had in mind rather than discuss their ideas. Therefore I had to adopt a very different approach to leading it than when I’m acting as an external consultant/coach. The fact that I genuinely had no idea how to solve the problem at hand helped me do it – I had no architecture to push for.
(more…)

What I suspected for a long time will happen just did: PMI has announced its agile certificate. This is a significant development for many reasons.

First of all it officially confirms agile’s position amongst respected management methods – as part of the mainstream. I wrote about it at length recently, so I’ll just point out here that PMI’s move spells the end of the “agile revolution” in one sense. Just like the Linux revolution before it agile came with a promise of radically reshaping the workplace. It will in some places, but overall (and just like Linux) it will not completely eradicate its older alternatives, but rather become one of them – another respectable, mature tool for managing projects/teams.
(more…)

With 2010 ending soon it is a good moment to think about the future of agile. First – lets define it: agile is a set of principles, methods and practices that emphasise short turnaround times, high flexibility (also as a way of dealing with risk through adaptation), focus on quality and teams. Agile has been around for a decade now and it is now widely known and accepted – long gone are days when barely anyone knew about it.

With agile now mainstream it is clearly loosing its initial momentum and freshnes. While many would object I think this is a sign of maturity. Agile as a phenomenon merely follows a natural path of methods/approaches from new to commonplace. With that its position changes. From a separate specialty driven by a few “gurus” and a crowd of active followers (and consultants) it is now becoming a part of every good manager’s methods&approaches portfolio. From something that few people specialized in agile will now be transitioning into something everyone must know to a degree appropriate for their seniority and specialty.

This is good news, because it means the agile movement has succeeded in changing the industry – even if it means that I can envision agile practices becoming part of the Project Management Body of Knowledge (PMBOK) in three to four years. This is the book despised by many agilists (most of whom probably didn’t even read it) yet agile’s inclusion there will be a sign of its success – and an end to an era.

In hope that in the near future there will be much less need for dogmatic “agile coaches” and much more for good pragmatic managers, who will be able to use and apply both agile and traditional project management methods – as well as manage the operational, financial and human part of their businesses/units/teams. Key here is to use methods, tools and tricks that are appropriate to get things done – as opposed to trying to squeeze every situation to fit a method one happens to know best. Dogmatism that I crticized in my last post doesn’t help here.