Top Gear: A New Refactoring Kata

For the last five or six years, I’ve been using coding exercises during job interviews. After talking a little with a candidate I open my laptop, call up an editor, and we sit together to do some coding.

My favourite exercise for this is a refactoring kata that I came up with. I’ve always found it more interesting how people deal with bad code they encounter than any small amount of code that can be written in this kind of short period.

The form of the kata is very much inspired by the ‘Gilded Rose’ kata, but it’s intentionally smaller so that it’s possible to get to a point where tests can be written and the code refactored in a period of about an hour, hour and a half.

The code is supposed to be the code of a automatic transmission. Someone has built it, but it was probably (hopefully!) never released. You are asked to make a few improvements so that the gear box can be made more energy efficient in the future. This is the description:

The code that we need to work in looks like this:

I’ve made Java, PHP and ruby versions available in my github repository: https://github.com/wouterla/TopGearKata

If you add a language, let me know!

Everybody need somebody

On occasion, I like to listen to podcasts. Some of the most interesting can be those that are from outside of the software industry. This week I was listening to Robb Wolf’s podcast, where he hosted guest David Werner. Robb talks mostly about diet, metabolism and exercise, and this episode was focused on that last one. Both Robb and David are coaches. In the sports sense of the word: they own gyms, and teach people how to exercise both for general health and to improve performance in some sports endeavor.

Listening to people who are experts in their area is always a joy. Because learning by osmosis is fun. Because listening to people talk at a higher level of experience then you can helps you find out what is really important in an area (well, sometimes…). A joy. And, remarkably, it’s also a joy to find how people in completely different lines of work have found ways of working and thinking that so resemble things in my own area of work.

So it was nice to hear David Werner talking extensively about improving in small steps. About the danger (in physical training) of taking too big a step, and having related smaller goals that won’t over-strain you current capacity. And about how often people don’t do this, and try to do pull-ups while they’re not even able to do a proper push-up, damaging their shoulders in the process. The fact that I’m still recovering from my own shoulder injury due to over-straining has only marginal influence on that.

drop down and give my twenty! (well, if you can. Otherwise 3?)

drop down and give me twenty! (well, if you can. Otherwise 3?)

David went on to describe that based on that experience, he was building his new website in the same manner. He even mentioned that there was some Japanese word that is sometimes used for that. Kai-something?

Another piece of cross-industry wisdom is their discussion on how everybody, no matter how experienced, needs a coach. Robb joining David’s training helped him find areas where he could improve his fitness that he hadn’t found himself. I guess that the more of an expert you are in an area, the more expert your coach would need to be, but having an outside view of what your doing is the very best way to get better of what you do.

Everybody needs a coach

As a coach, of consultant, or whatever you want to call it, it’s sometimes hard to get this kind of feedback. That’s why initiatives such as Yves’ Pair Coaching, of one of the Agile Coach camps are very valuable. And why we like to go to all those conferences. But you can find opportunities in your everyday work as well, just by explicitly looking for it.

Agile On The Beach Talk

Ciarán and I had a wonderful time at the Agile on the Beach conference this last week. We did the first full version of our talk: “The ‘Just Do It’ approach to change management”.  I did an earlier version of the talk at the DARE conference in Antwerp earlier this year, but this longer version has gone through quite a few changes in the mean time.

agile-on-the-beach

The conference was set-up very well, and it was great to talk to so many people working on Agile in the UK.

The slides for the talk are up on slideshare:

We got some really nice responses, including:
The next chance to catch us is at the Lean and Kanban Netherlands conferene (“Modern Management Methods: Making Better Decisions”) conference in Maarssen on 7-8 October. We’ll have a new iteration of the talk, of course. Always on the move:-)LKNL-im-a-speaker-badge
UPDATE: The video of the talk was just released, and can be found on the conference website. Our talk can also be viewed directly on YouTube:
 Next year, Agile on the Beach will be on 4-5 September, and you can register your interest.

Conway’s Organizational Structure Heuristic

organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations. — Melvin Conway

We often run into examples of Conway’s Law in organizations where silo-ed departments prompt architectural choices that are not supportive of good software design. The multi-functional nature of Agile teams is one way to prevent this from happening. But why not turn that around? If we know that organizational structure influences our software design, shouldn’t we let the rules of good software design inform our organizational structure?

