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

Building Roads


We are often told when managing software projects that things should be more predictable, more repeatable and that our projects are less in control than others.  As we saw previously, I’m not convinced.

I’ve been watching with interest over the past few years as a major road upgrade has taken place near my home.  This was a 3 year project to convert a single carriageway into a dual carriageway and involved rerouting the road, creating some new roundabouts and bridges – including one that carries a railway line.

Overall, I’d say I’ve been reasonably impressed with the way this project unfolded.  It started on time, appeared to progress on schedule and was officially opened on time.  However, whilst the signs along the road side state that there would be disruption until Summer 2012, we still have cones along the roadside and overnight closures of certain sections.  I’d say that this project is definitely not complete!

So what happened?  And what can we learn about our own projects here?

Firstly, predicting timescales on any large project is hard.  The combined uncertainty of so many tasks can add up to make predicting an end date more of a guess than a science.  It was interesting to see that the end date they used on the road signs was Summer 2012, not 5pm on 1st June 2012.  Communication of end dates can be a useful way of inferring confidence, stating Summer 2012 shows the wide range of possible end dates that might be acceptable and shows the uncertainty with a lack of precision.  I have no doubt that a project manager somewhere will have sat down with a tool such as MS Project and will have added all the road building tasks onto the plan. Fortunately they avoided the trap of using the dates in that tool as the dates they communicated.

I also noted that at certain times of the project, they could predict with great certainty when parts of the road would be closed.  Signs would appear warning of closures for the following week.  Again, underlining the ability to predict with some certainty events that are close by (although even then sometimes the roads didn’t close when the signs said they would and the next day the sign would be updated with a different closure date).  This ability to predict close events with some degree of accuracy and further events with less is described as the Cone of Uncertainty.

Secondly, defining when a project is done is critical.  When upgrading the road, the definition of done seems some way off my own definition of done.  They officially opened the road on time, so perhaps they were happy with their definition of done, but as someone who drives on that road, I am not.

I have no idea why work is still being done on the road.  The road is functional, it has lines painted and lights on the side, so you could argue as version one it meets the Minimum Viable Product we might release as a software team.   A lot of traffic is using the road, so they are clearly providing value by “releasing early”.  Perhaps they have simply entered a maintenance phase, maybe they are taking the opportunity to reduce their technical debt.  Whatever it is, I just wish they’d hurry up about it!

Posted in agile, estimates, planning, Project Management, software development | Tagged , | Leave a comment

Speed vs Predictability

Understanding which trait is most important to a project can be a big factor in whether that project is seen as successful. It can also help determine the best way to “manage” a project (in a “project management” sort of way).

A traditional waterfall approach to a project can attempt to restrict change and so looks good from a predictability point of view. We know the requirements up front (or think we do), we have a design we have signed off on, we can therefore know with some certainty the end date for this project.

When it comes to speed though, a waterfall approach has some issues. Firstly, there’s Student Syndrome to consider – the fact that many people will only start to fully apply themselves to a task at the last possible moment before a deadline. This can lead to wasting any buffers built into the original estimates and helps to explain Parkinson’s law – work expands so as to fill the time available for its completion.

Waterfall plans tend to have larger tasks on them with deadlines that are further away. Even if the work is broken down the focus on phases tends to be larger. For example, even though I know I should complete my task today, I know that it only really matters in 3 months time when this larger phase has a deadline. I can convince myself that things will get better, I will get lucky with the next task and so I can catch up.

Agile approaches focus more on embracing change so can appear to be less predictable. We don’t really know what we are creating or when it will be ready, but you will have an opportunity to really shape what we develop incorporating the best ideas of the time and deciding when we have enough value in order to release.

The Agile processes of daily standups(or scrums) and short sprints create a culture of constant targets and could be seen as a way of speeding up development. There is little scope for either Student Syndrome or Parkinson’s law to take effect here. Daily standups attempt to break down that large task we might have had with a waterfall approach and turn it into smaller daily commitments. By setting a daily target, apathy is never allowed to set in.

