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:

GANNT1

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.

GANNT2

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 , , , , | Leave a 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! (http://uxmyths.com/post/647473628/myth-people-read-on-the-web)

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:

https://docs.google.com/presentation/d/1B_qr3G-4CkuqHuO_6W2HjDtJKi5F-tLpsZc_4ZaS96A/edit?usp=sharing

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

roadworks

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 , , , | 1 Comment