Applying for Jobs and the Agile Job Search

I’ve written before about how I approach recruitment and I’ve even given a talk on it, but recently I’ve been on the other side looking for my next role.

There are some parts of my own recruitment process I will definitely be improving as I now understand more about the things matter to an applicant.

Firstly, waiting for feedback after applying can feel like forever.  I’ve previously waited weeks before contacting people for interviews, despite getting feedback later that this was a long time!  I will now try and give feedback within 3 working days of receiving an application (and will commit to that in any automated responses that I might send to an applicant).

The next thing I experienced was how you really need to sell the company and you should involve everyone in this process.  I was put off by grumpy receptionists, untidy buildings and late starts to interviews.  All things that I might have previously considered minor, but with other items appearing equal then they could have made the difference!

The interview questions that are asked also reflect the company.  For some roles I engaged in pair programming to test my technical knowledge, others I was asked about more obscure areas of C++.

The biggest issue I have with interview questions and a question I often ask myself, is what insight do I get if someone answers incorrectly?  The opposite is easy, if I ask about virtual destructors in C++ and I get a good answer then I have learnt something about their C++ knowledge, but if they don’t answer very well then what have I gained?  Do I really need someone who already knows this information or would I be happy spending 5 minutes explaining the answer and having someone who can learn?  Unless you really must have someone with this knowledge then you either haven’t asked a question that helps you evaluate, or you could be turning away a lot of suitable candidates.

Johanna Rothman has often written about how the shortage of skilled workers is being made worse by poor recruitment practices.  She suggests hiring for cultural fit and helping people gain the skills they need to fill the role.  After all, when I was looking for a new role, I was looking for somewhere that could also offer growth for my own career not somewhere where I already knew everything.

To give myself a boost in my job search, I attended a 1 day seminar in London with Johanna Rothman.  I’ve since bought her book, which is also highly recommended.

The course itself ran with an agile approach, being tailored towards the people on the course.  It was an amazing day, not only was Johanna brilliant, but the encouragement and support from the other 3 attendees was an unexpected and powerful bonus.

Whilst I didn’t put too much of Johanna’s headline ideas into practice, I can see how well they would work and I often stumbled into the mistakes they were designed to avoid.

Some wise words proved very wise later; Johanna said that getting a new job is hard, and there will be many ups and downs along the way.  I had moments of positive feedback and exciting roles to apply for, but also many lows of rejection and frustration.  I especially disliked that feeling of not being in control – I knew I wanted a new job, but couldn’t find anything suitable to apply for or was unable to progress roles I had already applied for.

I also found that I shouldn’t rely on other people to progress my application, especially recruitment agencies.  Despite getting automated acknowledgements to say they had received my application, I still found they’d gone missing when I chased a few days later!  Keeping a list of what I’d applied for, through which contact and agreed next steps would have been a lot smoother if I’d written it down rather than trying to keep it in my head!  Sorry Johanna!

The one part of my job search that I couldn’t get working, despite Johanna’s advice was in finding roles to apply for.  There’s a lot of research that suggests many roles are not advertised and are filled by people meeting the hiring manager, but I didn’t manage to find them.  Instead, I found a daily search of Indeed to be the most effective.  I was able to setup about a dozen searches and check for new entries in each of those categories easily each day.  This was made even easier using the Indeed phone app.  I also setup an rss feed from stackoverflow careers, which has some amazing jobs, but I didn’t find many in the locations I was looking for.

Most roles were advertised through recruitment agencies, and I ended up uploading my CV to cwjobs and jobsite in order to apply for a lot of them.  This in turn triggered a lot of contact from other agencies for other roles.

I’m pleased to say that I have found a new role and I’m really enjoying it.  It’s always sad to leave somewhere, especially as I’ve been there for so long and have personally recruited so many of the great people who work there, but the time was right for a new challenge.

Posted in News, recruitment | Tagged , , , , | Leave a comment

Tribal Leadership

One of my favourite books of 2013 was Tribal Leadership:

I’m not going to go into the details here as there are plenty of better places to get that information.  Buy the book, check out this TED video or listen to the audio book

Go on – the video is only 16 minutes long, I’ll wait.

I first came across Tribal Leadership from the excellent Portia Tung at the equally brilliant BCS SPA mini-conference.