However, it is also this practice of daily commitments which could be seen to force teams to aim lower than they would normally. Rather than saying “I think I would like to get this done if things go well”, the group aims instead for a commitment – “I will definitely get this amount completed”. The very nature of it being a commitment means less is targeted and anyone attempting to commit to more than seems reasonable is questioned by the team.

This same thinking can also be applied to the “sprints” that an agile team will take part in; they could be seen as less like sprints and more like strolls as the amount they are “sprinting” for is reduced in scope in order to achieve a commitment. That’s not strictly true, a team should be tracking velocity, taking items from the backlog to fill the sprint and adding items that weren’t completed to a future sprint. However, teams and perhaps more importantly their stakeholders want commitments. Even if it isn’t seen as a commitment by the team; the innocent question at the start of a sprint “what can I expect to see in the product after this sprint?” can lead to an unspoken expectation of a commitment.

However, if a team constantly meets its daily commitments (or sprint objectives) then it is going to be more predictable, which could be seen as more valuable in some projects.

As a thought experiment, let us consider a task so important that we need to devote every single minute of our time to completing it. Surely, this is the route to completing it as soon as possible. Stopping work for a daily standup isn’t going to help us progress this task. The standup does offer the chance for the group to offer assistance in creative ways; perhaps someone else has already solved the problem you need to solve in another project, perhaps someone else is available to look at the problem with you and remove the blockages that have slowed your progress, perhaps the task can be broken down and worked on in parallel. So, the standup is a bit of a gamble, if nothing changes, the time is wasted, but you could save time on your project by attending.

This is one of the reasons the standup should be as short as possible; for all those people attending and taking the gamble that they will get a benefit from being there, if the gamble doesn’t pay off then the loss should be as small as possible.

By reducing scope a little with the daily commitment the group increases predictability, but also has a little spare capacity to help those people who might not make their commitment. A bet that will nearly always pays off is a very attractive proposition, and I think is one of the most powerful aspects of a daily standup.

I don’t think there is a simple answer to the question of whether speed or predictability is more important, but I do know from past experience that choosing the right approach is very important.


Posted in agile, planning, process, Project Management, software development | Tagged , , , , , | Leave a comment

Recruitment Talk

I’ve written a few times about recruitment.  In particular you can read what I had to say on Job Applications and Interviews.  There are even some amusing stories from my Interviews.

This time I’d like to share a talk I did for GeekUp Nottingham (@geekupnotts) which was all about hiring and getting hired.

You can watch the video below or view my slides here.  You probably want to skip the first 18 minutes of the video (it was being streamed live, but we had a few technical issues getting started).  The excellent @samwessel is the first speaker, well worth a watch.  My talk doesn’t start until about 52 minutes in.

Posted in community, recruitment | Tagged , , , | 2 Comments

Progress – Part 3 (What still needs improving?)

In the previous parts, we looked at how things used to be in the development team, and then looked at how things are now.  This time, lets look at the areas that still need improving.

As a small company trying to get started, it was important that we used our ability to react quickly as one of our strengths.  Speed was very important in the development team, but one of the ways we achieved that speed was by taking on technical debt.

Now that we are larger, speed is less important and quality and predictability are the main requirements.  Our software code base is larger and areas of inflexible design have surfaced.  We need to re-factor into smaller replaceable components so we can keep the product fresh and modern.  We can count this as another of our areas of technical debt that we need to reduce.  We need to find ways of reducing our debt whilst maintaining our ability to ship real benefits to customers.

One of the main techniques we plan to use to improve our quality and reduce technical debt is Test Driven Development.  We’ve been keenly watching the Uncle Bob – Clean Coders videos as his use of TDD has been a revelation.