Good software design leads to High Cohesion and Loose Coupling. What happens when we apply those principles to organizational design, and in particular to software teams? High Cohesion is about grouping together the parts that work on the same functionality, or need frequent communication. Multi-functional teams do just that, of course, so there we have an easy way of achieving effective organizational design.

Loose Coupling can be a little more involved to map. One way to look at that is that when communication between different teams is necessary, it should be along well-defined rules. That could be rules described in programming APIs when talking about development. Or rules as in well defined pull situations in a Lean process. Or simply the definition of specific tasks for which an organization has central staff available, such as pay-roll, HR, etc.

In general, though, the principles make it very simple: make sure all relevant decisions in day-to-day work can be made in the team context, with only in exceptional situations a need to find information or authorization in the rest of the organization.

Spikes, they’re sharp

One of the concepts that came from XP is the Spike. Especially in teams new to agile, there can be confusion on what a Spike is, and how to deal with them.

The best definition of a Spike I’ve found is this one:

“Spike” is an Extreme Programming term meaning “experiment”. We use the word because we think of a spike as a quick, almost brute-force experiment aimed at learning just one thing. Think of driving a big nail through a board.
— Extreme Programming Adventures in C# – Ron Jeffries

Let’s break this down.

Experiment

A Spike is an “… experiment aimed at learning just one thing”. That means that a Spike always starts with a question to be answered. An Hypothesis. At the end of the Spike there is an answer to that question. The hypothesis has been proved, or disproved. And that proof takes the form of a piece of software. A document does not prove anything.

Quick

A Spike is quick. A Spike is usually time-boxed, to as short a period of time we think is feasible to answer our question. That period of time should normally not exceed a day or so.

Brute-force

A Spike will not generate any production code. A spike can be a design session in code, just enough to prove that the design will work. It can be a technology investigation, just enough to see if that library will do the trick. All code from the Spike will be thrown away. It’s about learning, not production.

Rare

I know, that wasn’t in Ron’s definition. Just an additional remark. Spikes are rare. They occur only very infrequently. Once every couple of sprints sounds about right to me. That might decline with the age of the project, as Spikes are particularly useful to remove uncertainty on technical design early in a project.

Spike image

In practice

When an occasion comes up to introduce a Spike into a sprint, you do the following:

  1. Reconsider: Do you really need to investigate, or are you just scared to commit to an actual, value delivering, user story because you don’t know the system very well?
  2. Reconsider again: Do you really need to investigate, or are you just scared to work together with the rest of the team without someone handing you a detailed specification?
  3. Define the question: ‘grooming’ a Spike means that you clearly and unambiguously define the hypothesis that you need to have answered by the spike. This is like the Spike’s Acceptance Criteria. That means clearly defined, and preferably having a boolean (yes / no) answer. Agree what further actions will result from a ‘yes’. And from a ‘no’.
  4. Define the time-box: To answer this question, what size investment are we prepared to do? Keep it short. A day is long. Sometimes long is needed. Sometimes.
  5. Prioritize: The Spike is on your backlog. You prioritize your backlog.
  6. Execute: Code to find your answer. Stop as soon as you have it. Stop if the time-box expires.
  7. Deal with the result: That’s the action agreed upon earlier. A timed-out Spike also is an answer to that question (‘too expensive to find out’), and also has an agreed upon action.

Have you done a Spike recently? How did that turn out? Did you get your answer? Or a time-out?

On Discipline: Fooling yourself is an important skill!

Discipline is an interesting subject. One that I find myself regularly talking about. Or discussing about.derren brown mind control stunt

In the last year I lost about 20kg of body weight through a combination of diet change and exercise. This apparently give some people the impression that I am very disciplined. I’m not. I do know, however, how to make change easier to absorb. And how to inspect and adapt.

Fooling yourself is an important skill

The best ways to make sure you are able to keep discipline is to make being disciplined easy. And luckily, human beings are exceedingly good at fooling ourselves (click on the picture of Derren Brown, here, to watch a nice youtube clip demonstrating this).

For losing weight, this included:

  • Making sure that what I could eat was as least as nice to eat as what I had to stop eating (more meat, less potato chips)
  • Teaming up with my cousin to make not going to the gym not an option
  • Daily measurements of multiple metrics to get an understanding of progress, and variation
  • A very substantial reduction of insulin use, and improvement in blood sugar values with the corresponding increase in energy levels
  • Setting sensible targets that I adjusted as soon as I reached them.
  • Regular experiments to see what helped (drinking a lot of water), and what didn’t (too much exercise)