In her session, she explained the basics of Tribal Leadership and then set us up in teams with the task of making paper cranes:

Paper Crane

A Paper Crane

I didn’t really understand what it was about at the time, but I think I do now:

  1. Initially making cranes was hard, the instructions were poor, it wasn’t much fun – so we were experiencing stage 1, “life sucks”
  2. Then some people started completing the task, I wasn’t able to make a crane, so that was stage 2, “my life sucks” (but I understand that not all life sucks)
  3. Once I could build a crane I felt good and proud of my accomplishment.  This was stage 3, “I’m great” (with the implied stage 2 for anyone still struggling, “and you’re not”).
  4. The last round was as a team competition – trying to build more cranes than anyone else.  This was stage 4, “we’re great” (and you’re not).
  5. We never got to stage 5!

Since then I’ve seen some brilliant individuals stuck in stage 3 (I’m great, you’re not) and so struggle to create a team.  I’ve seen people exhibiting stage 3 behaviour that brings about stage 2 (my life sucks) reactions in others.  I’ve seen glimpses of stage 4 and have been working on exhibiting that behaviour and encouraging others to reach that stage as well.

I’ll probably write more about Tribal Leadership in the future as I’m a definite believer.


Posted in motivation, reading | Tagged , , , , | Leave a comment

Kanban with kids

I recently had a day at home with my kids and we decided (well I decided) that we’d try a new game.  I explained the rules:

“Today we are going to get lots of jobs done, but before we do anything we are going to divide up the whiteboard into columns; to do, doing and done.  Next we are going to write all the jobs we’d like to do on sticky notes and place them into our to do column.  Finally we’ll pick a job to work on and move it into doing.”

For those of you who haven’t come across this technique before it uses a kanban board.  It is often used in agile or lean development as a way of visualising work, limiting work in progress and providing a focus on getting items to done.  Here’s our board at the start of the day:


Kanban board at the start of the day

So what did we learn?  Well the first thing I learnt was that kids love using sticky notes, they loved writing on them and moving them across the board.  I’m pretty sure that adults do too!

When we started, our target was to get all jobs into done before the end of the day.  We didn’t spend any time estimating the tasks as that wasn’t important to us, the time was better spent actually doing the tasks.  As you might expect, we didn’t finish all the tasks, however the sense of achievement from the large number of tasks we did achieve was great.

We also uncovered a lot of the common issues I also see at work.  Some of the tasks in our backlog (to do column) were too vague and were actually several tasks in one.  For example, one task was to empty the wash basket.  That was actually several steps; put first set of clothes in washing machine and wait for it to finish, hang out wet washing when finished, collect dry washing from outside and then put away.  With a sprint of just a single day, and several washing loads to do, having a single task of many hours was not granular enough.

As Dad in charge (product owner) I was able to groom the backlog, breaking down these epics (empty wash basket).  I was also able to look for a natural order to the tasks, e.g. once the dishwasher was running we had an hour for other tasks whilst it completed its cycle so it made sense to prioritise that task above some others.

The final item we learnt was in defining our acceptance criteria, i.e. what does done look like?  One task was to tidy a bedroom.  This was too vague and subjective, who decides a bedroom is tidy?  Instead we employed a technique called time boxing.  The task became “spend 15 minutes tidying bedroom” with done now clearly defined as 15 minutes worth of tidying.  After 15 minutes that task moves to done, and as product owner I could evaluate and decide if I wanted more effort on tidying that bedroom and create a new task in the backlog.

It’s perhaps worth noting that a more traditional waterfall approach to this problem of whether a bedroom is tidy or not would have been to produce a more detailed definition of requirements up front.  I could have listed all the items that needed tidying away, that the bed needed making, bins emptying etc.  However, the common problem is that not only does this definition take time, it can also miss vital parts.  If I forgot to say that I didn’t want sweet wrappers on the floor then it would be possible to say the bedroom was tidy (according to the requirements) even though as product owner I could see the wrappers on the floor and so know that the room wasn’t tidy!  Another common problem with this approach is when the requirements are actually unclear, e.g.  I know the bedroom is untidy, but I don’t know how to make it tidy, or how tidy I actually need it.  A time box approach allows the team to spend an agreed amount of effort and the results to be evaluated.  No extra effort is wasted making the room tidier than needed, and some progress may help me as product owner to realise what further parts of tidying the room are important, e.g. Now I can see the carpet as the toys have been tidied away, I now want to focus on making the bed and taking dirty pots downstairs, but that is probably all I need.

