Bad reasons to adopt Kanban

David Anderson recently posted Why do we use Kanban?

He proposes two lists, one entitled ‘Why do we use Kanban’ and a second entitled ‘We do not use Kanban because’, the second list contains complimentary practices that are themselves not a reason to adopt Kanban. For instance it is not necessary to adopt Kanban if all you want to do is dispense with iterations.

The thing I found really interesting about this post is that the reasons my team first adopted a kanban system were drawn almost entirely from the second list. In particular our dissatisfaction with time boxing.

This may, in part, be due to us coming at this very much from a software development perspective, rather than considering the entire value stream.

David lists the following as reasons for practising Kanban

Evolutionary, incremental change with minimal resistance

Achieve sustainable pace by balance throughput against demand

Quantitative Management and emergence of high maturity behavior in alignment with senior management desire to have a highly predictable business

Better risk management (the emerging theme in the Kanban community)

It’s only through practising kanban and learning more about the lean principles underpinning it that the real benefits such as improved risk management and greater predictability have become apparent.

Anatomy of a technical Interview

So you decided that you need to hire a new developer , advertised in the right way , vetted the CVs and even thought of some questions . Unless you’re in the 0.1% of people that think that a 90 minute chat is the best way to assess the skills of someone you may end up working with for the next 5 years you’re going to need to think really hard about how to give the candidate the best chance of showcasing their skills in a face to face interview.

This post won’t help with what questions to ask, but it will help with structure and maximising the chance of getting a good performance from a candidate.

Calm them down

First off let’s start right at the beginning, you’ve just met and are about to commence on some small talk, perhaps give an overview of the company – to be honest it really doesn’t matter what you say at this point, the candidate simply isn’t listening. Years of evolution are telling them to fight or flight and it’s your job to calm them down sufficiently that you can move the interview forward.

Your end goal is to get to the point where you can ask them some really hard questions with a fighting chance of doing themselves justice, but first off there’s ground work to do.

Get them talking

Having helped them settle into their surroundings, it’s time to turn things up a notch and actually get them talking. A pretty good way is to go through their CV, their past work experience, university projects etc. This is stuff that they definitely know more about than you do, and should help them ease into the interview. The key point to remember here is that by asking very open questions and listening to what they consider to be most important or interesting, you can learn a lot about them. Good candidates will start explaining cool and interesting tech that they have used, while others will start talking about co-ordinating this and managaing that. Give people a chance and press them on the tech, but if they’re not confident or worse disinterested, then this is your first warning sign.

During this period you should be thinking about what sort of person you have in front of you, people handle stressful situations in different ways and if you don’t pick up on this you’re likely to miss some good candidates. e.g. if they are shy they’ll need some encouragement or if they are brash and perhaps little arrogant you need to be challenging them and forcing them to justify their assertions.

A final point, and one that I am most guilty of committing, is to make sure that you don’t go too far and overly relax the candidate. Doing so will make it harder for them focus once you start firing technical questions at them.

Getting technical

Before we get into asking any questions, I’d advise the following approach. Present the problem in a form that will probably be too difficult to answer, expect the candidate to need some help and judge their performance on quite how much help they need. This means that you’ll get an idea for how they think, smart candidates will have stretched themselves to solve the problem and poor candidate can at least solve the problem eventually, meaning that they won’t be so traumatised that they can’t concentrate on future questions.

As an initial technical question I’d recommend something pretty straight forward. Something like Fizz Buzz, I find candidates answer these sorts of questions in three different ways.

They write out the answer without even having to pause to think and you move on quickly.
They struggle a little bit, think things through and get the answer out. This isn’t necessarily a bad thing and might be down to inexperience, but it does mean that they are unlikely to hit the ground running.
They really can’t get the answer together and need a lot of leading. Alarm bells are ringing.

Next up I’d raise the difficulty, I’d suggest something wordy and open ended, perhaps some sort of systems level discussion. This means that the candidate can still push the discussion in a direction that they are comfortable with, but make sure that have at least of few things in mind that you will definitely discuss. Again judge them on the amount of leading they need before completing the question.