It’s just common sense. If you want change, make sure that what you’re changing to is enjoyable, and that your progress is clearly apparent. And a little peer pressure can also be useful.

Many of the practices promoted for agile processes fall in the same mould.

  • Short iterations give a clear sense of purpose for the short term, and a sense of accomplishment when completing them.
  • Visual progress, such as a scrum/task board give a direct view of progress, and the impression of things getting done (plus a little peer pressure…) when everyone on the team gets up and moves post-its a couple of times a day
  • Acceptance Test Driven development gives clear and achievable goals
  • Pair programming helps keeping focus throughout the day
  • Test Driven Development does the same, and again keeps progress visible
  • Retrospectives (and the resulting improvement experiments) give the sense of continuous improvement needed stimulate a positive feeling of support of the surrounding organisation

It might be slightly irreverent to throw all of these things together and talk about ‘fooling ourselves’. Is working in concordance with human needs ‘fooling yourself’? I don’t know, but I rather like the sound-byte:-)

Estimates and Commitments – The Hard Truth

My esteemed colleague, Ciarán ÓNéill just posted a nice and considered discussion on estimation, velocity and cycle time. I, however, do not plan on being so considered, or considerate.

You see, too many people are bent under the crushing weight of living up to estimates. Even reckoning that they provided these estimates to begin with, the continuing focus on this fragile, incomplete, numerical slice of their work is having a seriously detrimental effect on our industry.

I can’t count how many times I’ve seen this playing out, in different companies. The poor product manager, even if he’s sometimes called Product Owner, has made his business case; calculated the expected ROI; probably even spent lots of time plotting the Rate of Return over time; thinking of ways to track the relevant figures closely so as to be able to adjust the approach over time; and shared these ideas with the broadest set of people within the company to get as much feedback as possible.

He’s calculated expected additional visitors to the website, impact on conversion and retention rates, and put in place the instruments to verify those numbers. He’s had his numbers checked by his peers, and carefully explained them in detail to the development team he’s expecting the work to be done by. He’s done everything he can to make sure his estimates are as accurate as he can make them.

And then he’s done the additional work to make sure he can not only track whether he’s on-track, but also proposed different scenarios on how to react if they’re not. He’s done all that for all the different features, and new products, that he deals with, and used the expected returns to prioritise work in the way that profits the company most.

Now he knows, our intrepid product manager, that he’s dealing with a complex issue! He’s been careful to include confidence margins, bandwidths of possible returns, and comments stressing uncertainties and risk factors. He’s done everything right.

So what happens after a few sprints, when the initial (bare minimum) features have seen the day of light and basked in the glory of unadulterated customer scorn? He’s still in the bandwidth of expected returns, but he can see that he’ll probably end-up on the lower end of the range he expected. At the iteration review he shows the current results to the development team (there’s a few managers in the audience as well), shows how things are progressing, where he sees ways to change the feature to get more customers interested, and how the priorities need to be adjusted to make this happen.

Some of the feature, sometimes a lot of it, needs to be cut. Including some functionality already released! After all, no-one is actually using that. And to make it a success, the team will probably have more work to do than was originally expected. In the end, though, they still have a very good chance of making this a success.

And that’s where the trouble hits home. The poor guy is lambasted for not being able to stick to his estimates. He came up with those estimates himself, he should make them work. After all, the numbers added-up, didn’t they? Everyone else is doing their part, and if he’d just put a little effort into it, he really should be able to stick to the plan, and ensure that customers start using the new feature as was planned. Perhaps adding more advertising for this feature is what is needed, and budget should be found for some additional effort on that part. Or maybe, since he’s the one not delivering, he should do that advertising work himself over the weekend.

It’s cruel. We, as an industry, should stop holding our product managers to standards that are impossible to reach. We should accept the inherent complexity of the problem, and help them tackle it by planning, tracking, and adjusting the plan as necessary. In fact, if we make the steps and adjustments small and fast enough, we could possibly relieve them from a large part of the yoke of budgeting, automating many of the tracking of adoption, and making them fully recognised, adult members of the organisation!

Success

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

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

Scrum vs. Kanban: A Game of Life?

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…