Here’s our board at the end of the day:

Kanban board at the end of the day

Kanban board at the end of the day

Posted in agile, estimates, kanban, planning, Project Management, software development | Tagged , , , , , , , , , | 1 Comment

Who Said the Software’s Late?

We are always hearing about software projects being late.  My current experience tells me that my own software team will deliver their software later than planned.

So why is that?  Let’s firstly get the assumption that the team is somehow lazy, incompetent or unmotivated out of the way.  Good software developers and development teams just aren’t like that!

Right, so we have established that everyone on the team wants to succeed, they are working hard, but still the deadlines come and go and the software ends up late.

I think this can all be tracked back to estimating and we all know that estimating is hard.  I think the big question when someone decides that a software project is late is “who decided when it should be finished anyway?”  Simply changing the end date takes a project from being late to being on-time or even early.  This fact is so important, yet estimating is rarely given enough importance in order to set a realistic end date for the project.

One of my favourite responses I heard someone give to the question of when their software would be ready was “it will be ready when it’s ready”.  Really unhelpful in terms of planning the myriad of other activities that depend on that software being complete, but entirely truthful and sums up both the difficulty of estimating and the desire to avoid setting unrealistic expectations.

Let’s draw some pictures.

Firstly let’s look at a software project as a series of tasks that require completing before the project is complete.  You might see this on a GANNT chart:


Note: This is a very contrived example, simply to illustrate the point.

In this example, we have broken down our project into 3 tasks, all of which depend on the previous task completing before we can start the next one.  Our project plan shows us starting on the 6th January and finishing by the 24th January.

Now let’s take a look at the plan once the project is complete.


Several things now become clear:

  1. There weren’t just 3 tasks involved in this project, there were 5.
  1. Of the 3 original tasks, they were better expressed as several subtasks, the combined total of which took longer than originally planned.
  1. The project finished on the 4th February, not the 24th January as originally planned
  1. If the team (or project manager, sponsor or whoever is in charge of producing the plan) had produced a plan that looked like reality (version 2) then they would have been praised for completing the project on time.

The ideal project plan is therefore one that accurately predicts the future!

Don’t confuse poor estimation with poor performance (or the ability to set low expectations and then exceed them as a mark of good performance).

Posted in agile, costs, estimates, information, planning, process, Project Management, software development | Tagged , , , , | 1 Comment

The Agile Manifesto

The Manifesto for Agile Software Development is a really powerful piece of work and something I really relate to. Not only have some of the finest minds in the business been part of its creation, thousands of others have found that it relates to their own experiences and have been proud to sign up. I signed the manifesto myself back in March 2011, but recently it’s become more relevant than ever.

I’ve been part of a very successful business, the number of software developers has grown from a dozen to nearly 30 and we’ve subdivided into different teams working on different aspects of our product. You can read more about those changes in my series on progress; Part 1 – How things used to be and Part 2 – How things are now.  We’ve specialized and diversified from a company of developers to one with many different roles and departments. The challenge now is to try and maintain the aspects that work and made us successful whilst encouraging the new changes that will help us continue and become more successful.

Ask most people what a successful development team looks like and they’ll probably tell you that it is “agile”. But what does that mean? That they work in small blocks of time called sprints? They have fancy boards with kan-bans and burn down charts? They talk of user stories, planning poker and a product backlog? They practice pair programming, daily stand ups and retrospectives? Well all of those items could be considered agile practices, but for me it is simpler than that. You need to have an agile perspective, and the Agile Manifesto sums it up perfectly. Let’s look at each of the items in the manifesto in turn:

Individuals and interactions over processes and tools

Let me say that again, individuals and interactions over process and tools. Lots of those so called agile practices that I listed before are aimed at improving the interactions, but really they are just processes and tools. A really subtle difference perhaps, but one that means so much in practice.

Working software over comprehensive documentation