Now you’re ready to unleash the killer coding challenge, in many respects the whole interview has been leading up to this point, you’ve learnt a lot about them including how to get the best from them, but the next question will really set the best candidates apart. At this point in the interview you also need to consider whether it’s time to bail, if the candidate struggled with the toy programming question and couldn’t impress with your follow up question, then you really have to ask yourself whether it’s worth skipping the final challenge.

I would chose something that is initially tightly bounded but has the potential for significant extension should the candidate be up to it. Exactly what you go for is up to you, but if you don’t stretch the best candidate they won’t want to work for you.

Any questions?

Lastly it’s time to ask the candidate if they have questions, this in itself can be illuminating, though to be fair at this stage, the best they can do is reinforce a good performance. Questions about working attire and hours are generally a bad sign especially if not a final round, questions about version control, project management practices or something that came up as part of the interview are generally good things and provide an opportunity to sell the role.

After the interview

Once the interview is over, it’s time to come up with an decision. How you do is will be entirely down to your specific circumstances. For first rounds I tend to allocate a point for their programming, their systems and general technical common sense and finally a point for how well I think they’ll fit in. Anything over two and half, i.e. a strong performance in two out of the three and a good performance in the third is a thumbs up. For final rounds you can’t afford to let them leave the room if you still have any concerns unanswered. This is someone who you could end up working with for years so err on the side of caution.

Ultimately though, the only way to arrive at a good system is to have a lot of practice. Make sure technical staff are involved at the earliest possible stage and if you make a bad hire, don’t blame them, blame your process and learn from you mistakes.

In Defence of ‘Scrum but…’

Scrum, as a framework, is practiced in many different organisations and can be considered a mainstream approach to software development. To me agile is way of scaling common sense and while I no longer practice Scrum I consider it an excellent implementation and would happily return to it if my circumstances were better suited to time boxing. However as with all great ideas that are adopted widely, there are many instances where people are simply doing it wrong.

Warren Buffett has a neat way of describing this:

First come the innovators, who see opportunities that others don’t. Then come the imitators, who copy what the innovators have done. And then come the idiots, whose avarice undoes the very innovations they are trying to use to get rich.

In the case of software it’s reasonable to replace the goal of getting rich with that of successfully delivering software that is valued by the customer.

As such there are a wealth of posts discouraging the adaption and variation of Scrum, in fact the notion of Scrumbut is so well understood it even has a definition.

scrumbut [skruhmbut] noun.
1. A person engaged in only partially Agile project management or development methodologies
2. One who engages in either semi-agile or quasi-waterfall development methodologies.
3. One who adopts only SOME tenents of the SCRUM methodology.
4. In general, one who uses the word “but” when answering the question “Do you do SCRUM?”

Project management will necessarily vary from company to company. As such the ubiquity of a term like Scrum has less value within a specific company, since the shared understanding of the company’s approach ought to be evident to all. When I talk to people outside of my company it’s useful to reference commonly understood terms as a starting point. For time boxed approaches Scrum is an obvious point of reference, but the specific system that I wish to describe is highly likely to deviate from Scrum in some way and I do not necessarily see this as a bad thing.

The challenge of software development is to produce something that someone will find valuable. There are plenty of different ways to achieve this and all are highly dependent on the context of the project. Generally an iterative and incremental approach that bakes quality in from the start is preferable and a number of ready made implementations exist such as Scrum, Kanban or Evo. In some cases it may be appropriate to lift something like Scrum wholesale, but in many other cases, there are legitimate reasons for adapting the process. For example a team might be writing an implementation of a system where the behaviour is well understood. In fact in order for the system to be compliant and therefore usable it must adhere to a large pre-written spec provided by an external party. Clearly this is at odds with Scrum but there is no need for the team to drop time boxing or stand ups as a result.

So adapting a process is not in itself something to be frowned upon. Clearly bad project management is bad, and if the manager blames their own failings on their inability to implement a methodology then larger problems exist. The key point is that good managers should not worry that they are running Scrumbut, or indeed if they are ‘doing it right’ as the only metric for correctness is that the team maximises the value they create.