Our culture is conditioning us to instinctively think of success as a one-time event. In movies when lovers finally overcome obstacles and get together the story ends – “they lived happily ever after” (the interesting questions is: “how?”). In sports an athlete runs, jumps, swims – arrives first or jumps the farthest so he is given a gold disc symbolizing his success. Done. No one can take it away from him. And so on.

This thinking spills into business. Many startups are created because people want to follow in the footsteps of others who cashed in big selling one (looking at some of them the thinking seems to be: “create a cool service, get noticed, sell to Google/MS/whatever, live happily ever after”). Also, the whole concept of a project is built on the idea that it is an effort with a definite end occurring at a predictable moment – and we can say it was successful when it reached this end as predicted. Done. Successful, closed.

The problem is all of this is incompatible with the current reality. This reality can be characterized by two key aspects:

  • Increasing pace of change – technology, social customs, fashions, regulations, markets – all of that changes much faster than it used to and the rate of that change still accelerates. We can safely say we live now in constant change.
  • Everything becomes more and more complex. This is largely a function of connectivity. Everything is now more connected and interrelated. Globalization means supply chains are long and complicated – a flood in Philipines impacts now manufacturers in Europe, China and consumers in the US.

    In IT specifically we build much more complex applications and we create way more complicated systems out of them than, say, 10 years ago. Much of this complexity comes from interconnectedness – when we connect systems together their complexity increases exponentially. We also use programing languages and environments that are much more abstract than 20 years ago – this may simplify programmers work, but in the end the applications produced are much more complex.

    To make things worse constant change seems to have just one direction: towards greater complexity. This means increasing complexity.

Clearly, if we consider it the notion of success as an event is visibly absurd in a constantly changing environment of increasing complexity. The basic assumption of the classic project definition is also clearly wrong. Completing a project as planned can’t be considered a success in this environment, because the assumptions made when creating the initial plan will in most cases be long invalid by the time the project ends.

This means we have to re-define success. My proposal is as follows:

Success is a state in which an organization (or a system, a team etc.) adequately responds to its environment.

By adequate response I understand delivering what the environment needs/expects while meeting internal goals/visions. Maintaining that state over time is much harder than attaining it once. To do it an organization must constantly analyze both the external conditions and itself then if necessary readjust itself as quickly as possible. In other words, in a highly complex and unstable environment the only way to maintain the state I call “success” is through empirical control. The problem now is that modern world as a whole is now such an environment.

This has deep consequences. The old management model in which someone bright at the top (a prince, a president or a CEO) would think, invent, plan then communicate to others who will just do as they are told doesn’t work anymore. The level of complexity we face now overwhelms the brightest minds, so we need all the brain power we can harness. This means we must form cells (teams?) and tackle the complexity in small chunks – just like we do when building systems using agile methods.

It would seem then that what we know as “agile” is in fact the only way to deal with the modern world and stay successful in it.

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.

Someone has asked if management or project management should come to the sprint retrospective 1. Think the way this question was asked indicated that there was some confusion regarding sprint retrospectives versus sprint reviews which, I think, is worth clearing.

Sprint retrospective and Sprint review are two different things that shouldn’t be confused.

Sprint review is for everyone involved, especially stakeholders, to inspect where the project is and discuss how to adapt as needed. Sprint review revolves around what was built – the “shippable product increment” produced in the last sprint – and the overall product, not how it was produced.

It is good if Product Owner “represents” stakeholders, but it is even better if they come and see themselves what was accomplished, what runs etc. My advice is to welcome management of all kinds if they want to come to a sprint review, just being sure they know what the purpose of the meeting and their role in it is. Ensuring that and educating them is primarily Product Owner’s job, but of course the Scrum Master may assist him.

Sprint retrospective is primarily for the team to inspect their last sprint, concentrating less on what was done than on how it was done, and then adapt their way of work. I wouldn’t include anyone outside the team in those, besides maybe the Product Owner if he/she wants to join.

A common objection to bringing management of any kind into retrospective is that team may not be comfortable talking about their dirty laundry in front of them. It is indeed very valid – but it is also worth noting that from managements’ prospective this would be a waste of their time to, for example, listen to developers debating how to improve branching in their code repository. Even if the management knew what the heck the team is talking about this is not something they should waste their time on. Managers have lots of things to do (collectively called “bigger picture”) which no one will do for them – this is where their time will be better spent.

Having said that an overall retrospective on the project or on a longer chunk of it (like a quarter or half a year) that would include management may make sense, but it would not necessarily include all team members (if you have many teams that would make it even impossible to do). Such a retrospective would concentrate on “big picture” and could be very beneficial – if there is of course a right atmosphere within company for people to be honest enough in such a retrospective for results to be useful.

Speaking of retrospectives – definitely worth buying is “Agile Retrospectives” Esther Derby and Diana Larsen. There is not much to read there – just a couple of introductory chapters – but it is a great cookbook of various techniques to use in different phases of a retrospective based on how much time you have and what is the retrospective about. Each technique has a description of how much time to set aside for it, how to facilitate it and where its place is the overall sequence of a retrospective.

Great help, since classic “what we did well? what we didn’t do well?” etc. becomes boring pretty quickly. Anyone who facilitates retrospectives on a regular basis should have this book.

[1]original question.