Line by Line

I recently wrote here about the benefits of failure. One of my recent failures reminded me about the importance of success. I thought that to be nicely circular enough to warrant a new post!

You see, while it’s important to embrace failure – how else are you going to learn? – it is just as important that you don’t set yourself up for failure too often.

One very popular way that agile teams do set themselves up for failure is by taking in too much work in a sprint. True, this wouldn’t be too bad if failure was better accepted: we’d just recognise we were not going to make it, and drop some stories from the sprint. And learn to take in less work for the next sprint. But this is not what happens. What happens is that we try to succeed anyway. And that we don’t stick to our own rules of work when doing so. So we work late (making the whole concept of velocity useless, a way I missed in my previous list of ways to do that), or we reduce quality. Or both, usually.

But here I am getting stuck on failure again. We were talking about success!

When a team is starting out with agile, they are bound to run into many issues. The short feedback cycles ensure that they’ll be confronted with all kinds of ways in which their current process is suboptimal. This is not always a nice experience and if it is not mitigated by successes in improving matters, a team can become discouraged, and let their agile experiment die off.

In the recent situation I was referring to, this is what happened. The team had quite a good grasp of what was wrong in their process. In fact, during our initial ‘Scrum Introduction’ workshop some clear issues came up. We always do such a workshop in the form of an extended retrospective, interlaced with some theory and games. In that retrospective part, one of the top issues that came up was that of team stability. Teams were reconfigured for every project, but people were also regularly reassigned in a running project. Some further questioning quickly unearthed frequent quality issues in both requirements and code, causing people to be needed for projects in trouble after release or in ‘user acceptance testing’.

Note: UAT is not supposed to be a process where your users are the first people to test your code!

So, knowing that the underlying issue was one of quality we started by focusing on quality. Can’t go wrong, right? But the feedback loop from the quality issues to the ‘reassignment’ issue was very long. Also, since the reassignment was to other teams, that were already in trouble, the improvements we could make had no possible influence on the stability of the team. And so, when during a planning meeting for the third sprint the third person was ‘temporarily’ moved to another team, we figured out that we had set this team up to fail.

So what should we have done? ‘We’ being me as a coach, or the team involved in a – management approved – change process. We should have gone to the company management before starting any sprints (so right after that retro/workshop) and asked for their support, guaranteeing that this team would be left intact for the duration of the project. We should at the same time have advised working on the widespread quality issues.  I should add that it would have been exceedingly unlikely that that broader support would have been given, but then at least it would have saved everyone some work and more importantly, disappointment.

The lesson here is that when you find your impediments, you should make them visible to the wider environment, and make sure that you actively work to remove them in as short a time as is possible. This most definitely includes involving management, and will underline their support for the agile transition in progress. Not doing that is denying the team a chance to experience success. And that’s a great way to sabotage your change process.

Failure is not an option!

I’ve heard that phrase a number of times during my career. Mostly by people imitating a manager they heard in a meeting, but still too often.

What’s remarkable is that this phrase is usually uttered at the moment that it is becoming very clear that, yes, failure seems to not just be an option, but fairly likely!

And that’s the thing. Failure is always an option. The question is, what are you going to do about it?

Failure is always an option

No, let’s step back from that for a minute. First let’s see what we mean by failure. For many project managers, a project is a failure if it’s not delivered on time, and with the complete scope that was agreed. I’ve hurt project manager’s feeling at times by reminding them that according to their own definition, budget was also part of that equation.

A project for which people have had to work overtime, was a failure

Overtime means that you found out there was a problem very late, and at that point did not have a good enough relation with your customer to be able to negotiate release date or scope. That’s a good description of project management failure. Which is not to say that the project manager is the only one that failed, btw. That sort of thing requires a team effort…

Back to the options for failure.

Failure should not just be an option, it’s a requirement. If you go through a whole week of work on your project, and there’s no failures at all, it’s time to get worried. Because either you’re not noticing the failures, or you’re simply not trying hard enough.

