Monday, January 23, 2012

Hunter-gatherers, play & software development

Work does not have to be toil, it can be play.

I recently read the article Play Makes Us Human V: Why Hunter-Gatherers' Work is Play by Peter Gray. Since then I have been reflecting upon what his findings mean for the modern software development workplace.

In our most primitive societies, hunter gatherer societies, play is extraordinarily important. Work is simply an extension of play and the societies have no real concept of toil (or negative unenjoyable work). Work (which in their case is hunting or gathering) is comprised of optional and  collaborative ventures that involve mastery and purpose and a large degree of autonomy. They get no reward for this work other than the product of the work itself which they freely divide amongst the whole group. Their behavior really reminds me a lot of open source projects. In both open source projects and hunter gatherer societies, people are free to choose what projects to work on based on alignment with the larger goals of the project and the opportunity to practise and develop their skills. So, how can this knowledge be used to create a modern workplace which best matches our species predispositions?

Work should be play not toil. I think both employers and educationalists could learn a lot simply by contemplating this simple statement. As much as possible (and in the case of software development this is to a very large degree) work should be organized so as to minimize toil thus maximizing the sensation of play.

Developers should be encouraged to a large degree to make their own tools. If they need to automate something, or if they need to improve something they should be free to do this. They should be free to experiment and to constantly seek improvements. They should own their environment which will then make sure it is enabling for them and not restrictive.

Work should be collaborative. Hunters hunt in packs and humans still perform best when working in groups and not when isolated in small cubicles.

Work should to a large degree be optional. If it is possible make it optional to take part in a given project. If this is not possible at least make the distribution of work a matter for the teams themselves and thus make the actual work done by each developer optional.

This article gave me another perspective on why the practices and values I use and promote have worked in the situations I have seen. I think there is a strong alignment in the principles of people-focused organisations, management 3.0, agile development, etc. and the organisation of work in hunter-gatherer societies.

Friday, January 13, 2012

Agile culture is a culture of learning and growth, built on trust.

This is a re-write and summary of some of my other posts which I wrote for the ALE book project which seems not to be going anywhere just now. I recently re-read it and think it is a nice summary of several of last years blog posts and could therefore be interesting either as an introduction to my ideas or as a summary of them. Enjoy.

I work with productivity. It's what most agile coaches do; we try to create an environment that empowers teams and makes them as productive as possible. To do this you have to think an awful lot about motivation and psychology. About the cultures where people perform and and the cultures where they don't.

One can, in the software development industry, often get the impression that there are two types of developers. One category, the average developers, do their jobs well-enough but they lack that extra drive and talent to make them truly great programmers. The other category read all the blogs and books they can, know several programming languages, and have a constant hobby project or two that fills their free time. Most people who have worked in the industry an length of time will tell you to hire all of the talented developers you can as they are much more productive than the average developers. This is based upon the assumption that talent is something innate and unchanging.

Mindset is a book by Carol Dweck that challenges this view. In it she talks about "fixed" and "growth" mindsets. These mindsets are created in childhood and affect performance and attitudes to an astonishing degree. Even organisations can possess and propagate these "mindsets". The fixed mindset believes that our abilities are more or less fixed and we can do little to change this - some people are just more talented than others. The growth mindset believes that our abilities can be developed and grown, given the correct stimulus, and that talent can be developed over time.

These beliefs lead to two basic problem solving mindsets: The fixed mindset sees problems as opportunities to showcase one's abilities, whilst the growth mindset regards problems as opportunities to learn and grow. Needless to say people and organisations with the growth mindset consistently out-perform those with the fixed one. Luckily for us we can change our (and others) mindsets moving us (or our organisation) from a fixed to a growth mindset.

Apparently, generic praise leads to a fixed mindset, which is demotivating in the long term. According to her research, people with a fixed mindset consistently avoid more difficult tasks (when given the choice) and were even prone to lie about their performance. Non-generic praise leads instead to a growth mindset and increased performance. Unfortunately, the differences in generic and non-generic praise are subtle and mistakes are easy. In the case of children Carol gives the examples; "you are a really good painter" (an example of generic praise which will lead to a fixed mindset) and "that painting is really good" (an example of non-generic or specific praise which will lead to a growth mindset). An example for those of us in development organisations might be: instead of; "Thanks Eric, you are a great developer", we should be using; "Thanks Eric, you did a great job on that task/task x".

You can find out more about the book or buy it at and learn about her other project at

So, where does this talk of mindsets take us? If we cultivate a culture of learning and creativity, if managers invest in their developers instead of trying to rate them and control them then we can give the vast majority of developers the drive and the enthusiasm to become talented developers. But we have to motivate them, we have to give them leadership. Unfortunately, in business school they still often teach a 19th or perhaps 20th century approach to management and leadership that simply doesn't work for knowledge workers. There seem to me to be two main cultures of management alive in companies today:

