TechBiz


A theme that I see repeatedly in companies I work with is that they boast how innovative they are. Usually that means their managers demand from their staff to be innovative. At the same time, however, they remind everyone that deadlines have to be met and all has to delivered – and it has to be done! In other words, they make it very clear that there is no room for mistakes and everything has to be done as planned (or, more frequently, as it was already promised to clients by sales). Then they wonder why they get little real innovation – the most obvious answer being that their employees are stupid, because Google scooped “all the good ones” from the market and so we, poor managers, have to do with these lazy retards. How wrong!

Innovation is, by definition, trying new ways of doing things that have not been tried before. If you look at it from this angle it is obvious that more often than not this must end up in a failure. Most things no one tried before are not good ideas – only a few are, but you won’t know it until you try them. And even if you stumble on a really good idea it will need a lot of perfecting and improving before it will be a useful product. “The devil is in the details” – so this process will also involve a lot of failures.

Therefore, in order to have innovation you must make ample room for failure. That means you have to make it safe for people working for you to try new things. They have to know that if they try something new and it won’t work they will praised for trying rather than punished for failing. That is what “investment in innovation” really means. It is not about creating an “innovation department” or buying new hardware or “managing innovation”, it is about being ready to pay for things that very likely will get thrown away.

Someone may ask: what if we can’t afford it? What if we don’t have money to spend on things that won’t work? Then you can always be at least honest with your people (which is always a good idea anyway) and tell them: don’t try new ways of doing things, lets stick to what we know will work, because we have very little room for maneuver this year/quarter/whatever. They will understand. And you will not fool yourself you are “innovating” when you can’t.

But does it really take that much investment in terms of cash to foster innovation? I don’t think so, but this is a topic for a separate post.

The most common complaint I hear from developers is that their managers push unrealistic deadlines on them. The managers come and say something must by done by this date – and won’t take “no” for an answer. The developers then work nights to deliver on a promise they didn’t make – usually only to get more features added two weeks before the deadline.

This is a fair complaint, the only problem I have with it is that the developers generally deliver. The managers in the end do get what they asked for – at least it looks so on the surface. No wonder they come again and do the same thing. Their whole experience tells them this is how things work and many of them genuinely believe they act correctly by pushing unrealistic deadlines on their subordinates (known under a number of euphemisms like “challenging workers” or “driving folks hard”). How are they supposed to know this is achieved by degrading quality of the end product? Usually they lack knowledge and time to thoroughly check the product and many ill effects of poor craftsmanship in software take months if not years to become painfully visible (technical debt).

In other words developers just train their managers in dysfunctional behaviors, over and over again confirming their experience that those behaviors will produce desired outcomes.

So, if you are a developer: yes, your boss is probably a moron and yes, he demands stupid things – but it is also you who trained him that way by delivering those things. No wonder he comes for more. It is a vicious cycle. Want to break out of it? You have three options available to you:

  • keep on doing the same thing – write poor code, quick hacks upon hacks, with no tests under pressure just to keep unrealistic deadlines and occasionally complain out of your boss’ earshot to other developers or a passing trainer/coach/consultant hoping in wain things will change on their own,
  • change jobs in hope of ending up in a better environment
  • or try to change the current environment by saying “NO!”.

The only problem is that if you refuse to do stupid things you risk your job. And this is where courage comes into the picture. The rule is: if you want to change anything in your workplace you must be ready and willing to get fired over it. Otherwise you will give in, you will buckle – and things will stay as they were.

The empiricism underpinning all agile methods means that people live in a constant inspect & adapt loop. It is primarily about the product being worked on – but it also applies to teams themselves. The idea is that with agile not only the product evolves and gets better, but also the teams – and thus people teams are made of. This is one of the claims as to why agile is inherently better than waterfall – it not only produces better products, but also better teams. Some agile methods recognize improvement in teams’ ability as an important part of the process and prescribe tools to foster it – for example a retrospective producing actionable improvements every sprint is a required part of Scrum.

This is all very nice & good, but the problem is that improvement is a slow, monotonous process. It is rarely achieved by doing something spectacular. It usually means adjusting work methods, coding styles, design habits and daily routines. Often those are small adjustments or they are achieved by a series of small steps through time. It means taking the actionable improvements seriously and honestly striving to implement them every day, every iteration (sprint to use the Scrum term).

Why is this a problem? Because there is little joy in this as the change happening every day or every week is so small it is imperceptible for those involved.

How can we solve it? By making the improvement visible – and by keeping the work itself fun and engaging.

One great tool is retrospectives – they should not be solely about hunting down problems, but also recognizing, even celebrating improvements that the team achieved. There is a strong tendency to be negative during retrospectives, to concentrate on what didn’t go well as opposed to recognizing what was right. A more balanced retrospective gives team a chance to realize how much they have improved since the last time.

Another idea for making improvement visible is encouraging both internal and external sharing of knowledge and work through talks and conferences. If you talk to peers about a craft you share you will frequently find that what is already part of daily work for you is a discovery for others. This is the moment when you realize how much you have improved. Organizing a monthly, internal “tech talk” or encouraging people to submit talks to conferences is a way to foster this.

In any case I think it is the Scrum Masters (or Agile Whatevers) role & responsibility to make improvement visible, at least from time to time. It also part of the responsibility of managers overseeing the overall development organization. And it all starts with recognizing that improvement is boring…

Update:
This problem is not exceptional to software development. It is exactly the same in other crafts/skills – path to mastery leads through small improvements.

In fact, it should be easier for software developers, because in their case the improving quite frequently means learning something new – and this rewarding in itself. Others have it harder, because in other activities improvement comes through repeating same things over and over again. Musicians play & play same tunes for hours to get better. Soccer players repeat same standard moves as part of their training.

What is common, however, is that a) it takes discipline and willpower to improve and b) from time to time the improvement made is made visible (a musician plays a concert, a soccer players plays a match).

Bob Marshall wrote on his popular blog, that retrospectives make no sense if they are not about a hypothesis – or in other words, if they are not about analyzing why things didn’t go as we envisioned. This was followed with others voicing their agreement (example). While I agree with Bob on many things this time I think he missed the point of retrospectives as such.

Retrospectives for me are not a part of the process of “manufacturing” software

  • per se
  • , as they are not related to the product (software). Their purpose is not testing some pre-formulated hypotheses about the process – their point is discovery leading to self improvement. This discovery is achieved by stepping aside from the process, stopping and taking a look back to reflect on what happened, then considering our present state as a team and finally looking into our future. And key focus here should be us as a group of people – humans – being (experiencing our existence) together: how we related to one another, how we related to those not on the team, how we felt about what we were doing and – lastly – how we were doing it. By discussing this as a group we also develop stronger bonds – retrospectives are an important part of the true team-building process (as opposed to silly, artificial “team building” trips and parties).

    Retrospectives – at least the way I treat them – are akin to group therapy sessions for teams. I’m not using this analogy lightly, I think some elements of retrospectives are therapeutic. That’s why I see value in them being led – at least from time to time – by outsiders (coaches). Paradoxically it is easier for groups to open up with the assistance of a stranger, who is not part of teams’ internal dynamics nor local politics.

    No matter who leads a retrospective any pre-formulated hypotheses or (worse) outcomes are an impediment to the discovery process. We should approach a retrospective totally open-minded, curious maybe as to what will surface this time.

    That is why we should retrospect regularly, using varied techniques to avoid routine and stagnation. Retrospecting only when there is a hypothesis to test (as a lady from Target Processes said they do) is, in my humble opinion, a suboptimal practice – it is loosing most of the value retrospectives can bring.

    « Previous PageNext Page »