As a test team we haven’t made as many changes as we could.  We have started the process of automating our testing, but too much is still manual.  We spend a long time with our regression tests; often not finding any bugs, but using as much as 2 weeks of our time.  When we’re aiming for a monthly release cycle (or shorter) this is more than we can afford.  It was noted from hearing Uncle Bob talk about his work on FitNesse, “if the tests pass, we ship”.  That has to be our goal as a development and testing team; having such a comprehensive set of automated tests, that if they pass, we ship.

A constant battle in project management, between stakeholders and the project team is in understanding when a project will be complete.  Agile methodologies attempt to address that issue, by offering a new version regularly and letting the product owner decide when a version is complete enough to ship.  However, unless the whole business is truly agile, then this doesn’t really work; marketing want to announce what’s coming for the next year, and expectations are set with customers.  No-one wants an estimate or to be told to wait 2 weeks at a time to see if the system is what they want.  What they really want is a commitment!  So whilst we can work in 2 weekly sprints, and can release software to our customers monthly, we need to plan for something like quarterly commitments.  To have any chance of keeping these commitments, we need to use some of the more traditional project management tools to manage change (and restrict it).  We need to remove risk, and we need to estimate the size of tasks more accurately.

Whilst our stated aim has been for a monthly release, these have been stretching out to nearer 3 months and that starts increasing the pressure to delay the next release.  No-one wants to take the risk that if their sponsored feature misses the current release that it will then be a further 3 months before it can be released.

One of the tools that we can use to change this is to make our behaviour visible.  We have started to track our key metrics, what date are we aiming to have developed all our new code for?  How many features and fixes are still in development?  How much have we already passed to the test team?  Once we have this information, we can measure our progress, track our confidence for making the release and then adjust our plans accordingly.  By using a daily stand-up with the key members of the team, we keep visibility and remind everyone of our targets.  We can also display these metrics in a public place so that everyone is aware of them.

One of the thought experiments we can run is to find out which parts of our process would stop us releasing software on a weekly basis.  At the moment that is our manual testing, but as we automate more of that we should keep our eyes on what else might be slowing us down.  If we get to a point where we could release weekly, then the next step is to look at what would prevent us releasing daily.

One of the big benefits of a daily, automatically built, tested and ready for release version of our software would be within our support team.  Our support developers still spend a lot of their time producing hot fixes and sending them to customers.  These are manually built, put together and tested by the developer who made the code change.  Automating this process would free up more time to help other customers and reduce the occasional mistakes we make following this manual process.

If you’ve followed all 3 of these posts on progress then hopefully you’ll have seen how far we have come as a team; from sound principles, but poor practice, to a more modern approach with a vision of where we still need to improve.  It really is a credit to the team members, both past and present that have helped drive the change whilst maintaining a high quality product for our customers to use and our business to sell.


Posted in estimates, peopleware, planning, process, Project Management, software development | Tagged , , , , , , , | 1 Comment

Progress – Part 2 (How things are now)

Last time we looked at how things used to be within my development team.  This time, let’s look at how things are now and some of the improvements that have been made.

We now have 3 broad teams of developers, each team with its own focus.  Within the teams we still have many smaller projects in progress, often with just a single developer working on their own.  The teams are focussed on front end / user interface developments, back end / 3rd party integrations, and customer support.  We’ve introduced a variety of languages into the product – we now use Python, C#, Silverlight and Javascript instead of just sticking with C++. Some people have started to specialise within those teams and our user interface team now includes a graphic designer – we include “user experience” as a serious part of our process.

By splitting the developers into these teams (and putting them in different rooms) we manage to focus on all areas of our product.  As we saw last time, with everyone in the same room and no defined roles, we only managed to focus on the current interesting issue within the team (usually whoever had just phoned with a problem).

Our release schedule is more defined.  Partly in thanks to Johanna Rothman’s book Manage It! we realised that in order to challenge our failure to release every year, we needed to shorten our release cycle not extend it.  We now aim for a monthly service pack release, a quarterly feature release and a yearly major upgrade.