There are those that focus on extrinsic rewards - Salary/rewards are directly coupled to performance. Motivation becomes an issue as research has shown that something people get paid for is not as motivating as something people do for the love of it, regardless of how motivating it was to begin with. The extrinsic rewards undermine peoples intrinsic motivation. The managers job is now to try to raise performance, weed out the lazy and reward the hardworking. They have little time to think about improvements to the system. A culture of apathy and resignation emerges amongst the employees as no-one wants to take risks and makes mistakes when it affects their rewards/salary. As a reaction to this a culture of control emerges in management as they focus on trying to counteract the apathy spreading through the employees and focus on maximizing employee performance. The management view of employees becomes one of distrust; people do not work hard unless monitored and controlled. Unfortunately, within this pairing of company cultures this becomes a self-fulfilling prophecy; the employees merely comply with the increasingly bureaucratic guidelines and goals. People learn to game the system to do as little as possible whilst maximizing their rewards. Talented individuals, being denied freedom and responsibility and being hampered by controlling bureaucracy leave, and employee turnover rises. These companies are too focused on delivering upon given promises, their developers too focused on avoiding blame or following a plan to think creatively. Depending upon the business model, competition, etc. the company may or may not be profitable. But it will not have a high performing, committed, workforce and will be vulnerable to outside competition.

The second group focus instead on intrinsic rewards - Here, there is no direct connection between performance and salary. Everyone is paid very well for their knowledge and experience and so they do not need to think about how to get a higher salary or better rewards. People work as hard as they can and do their best without supervision, based upon their own intrinsic motivation. The manager's job is to create a healthy and motivating environment by setting clear goals and eliminating obstacles for their teams. Well-publicized and transparent career ladders allow for salary progression as one gains experience/competence. The employees attach and own the overall goals of the company and use these as guidance in all situations. Everyone is committed and employee involvement leads to high productivity and low employee turnover. The success of the company is still dependent upon the overall business model but if there is any way to make this succeed the workforce will find it. Obviously I, and many others, support the second strategy above. I believe that this is the beginning of a new 21st century view of management and motivation.

To succeed with any difficult endeavor you need inspirational leadership. The team (not to mention everyone else) has to have a clear understanding of the goals and they have to have committed to these. Within the software development industry we live in a world of complex problem solving, this world is not deterministic and is seldom entirely predictable and creative thinking is the key to good problem solving and therefore the key to building great systems, but we still need guidance when making decisions on a daily basis. We need a set of common goals to guide us and commitment to this common set of goals is crucial. This commitment is, in my opinion, a critically important constraint and it is built on a foundation of trust.

Without trust you cannot have open communication. Without trust you will develop a culture of blame. Trust is vital on a bunch of different levels; between team members, between the team and management, from management towards the team, etc. etc. Trust ensures open and honest communication, without which any project involving human beings will have a high risk of failure. Trust ensures that problems are raised, and therefore addressed, early on. Trust ensures that retrospectives are open and blameless, a prerequisite for successful retrospectives. Trust between team members is vital for the transition of a group to a team and the growth of team spirit. Trust toward management is vital in building commitment to the goals and, finally, trust from management - that the team will do their best and don't require micro-management or control, and that they should be allowed to solve their own problems - is vital in all Agile projects.

So, finally, if we have inspirational leadership and motivated teams with an agile mindset and a whole bunch of trust then we have a bunch of enthusiastic people hungry to learn. Regardless of our development method if we have a learning culture then our team will perform well. People will then have the commitment and skills necessary to overcome obstacles and to solve problems as and when they occur. We have created a culture of talent development, where we are constantly learning and growing, in short, we will have created an agile culture.

Monday, January 09, 2012

#stoos and boat building

I was discussing the various blog posts and feedback from #stoos with my friend and colleague @bjoernlinder and I realized that they seem to be pursuing a different strategy than I would have used. To describe this I would like to use the metaphor of boat building:

Let's say we have come up with a much better way to build boats. We see everyone else sailing around in what we think are really crappy boats and we have an idea about how to build boats better. So what do we do? Do we try to evangelize about our fantastic boat idea and try to get everyone else to build our fantastic new boat design instead of their own? No, we don't. We do not do this because it will have little chance of success. What we decide to do is to find a sympathetic boat builder that we can convince to do an experiment; to build one of our fantastic boats for us. Once our fantastic boat is built and sailing and everyone can see that it out-performs all the other boats then the boat builders will naturally want to use our design and convincing them will no longer be a problem!

So how does this relate to our problem and #stoos?
I have been eagerly reading the various feedback and blog posts from #stoos and am struck by the seemingly theoretical nature of the output. For example, we have now a list of stakeholders. We already know the stakeholders, any one of us could have sat down in a room and written that! We might not agree 100% on the order of importance but who cares? These details are not important. We are discussing evangelizing about our ideas when what we need are examples, activities, best practices, and above all PROOF.

What I believe we should do is find some companies where we have influence that we can convince to do some experiments. Once we have a bunch of successful companies using the values and principles which we are wanting to promote, and which perform better than traditional companies and once we have some data and facts about this improvement, THEN it will be much easier to convince other companies to follow suit.

What we need are some experiments and some data and then we need to write a book documenting this and then we can change the world. Or, at least, this is what I would do.