We deliver a high quality product that in general works very well. However, where we lack documentation we are heavily criticized and the documentation is seen as the cure for all issues. “If only we had that documented then we wouldn’t have this problem”. I doubt it. People just don’t read! (

Customer collaboration over contract negotiation

One of the biggest reasons we became so successful was our ability to listen to our customers and offer them a solution to their particular need. We had no real need to check that our contracts were water tight (and many certainly weren’t) as they were rarely disputed. We now take contract negotiation very seriously.

Responding to change over following a plan

Being very flexible in our approach a plan was more of a conversation piece. Something to discuss, but rarely accurate as change was inevitable (and the right thing to do). Now a plan needs to be agreed and executed with change controlled and removed where possible.

The manifesto concludes that “while there is value in the items on the right, we value the items on the left more.”

If you placed the items in the manifesto on a large set of weighing scales, you would want the items on the left tipping the scales to the left. If you add more process and tools, more contracts, more planning, you need to also add more focus on individuals and interactions, customer collaboration, and more responding to change otherwise. It is all about getting the balance right.

Posted in agile, software development | Tagged , , , | Leave a comment

Geekup – Language Showcase

I was recently given the opportunity to be curator for the Nottingham Geekup community.  As a regular attendee for several years and previous speaker, I thought this was a great opportunity to give something back.

As curator, it was my task to find the speakers for the night and arrange the format.  That didn’t sound too hard and certainly not as nerve wracking as actually giving a talk myself.  However, once I’d volunteered I quickly realized that my pool of potential speakers was quite small.  Never mind, I only really needed to find 2 or 3 speakers so it shouldn’t be that hard.  Encouragingly, as I mentioned this need for speakers I quickly had 2 or 3 volunteer, but their talks didn’t fit into any kind of theme.

I was also determined to try and make the night a little different to previous events.  One item that had concerned me over previous months was just how forced the coding exercises had been.  I was pretty sure I didn’t want to involve any coding this time.

As time passed, I got more focused on finding a suitable format for the night and would need to let people know I needed them for a talk pretty quickly.  I also thought it would be a good idea to press home the benefits of attending geekup to my work colleagues.  I collected a number of talk ideas and asked my team to vote on the best ideas with the premise that if you voted for a topic you were also committing to attend.

A last minute suggestion of a “programming war” was voted the most popular, although a few people expressed concern around the adversarial language of such an event.

This changed the nature of the event completely.  Now it really only made sense that I ran the night completely and that it would be completely code focused!

In order to address some of the competitive nature of the event I rephrased it as a “language showcase” and focused more on learning than competition.  I also felt it important to try and do the coding a little differently than before.  Whilst we have done many coding exercises at geekup in the past, we hadn’t spent much time trying to analyze or compare results.  This became the focus for the night and also helped enforce the showcase part of the title.

Overall, I was pleased with the way the night went.  I really enjoyed hosting the night and seeing so many people engage with the problems and share their results afterwards.

If you want to take a look at the slides and try the challenge yourself then take a look here:

Posted in agile, community, software development | Tagged , , | Leave a comment

When People Leave

I’ve talked a lot about recruitment and hiring people in the first place, but what about when people leave?

How you deal with people when they leave, and in particular during their notice period, can have a big impact on how they remember you and your company.

Firstly, lets acknowledge that when someone tells you they want to leave it hurts. You may have known them a long time, considered them friends and offered them the job in the first place.  It feels like a huge rejection and you can feel foolish as if none of those previous experiences mattered.  This is a natural reaction, but don’t let it shape your actions.  Take a deep breath, bite your tongue and calm down.  It was probably a difficult decision on their part and they will appreciate a professional response. This is a stressful time, so taking any emotion away can be a big help.

Secondly, once the dust has settled, make sure you use the time that person has left with you wisely.  You need to make sure all the knowledge they have is not lost when they leave.  You should also try and learn the reasons for them leaving.  Whilst everyone is different, if there is something you can discover, improve and prevent others leaving then it is worth listening.  Again, take the emotion out of the situation, encourage an open discussion and don’t argue.  You may hear a number of criticisms of yourself, your colleagues and your company; this can hurt, but don’t react emotionally.  A bad reaction can simply end the conversation and prevent you learning any more valuable information.  Instead, you need to listen, take note and thank the other person for their honesty.  You don’t have to agree with the criticism, but you shouldn’t just dismiss it.

Whilst it always has an impact when someone leaves, by reacting in the right way you can at least try and get something positive from the situation.  Ex-employees can still be friends and may want to work with you again in the future if you handle this situation well.

Posted in listening, peopleware, recruitment | Tagged , , | Leave a comment