This change in release cycle forced us to address our build and release process.  We now run an automated nightly build via Teamcity.  This also allows our test team to always have something to test, rather than waiting months between builds.

Our source control also needed to change, and we got good mileage from a switch to subversion.  However, it recently became apparent that we needed more flexibility in our branching strategy to cope with the different team goals and release cycles, so a switch to distributed version control is well underway.  As we were already big fans of Fogbugz, we decided to try Kiln, which is based on Mercurial.

Fogbugz is the hub of everything we do in development.  We track every change to our product through a case in Fogbugz, every change is proposed, reviewed for acceptance, implemented and then tested.  Fogbugz produces the output for our release notes (which now accompany every release, with every change noted), and contains a wiki of all the really useful information we want to share as a team.

We now have a dedicated team to handle incoming support phone calls and email, so developers no longer have to do this.  Whilst Fogbugz did a great job of handling those incoming emails, it wasn’t structured enough for the support team to figure out how to use it effectively enough – a wiki was just too general to store the information the support team required.  They have now switched to using SuperOffice, which does have the advantage of being the same system that the sales team uses.  As a database of customers, their equipment, previous support issues and maintenance contract details it excels.  As a piece of software to use to drive your daily tasks (handling support) it is one of the worst combinations of technology and user interface design I’ve had the displeasure of using!

As well as adding a dedicated support team, we have also increased the number of people in our testing team.  With a daily release available the test team always have something to test.  They have also improved the way they test.  They have more representative hardware available and focus on finding the faults our customers care about.  They also now test whether our software will downgrade as well as upgrade.

As well as improving the hardware available to the test team, the hardware available to the developers has also improved.  Dual (or even triple) screen setups are now the norm.  We have laptops available for each person who wants their own, whilst we still have a few available to share for occasional use.  In fact we have a dedicated budget to spend on whatever equipment or software we need as a development team.  We now use Visual Studio 2010 or Komodo as our IDE with tools such as ReSharper, NCrunch and Visual Assist X available to help and are constantly looking at new ways of improving our development environment.

Our physical working environment has also improved.  We shuffled people around into different rooms to help keep the teams focussed.  We even managed to build a partition wall to divide the largest and noisiest of our rooms down into two smaller and therefore more focussed work areas.  Our tired, old, straight-edged desks that had served us well for 15 years were replaced with modern curved desks that all matched.  With a more consistent look to our desks, we were also able to add matching book cases, cupboards and storage space.  With the disruption of changing furniture we also took the opportunity to bring decorators in to repaint the walls and brighten our working environment.

We now have a budget for training.  This allows us to purchase almost any book we think looks interesting, but also allows us to purchase training videos, go to external training courses and attend conferences.  This year we’ve had people at DevWeek 2012, ACCU and Usability Week as well as regular sessions for the whole team to watch Clean Coders.  It’s not just having a training budget that helps with training, but a general increase in the importance of training.  We now run regular Coding Dojos to practice and improve our skills and look at other free ways of improving.  We believe that Practice is important.  We are also far more involved in the local developer community.  We always have at least a couple of us at the monthly Geekup meetings – watch out for me giving a talk at one in the future!

Over the years we’ve doubled the size of the team.  Whilst bringing in new people brings in new ideas, it is important that those people are at least as talented as the current team.  Our previous interview process was very hit and miss, and whilst it certainly isn’t perfect now it’s definitely improved.  We now put ‘juggling‘ at the heart of our interview process with a series of simulations to try and identify if the candidate can do the job.  We still keep the interview friendly and fun, but we do need to know that the person we are interviewing can do what they say they can.

Whilst we can be very proud of the progress we have made, there are still lots of areas we can still be improving.  Let’s look at those areas next time.

Posted in information, planning, process, recruitment, software development | Tagged , , , , , , , | 2 Comments