Friday, December 02, 2011

How hard do you work for your employees?

Do you work hard for your employees? Do you invest in them? Do you address their needs even before they complain about them? Or do you pretty much ignore them until they complain loud enough to be annoying? Are they resources or people to you?

I have seen many organisations with management who expect a great deal from their employees in the form of dedication, motivation, engagement, etc. but which fail to put any effort at all into improving the daily life of their employees. If even the smallest improvements in your working conditions are a battle, if your company merely points to even worse employers when you ask for a bigger screen or a height adjustable table, why should you then do more than the bare minimum for your employer? If, on the other hand, your employer really invests in it's staff. If they show that they truly value their employees and want to ensure they have the best possible working conditions, would you not then also be prepared to go that extra mile?

Your employees stare at their computer screens 8 hours ever day, why would you not give them the best screens possible and reduce the risk for permanent sight problems as much as you can? Sure, if your company is struggling financially it may not have the cash for everyone to have a height adjustable table, and I am sure your employees would understand this. But, if your company has a healthy profit-margin, if it is growing and expanding, then why would it not be wise to invest in it's most valuable resource - it's staff?

I see too much time spent on demanding more from company employees and too little time truly investing in them and making the workplace as enjoyable and creative a place as possible. I have never seen a craftsman with cheaper tools than a normal hobby builder would have at home, but many developers that I know personally work in very profitable companies and have much better equipment at home than on their desks at work (and they haven't bought strange or exotic hardware but just went to their local Apple store). This is shameful and an embarrassment to our industry.

If we want our employees show loyalty, commitment, creativity and to really be prepared to walk that extra mile then we need them to love working where they are. To make them love their job or their company then you have to be prepared to invest in them, even when it isn't absolutely necessary. You have to show your employees that you truly value them as people and that you, too, are willing to make a commitment to them. A commitment to give them the best possible working conditions that you can. A commitment to involve them in decisions that have an effect on their daily lives. A commitment to see them as people and not resources.

An example of great offices: ATG offices in Solvalla, Sweden
© Jason Strong (courtesy of Note Design Studio)
An example of great offices: ATG offices in Solvalla, Sweden
© Jason Strong (courtesy of Note Design Studio)
An example of great offices: ATG offices in Solvalla, Sweden
© Jason Strong (courtesy of Note Design Studio)

Monday, November 21, 2011

Visualising your technical debt

For non developers:

Technical debt is an expression for the increasing level of difficulty a developer will have to introduce a desired change in the codebase. It encompasses lengthening estimates, increased unpredictability, increased number of side-effects, increased levels of developer fear, etc.
There are several reasons you might want to visualise your technical debt. I have tried to summarize them below:

  • Premise one:  You are a developer, and;
    • Parts of your code suck.
    • You don't want your code to suck as much as it does.
    • You have to convince someone that doesn't understand code to allow you to invest time in making it less sucky, or you just want to compare the suckiness of your code at two points in time.
  • Premise two: You are a code-illiterate manager who wants to know how sucky your code is.

So, how can you visualise the debt you have built up? Well, as debt is composed of various things such as the average cyclomatic complexity of your methods,  the average method length, test coverage, etc. etc. then you should be able to calculate these metrics and then combine them somehow to get some figures which you can then plot on a graph. And guess what? You can! Eric Dörnenburg has, with others, done some amazing work on Toxicity Charts and Tree Maps.
Figure 1: Example of a Tree Map. (Green is good, dark red is bad)
Figure 2: Example of a Toxicity Chart. (Short columns are good)
Using these visual aids even managers with no understanding of code can see where problem areas are in the code base and also compare the code base from one point in time to another. But they can also be useful visual aids within you team.

To find out more about these visualisation methods check out Erik's blog article and his excellent presentation of Software Quality - you know it when you see it.

Friday, November 18, 2011

What we can learn from the Swedes.

If you have your head in the clouds you'll keep tripping over pebbles. If you are only looking out for pebbles you'll lose your way. You have to watch the horizon without losing focus on here and now to make sure that you are going in the right direction without tripping over forgotten details.

The same is true in almost all aspects of software development - be it the technical development environments, the project process, documentations, testing, whatever... You have to make sure that you are not just fighting fires all the time but at the same time you can't ignore the smoldering embers you have or a fire might just break out. You have to maintain the situation while at the same time looking forwards and making sure that everything you do carries you further towards (and not away from) your goals.

Thinking about this subject reminded me of the Swedish word "lagom". As any Swede will proudly tell you this word does not have an exact translation in most other languages. It means something like: "just right", or "exactly enough, not too much nor too little." It is often used to refer to having the perfect amount of something and may be replaced by a combination of "in moderation", "in balance", "optimal" and "suitable". In software development we use the concept of lagom very often. It is, I would claim, the aim of us to be "lagom" in our planning, design, maintenance, all forms of testing and system documentation.

In nearly everything I do at work I have this concept of "lagom" to successfully steer my thinking. It is a wonderful concept and is extraordinarily helpful in everything from strategic planning to day to day operations.

And, as with all things Swedish it can be used wonderfully sarcastically such as in the phrase "lagom fun", to describe something that really wasn't that much fun at all (you can't really have too much fun).