You should have found some things that were harder to do than expected. When you do them again, later in the project, they’ll be easier, if you noticed this failure and learn from it. You should notice that your velocity over the last three sprints has been lower (or higher!) than expected. You need to adjust your planning accordingly, and talk to the customer about possible scope or release dates changes. Your continuous build broke five times in the last sprint. You should be talking in the team why that is, and ensure it doesn’t happen again. Your newly written unit test fails. Of course it does, you’re working test driven! Your customer keeps adding to and changing requirements during the sprint. You should make the requirements more explicit before the sprint starts, so that it’s clear the requirements are new.

Failure means learning. Failure to learn could mean… lack of success.

The more you allow failure. The more you encourage failure. The better you will be at detecting failure. The lower the threshold be for your people to report failure. And all that will help you navigate towards success.

Success consists of going from failure to failure without loss of enthusiasm.
– Winston Churchill

I’ve been following some of the discussions on the differences between Scrum and Kanban. And learning more about Kanban, of course. One point that is emphasized a lot is that Kanban requires fewer up-front changes than Scrum does. The term “Big Change Up-Front” has even been coined, by Alan Shalloway.

There’s certainly truth in that. Scrum doesn’t have many rules, but it is very strict in assigning a very limited set of roles and responsibilities. Kanban can be used with existing roles, as long as you make make sure you make the existing roles and policies explicit. Asking which one of those option is better is really beside the point. It simply depends on the context. In my situation, I usually get called in by companies who have already decided to ‘go Agile’, and as such are already part way through some of those changes. Of course, the changes are not always successful, but it doesn’t provide me with a change to start slowly.

Interesting discussion, of course, and for me it brought to mind Conway’s Game of Life. For those unfamiliar with it, this is a cellular automaton game, where a set of rules iteratively executed over a set of cells (with a state of on or off), where all kind of interesting stable and continuously changing patterns can occur based on the initial pattern put on the board.

Scrum could be compared with a fairly big and complex ‘breeder’ pattern, which needs to be placed on the board as a complete set. It’s quite an apt comparison in that the infinite growth belonging to such a pattern doesn’t happen if you get part of a breeder pattern wrong. And since you can see the Game of Life as a universal Turing machine, infinite growth means a continuous generation of information, which can be as continuous learning.

Kanban can start with an existing stable pattern (an oscillator), and can tweak that to move, step by step, towards breeder status. At least, that’s how I see it.

The analogy will probably break down after this initial thought, and might be made better if we move from comparing to patterns to comparing to rule-sets, but my brain started to hurt when I went along that route…

Peter Stevens, over at 

Scrum Breakfast has an interview up with Mary Poppendieck on Lean, Scrum, Kanban and Leadership. The part of the interview that caught my attention was a question on the relationship between Scrum, Kanban, and Lean in general.

I like Mary’s response a lot, where she basically states that Scrum and Kanban each have their own strengths, and each is suited for their own specific set of circumstances.

Scrum is basically a method of accomplishing work through cadenced iterations. Kanban is a method of accomplishing work through limiting work-in-process and managing flow. I have found that some work especially creative work is more effectively managed with iterations, while other work especially naturally sequential work is more naturally managed with Kanban. — Mary Poppendieck

She also stresses that, whether you choose to use Scrum or Kanban, the point is that you keep improving on your way of working, so:

Lean would have every company view these techniques as starting points that are constantly improved, so after a few years, Scrum and Kanban should evolve and change to something quite different than their starting point. — Mary Poppendieck

This suits the way that I view these things very well. Use the tools most suited for the situation, and see where it leads you.

Of course, the best way to choose is to try each, and measure results. Which brings us to another question: what and how do we measure? At the moment, I’m leaning towards flow (time for work to flow through the system), and Henrik Kniberg’s Happiness index. Getting that last one adopted anywhere is going to be an interesting challenge, though…