Tuesday, November 15, 2011

Creating an #agile mindset

Mindset is a book by Carol Dweck. 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".

So, from now on I am trying to remember to give specific, non-generic, praise! (I have been trying this at home with my one year old and it's a lot harder than it seems!)

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

Technical Excellence

Here's a very basic first introduction to the concept of Technical Excellence. It covers the basic concepts:
  • What obstacles to achieving technical excellence exist for developers. 
  • What are non-functional requirements.
  • What is technical debt, why is it bad and how can you measure and visualize it.
  • And what are the practices you can use to encourage and foster technical excellence.
Unfortunately, I tend to talk a lot in my presentations so there isn't so much text but perhaps it's a useful introduction to the subject for someone.

Here's a link to the presentation for those of you unable to see the embedded version.

Thursday, November 03, 2011

What's more important than retrospectives?

I was recently asked what I thought the most important thing was that a new team should focus on in their Scrum process. Was it the backlog? Or the sprint planning meeting? Or was it the retrospective? I thought about this for a little while and realised that these were all process-related. Yes they are important but they are still just tools. We should focus on the mechanic not her tools. People are the most important focus for a new team. As stated in the Agile Manifestos "People over Processes". Here's why:

First you need clear leadership. Not control or micro-management but 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. Commitment to some common set of goals is crucial. This commitment is, in my opinion, the single most important success factor - though I doubt if it's relevant to talk about single most important success factors for complex adaptive systems - so lets call it a critically important constraint instead. Unfortunately, this is also the one thing I see lacking most in most struggling organisations/projects. Without the inspirational leadership, necessary for forming commitment in the team, then people will only half-heartedly try to solve the problems, technical and otherwise, that will appear as time goes on. Without this leadership they will have also difficulty building/maintaining the second part necessary for commitment:

Motivation is critical for building commitment and is closely tied to leadership. But they are not the same, I have seen situations where there is a highly motivated team which totally lacks leadership. I am a great believer that people are naturally motivated to do a good job, but the presence of de-motivators can erode or even remove this intrinsic motivation. Lack of inspirational leadership erodes motivation. As does; unexplained or seemingly arbitrary decisions, poor working environments, a culture of blame, etc. etc. The list of de-motivators is long and most organisations have some of them. Luckily, often we can cope with one or two of these, it is when an organisations collects de-motivators like stamps that things begin to get ugly, and it takes far far longer to build back motivation again. I have seen two main results of demotivated teams: Either the team loses it's team spirit or, even worse, the team's loyalty to the organisation or stakeholders is lost. They begin to see themselves as somehow victims in a kind of internal organisational struggle.

Finally, if you have leadership and a motivated team, you probably have the third critically important constraint; trust. 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.

Regardless of your development method if you have these then your team will perform well. People will then have the commitment necessary to overcome obstacles and to solve problems as and when they occur. Then, and only then, it is worth investing time and energy in improving process related things such as retrospectives and planning meetings. If you don't have commitment built upon inspirational leadership, motivation and trust then no amount of trimming your Scrum meetings will make a huge difference to the success of your project.

Monday, October 10, 2011

Designing your company to succeed

Everyone wants a successful company. However, in business school they still often teach a 19th or perhaps 20th century approach to management that simply doesn't work for knowledge workers. There are two main ways to design the system that is your company:

You can 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 noone 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 maximising 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 maximising their rewards. Talented individuals, being denied freedom and responsibility and being hampered by controlling bureaucracy leave, and employee turnover rises. 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 alternative is to focus 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-publicised 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.

Wednesday, September 28, 2011

A sense of urgency

I had a manager once - the CEO of the company I worked for at the time - who constantly nagged me to create a sense of urgency within my organisation. Unfortunately I didn't fully understand what he meant at the time, I thought he wanted me to whip the developers into working harder. Maybe he did. Perhaps he didn't understand that we already had this, or perhaps he was just afraid it would be lost. Working in an organisation now that has no sense of urgency I understand why he considered it so vital to ensure that everyone felt the urgency he felt.

On this theme I recently read the following excellent quote by Michael Dubakov, founder and CEO of Taget Process (my favourite Agile tool).

"Everyone should clearly understand what are we doing, why are we doing this, and why is it important at this very moment." - @mdubakov

I think it is that last part that most companies fail in communicating; "why it is important at this very moment". Here in lies a sense that tomorrow may be too late. But at the same time a sense that someone, somewhere in the company, has a plan - a damned good one - and now everything depends upon our ability to deliver. A sense of urgency. A sense that what you do today really matters.

Tuesday, September 27, 2011

Schneider's Culture Model and Agile

Schneider's Culture Model is like all models flawed. However, I think it still tells us something of value about the organisation we are looking at or attempting to change. If you look at figure 1 below you should be able to map your company's footprint on the various quadrants. How much focus do people put on the various areas? How much are they discussed? What attitudes do you notice?
Figure 1. Source:

Once you have mapped out your company and have an idea of the culture it might be interesting to look at figure 2 below and compare the two. Although some authors have stated that Kanban is a Control culture I believe that there exists an Agile Culture that is larger than Scrum or Kanban or whatever method you use. This culture is represented by figure 2 below. Of course one can implement any Agile method within, for example, a predominantly Control Culture. However, I believe that if your company is strongest in the Control quadrant it may be difficult to adopt agile values and therefore have a successful implementation (even if you use Kanban). unless you have a strong Agile Culture you will not gain the expected benefits, and ultimately may even have to abandon your Agile practices. 

Figure 2. Source:

Monday, September 26, 2011

The Democratization of Leadership

Many analysts have written about the role of social media in the ongoing democratization of the Arab nations. Most admit that social media have had an important role and aided communication and accelerated the process.

My thoughts turn to the latest trends in management and leadership and the impact of systems and complexity theory on social and organizational models. I have become convinced that the 20th century models of management and leadership are crumbling. I believe we are witnessing a democratization of leadership and management and I believe that social media is perhaps the single most important factor in this process.

Social media has made us aware (more than ever before) of our interdependency and interconnectedness, but also of our equality. There are no hierarchies in social networks only specialized roles. Networks where information flows freely and which have the ability to form themselves tend to last. Rigid non-adaptive ones die. A company can be viewed as a complex adaptive system and many recent books support this view. In the post 20th century economy the most successful companies are often the most adaptive ones, the most innovative ones. Thus old hierarchical models of leadership and management are proving to be too rigid and unresponsive and people are turning to alternative autonomous models. Along side of this process is an influx of workers who have grown up with social media and who are reluctant to position themselves at the bottom of a hierarchy, especially in industries such as IT. Just like in the Arab Spring they demand democracy and autonomy. Finally, research into complex social networks has begun to erode our deterministic "knowledge" of motivation and performance and replace it with complexity theories of emergence and self organization. This knowledge is just now seeping into the more open management organizations and will in time permeate even the most conservative companies.

Thus we have three forces all pushing in the same direction with a seemingly inevitable conclusion; the old hierarchical style of leadership, with bonuses and focus on the individual, is dying. I predict this will be replaced by leadership which cultivates peoples own innate desires to create something useful for society, sets clear goals and allows the employees to self organize and learn. In this organization todays management hierarchies will disappear to be replaced by coaches and specialized roles.

Sunday, September 25, 2011

The myth of autonomy

There's a lot of talk about autonomy these days. And, in my opinion, a lot of misunderstandings. People tend to confuse two terms - autonomy, and self organisation.

I hear managers saying autonomy does not work when they mean that self organisation has led to a culture of low productivity. And I hear developers and coaches saying autonomy is inevitable, when they mean self organisation cannot be avoided.

Teams may or may not be autonomous. Autonomous teams are allowed to make their own decisions and solve their own problems (incidentally teams learn most when allowed to solve their own problems). But even teams that completely lack autonomy are self organising; those with autonomy also have delegated authority to make their own conscious decisions. Self organisation is the unconscious ability of a system to learn and adapt and change. This self organisation is inevitable, you cannot stop it. You cannot even steer it as you are not the organiser; the team is. Even individual members of the team cannot steer this self organisation. All we can do is change the constraints, for example by changing the environment of the team and hope this has a positive effect on the team. An example of this is to provide clear and (by the team) accepted goals and the autonomy to choose the methods used to achieve these goals. Another is to give the team zero autonomy and to dictate how the team should achieve these goals. However, teams with zero autonomy will not solve their own problems and therefore will not grow and learn, at least not in the direction you want them to.

Thursday, September 22, 2011

Management 3.0

What I have learned these two days:
- I have good instincts.
- But I don't know everything!
- Some great practical games and exercises to help plan change.
- Some great practical games and exercises to expose assumptions.
- I missed some great books in this domain, damn!
- We have a good team at Xing.
- I should read more!
- I should write a book!
- Jurgen Appelo (@jurgenappelo) is a really good trainer. Very informative AND very entertaining.

Location:Kiev, Ukraine

Monday, September 19, 2011

Trust and change

Trust is crucial for any change process. Without trust our colleagues may comply with our requests for changed behavior but they wont be committed to the change. They wont be engaged, they wont drive the change and so, ultimately, we are unlikely to reap the expected benefits.

Building trust in an organisation takes time. Building trust takes commitment and effort. It takes leadership skills. You have to listen, truly listen, to your organisation and act on what they tell you. You have to have an inclusive leadership style and an openness about your decisions. All change in people comes from within. You can in an organisation, of course, force people to comply with a decision but they will often lose motivation or in extreme cases work actively agains the decision. The best way is always to include people in the decision process, be open about the objectives and causes and, based on previously earned trust, obtain their commitment to the change.

I think many organisations lack an understanding of the difference between compliance and commitment. Or they don't care. Perhaps they are too busy or perhaps the effort necessary for commitment seems too much. One can say the difference is the energy and enthusiasm people put into the change process. With the rate of change in business and society today all organisations are likely to go through a change process, and for a great many this is a constant state. How successful this process is can determine the future success of the company. Commitment is key and therefore by extension trust is key. And you cannot make your organisation trust you. To do this you have to show that you trust the organisation to do the best job they can. This means delegation, no micro management, the freedom to be autonomous, inclusion in important decisions and a sense of togetherness.

So, in summary, if you want to achieve meaningful change in your organisation you have to build up trust in order to obtain the necessary commitment. And this process requires leaders with leadership skills and not spreadsheet-wielding managers.

Friday, August 26, 2011

How Google makes improvements to its search algorithm - YouTube

Interesting insights. I especially liked the idea of real user sandboxes to test new ideas. I might suggest these at work!

Friday, August 19, 2011

Kaikaku and Kaizen

Kaikaku and Kaizen are concepts in Japanese production philosophy that relate to each other. Both have origins in the Toyota Production System. Kaizen, quite familiar to agile adopter and coaches, is continuous changes often focused within a certain area of a production system, with the primary goal of solving a specific set of problems.

Kaikaku means a radical change achieved during a limited time. Kaikaku is about introducing new knowledge, new strategies, new approaches, new production techniques or new equipment. Kaikaku can be initiated by external factors, e.g. new technology or market conditions. Kaikaku can also be initiated when it is apparent that ongoing Kaizen work is beginning to stagnate and no longer provides adequate results in relation to the effort. Kaikaku projects often result in improvements in the range of 30-50% and a new base level for continued Kaizen. Kaikaku may also be called System Kaizen.

10 Kaikaku Commandments
By: Hiroyuki Hirano
  1. Throw out the traditional concept of manufacturing methods.
  2. Think about how the new method will work, not how it won't work.
  3. Don't accept excuses; totally deny the status quo.
  4. Don't seek perfection; a 50% implementation rate is fine as long as it's done on the spot.
  5. Correct mistakes the moment they are found.
  6. Don't spend money on Kaikaku.
  7. Problems give you a chance to use your brains.
  8. Ask "Why" five times.
  9. Ten person's ideas are better than one person's knowledge.
  10. Kaikaku knows no limits.

Tuesday, August 02, 2011

The myth of the genius programmer

From 2009 but still as relevant today. If you haven't yet watched this presentation then it's time you did!

Friday, July 22, 2011

Personal conflicts and feedback

Solving personal conflicts and giving constructive but personal feedback are two of the hardest parts of being an Agile Coach. I usually say that most problems are quite easy to solve once identified, but personal conflicts and issues between team members can be very difficult and require great creativity to solve.

Two great blog posts on this subject are:

Handling a team member who talks too much which uses the ladder of inference technique, and this post on creating the preconditions for constructive discussions

It is also extremely important to focus on the behaviour not on the individual. A persons actions are not who they are and you shouldn't assume to know the persons attitudes or reasons for the exhibited behaviour. Dominance, for example, usually turns out to be a sign of insecurity. You may find that building the persons confidence with positive feedback and encouragement (often counter-intuitive when dealing with a dominant person) will accomplish just the change in behaviour you are looking for.

Be concrete in your examples, cite specific instances but nothing more than 4-6 weeks in the past. Remind the participants of the situation and then state how this situation made YOU feel. Do not judge or criticise, merely explain how this behaviour affected you and what emotions you felt. Try to get the person to empathise with your feelings and situation and then ask them how they can help you to avoid this feeling in the future.

A talking stick is often useful when exploring an issue in a group as it allows people to talk through until they are finished without being interrupted. Always use an arbitrator - a neutral party - that can act as referee and make sure we stay constructive.

All coaches and managers should receive regular training in communication and conflict resolution. But the most important is that they maintain a neutral and non-judgemental attitude to all of the team members.

Thursday, July 21, 2011

The Kanban board

This is one of my favourite pictures of a Kanban board:

What is the function of a Kanban board?

Many people think it is too keep track of status. For example, I hear all the time teams say that it helps testers to know that a ticket is ready for test. No,  the daily stand-ups (and other verbal communication) are for this. Possibly a note on the ticket saying "test this" but even that I would disagree with. Testing should be an integral part of the development process. Developers should not hand-over a ticket to QA. QA should already be preparing the tests as soon as the tickets enters the team. QA is a parallel process to coding and is as much a part of development as programming code is.

It is my firm belief that the board should have two primary functions:

1. It gives the team an overview of everything, something easily lost in an iterative, ticket-based process. But to do this requires no more states than ready, ongoing, and done. This is important because we don't want to give the false impression that things are nearly done. We've all seen bugs surface at the "last minute" that increase development time by a large %. Using Lean as a guideline; stories/tickets have no value and are considered waste until they are done. Therefore the only important states are Ongoing and Done!

2. The Kanban board helps us to improve our process. Limiting WIPs and columns means problems create bottlenecks which slow us down short-term but force us to fix problems thus speeding up the process long-term. This is the principle from Lean that we fix our problems now, even if it means stopping production, because it is more expensive to fix them later. It is this drive to solve problems in the process that make Kanban an effective tool for improving the development process. Otherwise it's value is severely limited.

Tuesday, July 19, 2011

People are NOT resources.

I just read Ken Schwaber's latest blog post. I felt I just had to quote the following text which lies at the heart of everything I strive for in Agile implementations:
The new VS measures a person’s available capacity. You have to wonder. People don’t have measurable capacities when they are performing intellectual, creative work. Things move back and forth between different parts of the brain and some of the best ideas come at 2:00am in bed.  Scrum and XP are sneaky. A team of people sign up to solve problems within a Sprint. They are engaged in group problem-solving for the duration, and the problem never leaves some part of their brain. They are engaged. Brian’s comments and the consequent tooling reminds me of ideal days: a person is only working when his or her fingers are on the keyboard.
He made, of course, a lot of other good points and I recommend you to read his post.

Monday, July 18, 2011

Encourage failure

The best way to improve a complex system is by trial and error. Don't just take my word for it; watch this Ted Talk presentation by Tim Harford, or this TEDxEutropolis talk by Paul Ilske. Of course, if you use trial and error then you have to accept failure. Not all of your changes will turn out to be improvements. It is equally important to learn what NOT to do as to learn what you SHOULD do. In fact, Thomas Edison once said when he was reminded how many failed experiments it took him to build a functioning light bulb: "I haven't failed, I now know over 300 ways NOT to build a light bulb".

Too many organisations have an explicit or implicit dislike for failure. In business development organisations this is even more common than in software development organisations. This fear of failure leads to stagnation and playing it safe and I think is one of the primary reasons great start-ups lose that dynamic and explosive feeling. At the beginning you have nothing to lose and therefore experimentation (and therefore failure) is more acceptable. But as the business grows so the organisation becomes more afraid of failure and more conservative. Trial and error are no longer acceptable. It is no longer enough to say "I have this great idea I'd like to try out", you now have to provide days of analysis work, risk assessments, etc. etc. and above all be absolutely sure that it will not fail!

Instead of focusing on how to prevent failure, organisations should focus on ways to evaluate the results of changes. We need to be able to assess if a change was an improvement or not. If it was an improvement we want to keep doing it, or even better build upon it. If it wasn't an improvement then we want to go back to the previous successful state. This process should be simple and there should be tools and metrics in place that allow us to make this evaluation. There needs also to be a culture that allows us to make changes and more importantly to reverse our changes in a positive way. There should be no negative stigma in discovering a path of development we shouldn't take, be it in our process or our product.

I think this is one of the drivers as to why Fed Ex days, innovation days, and other such initiatives work so well; they allow experimentation. And through experimentation we learn and improve, because we are hard-wired to learn this way. We are hard-wired to learn through trial and error how to walk and talk. When children play they are constantly experimenting. So why, when we become adults is experimentation suddenly taboo? Why must every change succeed? Food for thought I think...

Monday, July 11, 2011

Continuous improvement

While I would define Agile development as something along the lines of "Delivering the most business value with the least effort" a lot of what Agile is about is continuous improvement. Small incremental improvements done over a period of time that lead to a large improvement in efficiency and effectiveness.

My new job has given me cause to ponder this. Most of my Agile career I have dealt with organisations at the beginning of this process. Organisations implementing Agile or wanting to improve it due to some problems. Now, I find myself in a relatively mature Agile organisation where my team has been practicing Kanban for some two years or so. However, compared to other organisations I have met my teams process could be considered rather sloppy and immature. This has ledd me to ponder the possible causes and my money is on some kind of change friction. Just like a ball rolling will eventually roll to a halt so has the continuous improvement process in my team slowed down to zero. In fact, I would go as far as to say it has gone backwards slightly. The team has shrunk with no change to the WIPs resulting in a large amount of parallelism and the expected lack of focus. The stand-ups are tired and bored (at least that is my feeling) and certainly not indicative of a energetic focused team in a mature phase of Agile implementation. I believe that my team are simply tired of constantly looking for improvements. They have reached a phase where they think everything works pretty well and see no real gains in changing things from where they are. Has anyone else seen this effect? I am now thinking about how to broach this subject at the upcoming retrospective. Anyone got any ideas?

Wednesday, July 06, 2011

Teams of 3-4 members gives optimum productivity and team development.

I just read a very interesting study on group size vs performance. According to this study we really should always aim to be working in groups of 3-4 members and not the 5-9 that is typically quoted.
This research investigated the impact of small and large work groups on developmental processes and group productivity. There were 329 work groups operating in for-profit and nonprofit organizations across the United States in this study. Groups containing 3 to 8 members were significantly more productive and more developmentally advanced than groups with 9 members or more. Groups containing 3 to 6 members were significantly more productive and more developmentally advanced than groups with 7 to 10 members or 11 members or more. The groups with 7 to 10 members or 11 members were not different from each other. Finally, groups containing 3 to 4 members were significantly more productive and more developmentally advanced on a number of measures than groups with 5 to 6 members. Work-group size is a crucial factor in increasing or decreasing both group development and productivity.

Saturday, June 25, 2011

Agile adoption is not just about sprints and user stories.

I've been involved in several agile implementations where the company's management have failed to see the widespread implications of an agile adoption. Agile isn't just about the development process, it's a value system, a way of thinking, and as such it affects many areas of the company. Management should support and promote these changes but unfortunately are all too commonly not even aware that this will happen. Today I'd like to focus briefly on three of these areas: project management, rewards, and talent management.

One really obvious area is project management and "resource allocation". By the way, I hate the term "resource allocation" as it's people we are talking about. The attitude of thinking about developers in the same way as $$ signs is why many companies are so unproductive. If an agile adoption is to succeed and mature then all the management tools must also be agile ones. It's no good trying to follow up an agile project with old projects management tools. Key indicators, milestones, etc. all have to be in an agile form. And be aware - you change what you measure! That is to say the behavior of your teams will change depending upon the measurements and key indicators you use so try to keep these to a minimum and select the things you think need improvement.

Rewards are another area that is heavily impacted by an agile adoption but which all too many companies forget. We seek now to reward new types of behavior. Previously the employees that followed the agreed process and were reliable were rewarded. However, now it should be the employees that think critically and creatively. That aren't satisfied with the status quo and who always seek to improve the tools and methods used. We should also seek to change our methods of rewards, expected if-then rewards do not function as expected and should be replaced by direct and peer related rewards. Allowing the employees to distribute rewards has two effects: it increases the amount of positive feedback in the organization which will improve moral and productivity enormously, and it makes sure that the right employees and behaviors are rewarded.

Talent management is also something that a company adopting agile should be thinking about. Talent should be cultivated and invested in and this requires processes and training. All too often companies employ talented individuals only to then leave them sitting in their teams with no kind of talent management or cultivation. After several years of neglect these individuals will either have lost all of their talent or left the company!

Agile adoption is an adoption of values and thought patterns and therefore will spread and affect many areas of the company. If the management do not sufficiently understand the value systems behind agile, or simply do not promote these sufficiently then they run the risk of damaging their agile implementation.

Thursday, June 09, 2011

Poll: why projects fail?

New job new challenges

So much of my perspective is dependent upon the projects I have and the problems I am struggling to solve within them. Hopefully, challenging projects give me brief insights into previously hidden relationships - which I can then take with me and use to expand my understanding.

I am about to swap jobs, and countries. So, now I sit here wondering how my new role and assignments will affect my perspective. How the culture in my new company will change my position on certain issues. It will be interesting in a year or so to go back and read my blog posts and see if I still agree with myself.

Ubiquitously Apple

So, Apple launched iCloud which is to be a central feature in iOS5 and Lion. And it's really gotten me excited, not that my PC hugging friends can understand why, after all there's nothing actually new about iCloud. Or is there? Basically you can summarise Apples solution as being ubiquitous. It's there all the time in the background or as Steve Jobs put it "it just works".

In order to accomplish the same thing in a PC environment you'll have to download, install and configure a bunch of software. Hardly the same experience. And that's what the PC geeks miss - Apple is all about the experience. On paper Apple's platform provides perhaps no better functionality than any other platform. However in the real world, where ease of use is king, the experience is quite different. It's the experience that I buy. It's the experience that adds value. And, in the end, it's the experience that gets ordinary people to use a product or service.

Until iCloud came along syncing the many kinds of information on all of my devices was a nightmare. It took effort and knowledge and time spent Googling for answers and products, and it still didn't work 100%. Now it looks as though Apple have solved this and that this will all happen in the background, as if by magic, ubiquitously, just the way I want it to happen.

Wednesday, June 01, 2011

Getting things done

One of the toughest challenges in any organisation, regardless of methods and processes, can be converting knowledge or intentions into actions. Sometimes organisations, or rather the people that make up them, appear paralysed - like rabbits in the middle of the road staring at the headlights whilst frozen in place. In fact, I think that one of the main components of my job is helping organisations move from thought to actions. There's probably just as many causes for this inaction as there are people but I think they can broadly be placed into several categories:

Fear of reprisals.
Organisations that punish mistakes end up stagnating as the only way to avoid making mistakes is to do nothing. People are very adaptive and tend to "game" any system to their own advantage. If those that make a mistake are seen to miss out on promotions, pay rises or future assignments then people will spot this very quickly and react accordingly. This isn't always easy to avoid - if you are a manager do you really want to give challenging assignments to people that have previously failed? I think the solution here is to give people assignments that challenge them, and that have an inherent risk of failure, but which are at a level of difficulty suitable for the employee and level of their experience/skills. And, of course, to remember that to err is human.

Fear of failure. 
Some individuals have a built-in fear of failure. Regardless of the organisation they work within they have - based on prior experience - learned to avoid failure at all costs. This prior experience can be a previous organisation or even their childhood experience. It is important for managers to spot these people and to coach and develop them allowing them to relearn and break this behaviour pattern.

Illogical hope.
It is not only fear that can cause inaction. Some organisations face problems by maintaining some kind of illogical hope. In the face of seemingly insurmountable problems they react by burying their heads in sand and hoping that the problem will somehow go away all by itself. Of course, usually, the problem tends to just get larger and more difficult to solve. Encouraging a culture of communicating transparently and giving honest status updates goes a long way to helping guard against this. It's harder to ignore a problem you have to give updates and reports about than one nobody talks about.

A feeling of despair or hopelessness.
Some problems seem so large, so insurmountable, that we lose al l motivation and drive to solve them. We don't know where to begin and cannot comprehend a solution to the whole problem. I think an important solution here is to encourage baby-steps. That is instead of trying to solve the problem completely we should try to find some small activity that we can do to start to improve the situation or to solve a part of the problem. By breaking the problem down into bite size pieces we can remove a feeling of hopelessness and see real progress which gives vital positive feedback.

Whatever the cause, getting people to take that first step can be frustratingly difficult at times. I can certainly feel that my creativity, my drive, my enthusiasm and my teaching abilities are all pushed to their very limits and wonder on occasion why I didn't pick an easier job. However, the buzz of helping an organisation or team achieve real change and real goals is a hard habit to kick.

Tuesday, May 31, 2011


Great quote by Daniel Pink:
"Relying on 'if-then' rewards to encourage great work is like guzzling six cups of coffee and downing three Snickers bars for lunch. It’ll give you a burst of energy – but the effects won’t last."

Monday, May 30, 2011

Thoughts on Aspergers.

Asperger's syndrome is one of the disorders on the autistic spectrum - a milder form of the condition that afflicted Raymond Babbitt, the character played by Dustin Hoffman in Rain Man. Those diagnosed with Asperger's syndrome often have high, or very high, IQs.

Many programmers exhibit Aspergers-like behaviour. Aspergers syndrome can involve an intense and obsessive level of focus on things of interest - which is in my experience widespread in this industry. I would perhaps go as far as to say that it is possibly an advantage if you have ambitions to be a great programmer. It is I would think a lot easier for someone with Aspergers tendencies to find the motivation to spend the required number of hours reading highly technical literature. Literal interpretation is another common (but not universal) hallmark of Aspergers. For many years I simply thought this was a side-affect of working in a so binary world, now I wonder if it is simply that the controlled, binary, world of computers attracts people who would score highly on an Aspergers diagnosis.

I wonder also what the industry would look like if it were possible to "cure" Aspergers. I've seen several blogs claiming that in the post-agile software industry with it's focus on teamwork and cooperation there is only limited space for this type of programmer. However, I would disagree. I do not believe that it is impossible to be a sufferer of Aspergers and still have good social competence. My main example for this belief is myself. I am usually described as a individual with good social skills and an extrovert and communicative person. However, I recently took an online test with a battery of questions aimed at typical Aspergers behaviour. Although not a diagnosis the test gave an interesting result. An average person in a control group had a score of 16 whilst a majority of those with an Aspergers diagnosis scored 32 or more. My score was 34. Just as dyslectics can learn to read so can those with Asperger tendencies learn to interact in an increasingly social industry - it may require more effort that it does for other types of individuals but it is possible.

I think, ultimately, it depends upon who decides what is functional or what is normal? Hans Asperger, who first identified the condition, wrote that to be successful in science an amount of autism is essential. Is Aspergers simply a medical definition of being a nerd?

Tuesday, May 24, 2011

Cultivate a culture of talent rather than control

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 why some people perform and others don't. About what you can do to improve the situation and what you can't change. This led to me writing a blog post about talent that unfortunately Google decided to lose in their crash. While not the same blog post (I was especially happy with the original post) this one will address the same issues...

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. Based on my experience I am beginning to doubt this.

Too many companies are too focussed on delivering upon given promisses, too many developers too focussed on avoiding blame or following a plan to think creatively. We live in a world of 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. If we would spend less time making plans and then sticking to them in all weathers, less time chasing our developers and interrogating them as to why they didn't deliver exactly within their estimate (how can you estimate how long it takes to solve a problem?). If we would give the teams the responsibility for the quality of the code that they produce, instead of pushing them to work harder faster longer, then we would create better systems with more maintainable code. We would have enthusiastic developers hungry to learn more. We would have created a culture of talent.

If we cultivate a culture of initiative, freedom and creativity, if managers invest in their developers instead of trying to manage and control them, if we create an environment with clear goals and expectations and the freedom and trust for our teams to reach those goals in their own way, then I am convinced that we can give the vast majority of developers the drive and the enthusiasm to become talented developers.
In summary, I believe that developers can move freely between the two categories given the right (or the wrong) work situation. I'm not saying it is easy to create a culture of talent - it requires investment by the company and commitment by the managers, but it is possible and it is worth it.

Friday, May 06, 2011

Autonomy, mastery and purpose

It was a while ago now that I read Daniel Pink’s book “Drive” but it is so good that it deserves a mention. This is a book that everyone working to raise employee/team productivity in some form should read. It summarizes forty years of scientific research and the consequences are far reaching for Managers, team leads, scrum masters, coaches, or anyone else working with organisational structures, reward systems, personnel strategies, productivity, recruitment, etc.
Basically, human beings are motivated to perform complex cognitive activities by three intrinsic drives: 
  • Autonomy; the desire to be self-organising and to structure one’s own situation.
  • Mastery; the desire to become better at an activity, to learn and understand a knowledge domain.
  • Purpose; the desire to contribute to a greater cause, to do something profound, to impact other peoples lives in some way. 
It is these three intrinsic drives and not the traditional extrinsic drive of monetary reward that are the most powerful motivators. However, if our expectations of fair and reasonable extrinsic rewards are not met this can have a devastating negative effect on our performance. Surprisingly, expected monetary rewards can even decrease our motivation in complex cognitive tasks to a point where we perform worse than we would have with no reward!

All-in-all a very interesting read and a great source of inspiration!