An old article I just came across, posits that learning is the thing of value in software development:

When we present this hypothetical situation to students – many of them with 20+ years experience in building software – they typically respond with anywhere between 20% to 70% of the original time.  That is, rebuilding a system that originally takes one year to build takes only 2.5 to 8.5 months to build.  That’s a huge difference!  It’s hard to identify another single factor that could affect software development that much!

The article goes on to discuss in detail how learning is enabled by agile processes. The advantages of quick feedback cycles are not just ‘fail early’, but also ‘learn early’ (and continuously).

Agile Feedback Loops

Peter Stevens has a nice write-up on the differences in responsibilities between Scum projects, and traditional project. As can be expected, responsibilities are distributed broader in an Agile team, with much (or all) of the responsibilities of a project manager being spread over the Product Owner, Scrum Master and the development team.

Especially interesting is that they found some responsibilities not being clearly defined in a traditional team (ROI, process improvement), while it was there in Scrum. I’m not sure whether that’s quite fair, since tracking ROI is only rarely actually done in Scrum projects, but the responsibility is explicitly there.

Scrum Breakfast: Responsibilities in Scrum, or Why Scrum Developers Should Get Paid More!.

The retirement of Google Wave is pretty big news. There’s a lot of discussion on how Google failed. Failed because they misjudged the acceptance, failed because they overhyped, and failed because they waited too long before finding out whether users would actually like it. And all those things did happen, and some of them were probably mistakes.

But the main thing that I get out of this, to be honest, is quite a bit of respect for Google in how they handled this. They had an idea, followed up on it, saw a possibility of creating a product out of it, experimented, poured resources into it, tried it out in the wild, publicly supported it… And when the time came, they admitted it wasn’t working out as hoped for, and in a timely manner pulled the plug. Writing the whole thing off as something that generated some useful technology, and hopefully some valuable insight in end-user wishes.

This is how you innovate. You take risks. You try new ideas. You get feedback from your (potential) users. You fail.

And if you don’t fail enough, you’re not trying hard enough.

For a company of Google’s size, failure is necessary on a larger scale.

Now if you’ll excuse me, I have some failing to do…

Update: I just love it when people back me up: Eric Schmidt said: ”We celebrate our failures. This is a company where it is absolutely OK to try something that is very hard, have it not be successful, take the learning and apply it to something new.”

Pete Deemer has written an article on InfoQ, Manager 2.0: The Role of the Manager in Scrum which disucusses the role of the manager in an Agile organisation.

The situation sketches that he gives are all too familiar, and anyone working on a transition to Scrum (or any other Agile practice) would be well advised to read this article.

The quote that rang the most bells for me was:

“If there exists a fundamental belief in the effectiveness of the “command and control” approach within the management and executive ranks, and a heavy dependence on intimidation, threats, or punishment (such as shaming or humiliation) as a management tool, it is going to be particularly difficult to make the transition to a new way of thinking. As a result, an adoption of Scrum risks being incomplete and dysfunctional, producing little if any improvement for the organization.”

The warning not to have (ex-) managers as Scrum Master is another important lesson, though. The habit of following orders is just so very hard to break.

Scott Ambler is in the habit of doing some very interesting surveys. One that caught my attention this morning was on Enterprise Architecture.

The interesting part is the tables on success and failure factors. The highest rated success factors are about involvement and communication with both business, management and the development teams.

The highest rated ‘reasons for cancelling enterprise architecture programs’ are getting insufficient time, not being able to prove any benefit, and rejection of the EA work (and sometimes the EA) by the development team. Again, all factors of involvement and communication.

So there you have it: If you want to get some architectural improvements off the ground, the important thing is that you need to talk about it. Sell it to the business, by providing them with convincing arguments on how this change will benefit them. Talk to the development teams, and get them involved. Not just in execution of the idea, but in improving the concept and generating alternatives. You can’t know everything, and even if you did, you’ll get more done if the teams are involved in defining the needed changes.