A Tale of Two Projects

Posted on January 15, 2011 by Big_GH

I’ve recently had the opportunity to be part of two similar projects each being run using a different methodology.

Both projects ran for a year, with the second project a continuation of the first. Let’s look at the various aspects and results of the projects before we look for some conclusions.

Methodology

Project A was run using an agile approach – 2 weekly sprints, with a demo to our internal customer and the rest of the company at the end of each sprint, careful time tracking, burn down charts and a project backlog were all used by the development team.

As the technology was new to the team a large part of the initial time was spent investigating and evaluating the technology. Many prototypes were produced to test the possible solutions and remove some of the risk. Once the favoured technology was chosen a few weeks were put aside to produce a small internal application. This proved both a useful demonstration of what could be achieved and as a way of getting lots of silly “first time” mistakes out of the way in this system rather than the production project. It was a great learning experience for the team and with the tight time scales and sense of achievement it was also the start of getting the team to gel.

Project B took a more traditional big bang approach. The year was divided up into 3 stages, development, alpha testing and beta testing. About 6 months was development, with 2 months for alpha and 1 month for beta testing. The remaining 3 months were allocated as contingency.

A lot of the risk was removed from this project as it was a continuation of Project A and so used the same technology stack.

However, the project did still push the boundaries of what had been previously achieved with a web browser so a number of investigations into technology were still required. These were largely done the same as before, but as there were fewer investigations to perform and the technologies themselves less of an unknown the investigations took less time than those in Project A.

Team composition

Project A was led by an experienced and senior member of the team. He was mainly tasked with the day to day management of the team and with removing any technical road blocks that might be encountered along the way. There were 3 other members of the team, one other experienced member of the team (but not rated by some of his peers) and a junior working on his first project in the industry. The final member of the team was a graphical designer, also working on his first professional role.

Project B was again led by an experienced and senior member of the team although not the same leader as in Project A. There were 3 others on the team, the same junior developer and graphical designer from Project A, but this time they had 1 years experience. The other member of the team was a developer with 5 years of experience and highly rated by his peers.

Outcome

Project A was considered by the technical team to be a great success. They had risen to the challenge of new technologies, new agile approach and new team members and had delivered a functional, stable and coherent software base that will be the basis for the next 5 years of development in this area.

Changes in direction, the need for sales demo’s and additional functionality were all handled with minimum fuss by simply adjusting the goals of the next sprint.

Unfortunately, the business side were somewhat disappointed with the project. They saw the project as being delivered too slowly, with little ambition and lacking innovation.

Project B was considered by the technical team to be another success, but lacked some of the pioneering spirit of project A. They just didn’t have the same buzz about them, the urgency was gone, it felt more of a slog. At the beginning of the project they had taken a small gamble by deciding to write a large part of the solution themselves instead of using the best open source component available. That gamble paid off – the end result was amazing, above and beyond what might have been hoped for initially. I believe this showed the value in trusting the team and allowing those individuals in the team to take that trust and deliver what they believed could be possible – the motivation from that trust and desire to be proved right is a winning combination (although they obviously need the skills as well).

As might be expected from a year long project the initial requirements changed over time. This was roughly catered for by the inclusion of 3 months contingency in the original plan. However, the resentment at being expected to somehow magic up additional functionality was stronger on this project, especially as the final deadline loomed and the contingency had all been used.

This time the business side were very pleased with the results of the project. They got the innovative update they asked for, with minimal interaction and monitoring of the development team and demo’s and project completion were all completed on time. They had even thrown some extra requirements at the team and were pleased that these had all been accommodated.

Summary

So what can we learn from this experience? My personal beliefs tell me that being agile is good and I’m not alone. In fact, the results of these projects just confirm those beliefs. Being agile allowed changes to the project to slot right in, with suitable discussions on the impact of making those changes in direction.

The feedback cycle was short – delivering a demo every 2 weeks was tough, but each time they made it they were rewarded with a sense of achievement and renewed desire to nail the next one.

The architecture of the project grew naturally without the need for lots of extensive design process up front (which to be fair applies equally to project B).

The risks were greatly reduced, by showing the project every 2 weeks, progress was known and the final deliverable could be shaped throughout the year as more knowledge was gained about the market, feedback from users was acquired and thoughts matured about what could be possible.

In comparison, Project B struggled with some of the changes in requirements. They were more focused on delivering what had originally been asked for and resisting change. It was difficult to have suitable feedback on the consequences of making changes to the requirements – the suggested changes were all good, so the main response was simply to suck it up! (They could have chosen to not deliver instead, but that wouldn’t really please anyone).

They lacked some of the buzz from continual pressure and regular small achievements which led to my earlier comments of the project seeming more of a slog.

The risk of delivering the wrong solution was large. With no feedback until the project neared completion, the end results could have been very bad. It was largely down to the skill of the team that they had a good sense of what was required and how to make it happen. That led them to make the right choices themselves and bring the project to a successful conclusion. However, they certainly suffered from the large amount of feedback that turned up near the end of the project and demanded their time exactly when they didn’t have any left.

Conclusions

One interesting observation was that the technical people involved in the projects all considered their projects successful. Does everyone in the team always think that their projects are successful? What would an unsuccessful outcome look like to them? Why were their thoughts on the success of the project different to the business side?

Firstly, this relates to something described in almost any discussion of projects – defining success. Both projects neglected to really define success from a business point of view. They had their own vision, but somehow project A failed to meet the success criteria of the business, whereas Project B didn’t.

Another area often talked about being key to success is communication.  In each project the communication within the team was excellent (although progress was less known in Project B so was harder to communicate).  It was the communication out of the development team that varied drastically between the projects.  It would seem that more communication is not always a good thing especially if the message being communicated is not what the recipient wants to hear.

In each project, the business wanted the project delivered earlier than the development team thought feasible.  Project B got this message out early, took the flack and then consistently stuck to the same completion date.  It got to the point where it became pointless for the business to ask for status as they were always given the same completion date.  The team either didn’t know their own status (which is a difficult thing to know when the project is so large) or would lie to the business about the true status.

Project A always knew their status and couldn’t hide it – every 2 weeks there they were showing the world what they had done.  This caused a biweekly reminder to the business that they weren’t getting the software when they wanted it and, as they didn’t always understand what they were being demonstrated, a lack of confidence in the team
delivering at all.  Accusations of a lack of focus on what was important (to the business instead of technically) and of not being committed to achieve were frequent.  A lack of understanding of the agile process caused friction with the business wanting a guaranteed
completion date and the team wanting a more free flowing let’s see how it goes and we’ll know when we’re done when we get there.  Perhaps I could have described the communication coming from the team as marketing.

Project B did a better job in marketing itself.  It gave the business what it wanted – a cast iron guarantee of delivery date (which wasn’t the date the business wanted and even the new date turned out to be bogus as they missed it anyway).  They then stuck to that date religiously demonstrating huge belief in their abilities and commitment to the cause.

Project A told the truth – they had no guarantees, but would work towards whatever they were asked to in the pursuit of an excellent product.  When everyone agreed the product was awesome (or had enough good stuff to be useful) the product could ship and the team could move to the next version or end the project.  This just didn’t work – the message was wrong, the target market was wrong, the success of the project depended on it and this mistake was costly.

So, I still believe in agile – even more so, but the results also don’t lie – Project B gave better business results than Project A (and when the business is happy then we are all happy).  My conclusions were also that the team in Project A didn’t do much wrong – they followed the agile advice – they involved the customer all along the way – but the customer didn’t follow the script.  The customer seemed annoyed that they had to spend time every 2 weeks seeing a project they wanted yesterday taking longer than they thought it should.  They didn’t appreciate the opportunity to steer the project, to reduce the risk and to develop great technology.  They were supposed to say “that’s great, I can use that now, that is so much better than projects I’ve been used to in the past”, but all they could say was “when will it be finished? I need it NOW”.

Do I really need to fix the customer?  Can we be agile without a customer?  Can we communicate better and get the customer on board?

Only time will tell.  We’ll carry on doing, evaluating, and trying to improve (or rinse and repeat as the TDD folks would say).

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

Unexpected Lessons in Project Management

Posted on November 23, 2010 by Big_GH

I found the following advice in the strangest of places – whilst watching Thomas the Tank Engine with my kids.

If you don’t want to watch the full episode, you can get the complete story line here, but I’ll summarise the important lesson contained within.

In this episode, Victor doesn’t want to upset the Fat Controller so he says yes to all the broken engines that need fixing even though he knows he hasn’t got enough time.  It is only when it all goes wrong and he is forced to prioritise and focus on the most important jobs that he becomes a “really useful engine”.

A useful reminder for all of us, and perhaps pitched at a level we could share with some of our more intellectually challenged colleagues.  😉

 

Posted in time management | Leave a comment

Staff Appraisals

Posted on November 14, 2010 by Big_GH

It’s that time of year where I need to appraise all my staff and present recommendations to the board on any adjustments to their job roles and salaries.  I thought I’d use this post to collect my thoughts on how I do this and as a trigger to improve it in the future.

So, first let me outline the process we currently use.  Once a year (about now) I meet with each member of my team and we discuss the following items:

  1. What have you enjoyed the most this year and why?
  2. What have you enjoyed the least this year and why?
  3. Have your skills changed or improved this year and in what way?
  4. Has your role or level of contribution to company performance changed over the year, i.e. do you have a greater level of responsibility?
  5. How would you compare yourself to others performing the same role as you?
  6. How could the company help support you?
  7. What objectives / targets are you setting yourself for next year?
  8. Any other items to discuss?

I allocate about 45 minutes to 1 hour for each person and make notes as we go through each area.  I try to spend more time on the areas that are relevant to that person rather than trying to force the conversation into areas that we have nothing much to talk about.

I try to answer those questions myself for each person before they arrive, so that I also have my own agenda on what we should be talking about.  I don’t let that override what my team member wants to talk about, but it does help me keep the conversation moving and can be a topic of discussion in itself.  Any time my own thoughts don’t match the thoughts of the person I’m appraising, I need to consider why?

I generally need to look at one of these reasons why:

  • I’ve not noticed the changes in my staff and have carried over old ideas of them.
    I quickly need to re-adjust my views and stop previous thoughts about that person clouding my view of them now.
  • I haven’t been providing enough feedback throughout the year.
    One of the main criticisms of staff appraisals is that they too often provide surprises.  There shouldn’t be any surprises in an appraisal so if someone doesn’t already know my thoughts on their performance I have been lacking during the year.
  • We simply disagree on that person’s performance
    This can be the biggest challenge, and again is one of the main criticisms of staff appraisals – even the worst staff think they have done well and don’t take being told otherwise very well.

I pay particular attention to questions 3, 4 and 5 as they are the ones I use to recommend any adjustments in salary or changes in job title.

The other questions are great at providing feedback on what I need to do as their manager.  If they are not enjoying the tasks I am asking them to do, I need to find other projects to challenge them or explain why they are being asked to do these tasks and offer a time scale to change.  If they have good suggestions for improving the company I need to do my best to implement them or push for those changes on their behalf.  If they have targets they want to achieve I need to help remove any obstacles that might prevent them from doing so.

I also like to include a chance to take the conversation away from the agreed agenda.  This  can throw up some interesting discussions, and again can be useful in providing feedback on how I should manage that person moving forward.

So, does it work?

To be honest I’m not sure.  On one hand, I think it is very important to reflect on past performance and think about what you’d like to do in the future.  It’s also important for a business to assess the value for money their employees are providing and to make sure that the right people are rewarded.  On the other, I agree with the idea that a performance appraisal is a terrible tool for increasing employee performance (see Joel’s post Incentive Pay Considered Harmful or this article on About.com).

Hopefully we avoid some of the pitfalls by not directly focussing too much on performance in the review and instead focussing on what we can achieve together.  However, we are still linking salaries to the reviews and that is certainly an area I am less comfortable with and would most like to address in the future.

Posted in listening, motivation, peopleware, software development | Leave a comment

Thoughts behind Project Management Alchemy

Posted on November 14, 2010 by Big_GH

I had intended this follow up to Project Management Alchemy to be written a little quicker than it has been.  However, my work has taken me on a couple of foreign trips (to Copenhagen and New York) and my free time has been taken up with preparing to be a best man at my friends wedding.  Now that those are done, I can get back to this post.

So let’s get straight to the point, why did I write Project Management Alchemy?

It seems that some of the practices I described previously are either well used in the industry, or considered the “right” way of managing projects – perhaps considered is a little strong, maybe others just aren’t thinking and so are lazily following poor practices or finding a path of least resistance.

When I have tried to see a different point of view, I haven’t been able to find anywhere that describes the practices I included in Project Management Alchemy.  By collecting those ideas into a single place, I hoped that it may form some kind of “honey pot” for people searching for ideas that match their own.  If I can improve the practices of just one person it will have been worth it. 😉

In fact, there seems to be so much good advice out there and that advice is often repeated, it didn’t really appear worth my while regurgitating it back again on my own blog.  Instead, I tried to create a little humour and recommend against the usual advice.

Having just told you what a waste it is to repeat the usual advice, I’m now going to do just that.  However, I’m not going to comment much as most of the links speak for themselves (and the original authors get their point across better than I could anyway).  I’ve grouped the links into categories for an easy quick reference to various parts of a project and have put the page up here.  I intend to update this page as my ideas grow or change or I find new links that I’d like to share.  Please feel free to suggest anything you might find as well.

Posted in estimates, listening, motivation, peopleware, planning, process, reading, software development | Leave a comment

Project Management Alchemy

Posted on September 28, 2010 by Big_GH

In this post I wanted to share some of the magic tricks I’ve picked up over the years that can help turn even the worst projects into golden triumphs.  In this day of software development and virtual worlds we can achieve what the original Alchemists could only dream off – we can turn lead into gold.

Firstly, don’t bother with trying to estimate the size of a project – it will be wrong anyway.  Simply pick a date that suits you and convince everyone that that date is the end of the project.  If you are finding it hard to persuade people that this is a winning start to a project, try pointing them to information about the “Project Management Triangle”, such as this article on Wikipedia.  Even better, simply explain that as part of the project management triangle you can achieve any timescale by moving the other 2 sides of the triangle – cost and scope. The trick here is to win the argument on timescales without compromising the amount of people on the project (cost) and what you wish to achieve (scope).

If your team still won’t accept being told when the project must be finished then maybe they are particularly bright or actually read up on the project management triangle as you suggested.  In this case, you may need to provide a little more justification for your timescales, which means producing a project plan with tasks and estimates in it.  Some people recommend asking the person who is going to be performing the work how long they think it will take to complete.  In his article on Evidence Based Scheduling Joel Spolsky notes

“Only the programmer doing the work can create the estimate. Any system where management writes a schedule and hands it off to programmers is doomed to fail. Only the programmer who is going to implement a feature can figure out what steps they will need to take to implement that feature.”

However, unlike Joel’s usually sound advice, I find asking the developer to estimate the work just distracts them from actually doing their main task of writing software.  After all, you are the manager of the team, dealing with schedules is your domain.  So, crank open your favourite project planning tool – Microsoft Project is highly recommended, and start filling in some tasks with some estimates.   You’ll probably find that based on the tasks you can come up with and your first guess on how long those tasks will take that your project is not going to be ready when you want it to be.  Don’t let that put you off.  Simply keep adjusting tasks, remove a few, reduce the duration of a few and manipulate away until you have the date you were looking for.  Remember, this is why you are paid the big bucks – scheduling is hard and requires tough decisions to be made to reach the target date.

So, we now have the first steps towards a golden project.  We have a suitable end date that will make everyone happy, and we may also have a plan that proves the date is realistic.

Now we need to make sure the developers stick to the plan.  After all you didn’t spend all that time making it look pretty for it to be ignored.  Here’s the next tip – status meetings.  Weekly updates where the whole team gets together and sits around a table discussing progress with you.  I find it works best if you ask each person in turn for their status and force the rest of the team to listen.  This is a great way to get honest feedback and build team spirit.  It also keeps the pressure on everyone to provide positive feedback – no-one wants to be the person bringing bad news to the meeting and so your milestones will pass by on time all the time.  Don’t let these people put you off when they suggest the round-table meeting as being a waste of time:

Ok, so we all know that software projects slip.  Developers just aren’t as motivated as Sales guys when it comes to targets, so sometimes they need a helping hand.  You have two choices here – a carrot or a stick.  The carrot works in Sales so it must also work for developers – offer them a bonus.  That one is easy, finish on time and you give the team a bonus.  However, that can be a little expensive, especially if you need to do it on every project, so you could also try the stick approach.  Who doesn’t work harder when they’ve been shouted at?

Right, so we are nearly there.  Here’s a quick recap on what we have so far:

  1. A winning plan or end date
  2. Great estimates
  3. Weekly status updates that show that the project’s on track
  4. Bonuses for finishing on time or the threat of a good boot up the backside to keep the motivation high

So, here’s my final piece of advise.  If you are really unlucky and your project is still not progressing as you’d like (or you’re just aiming for the stars and want to bring your project in early) then you can try this final killer tip – Overtime.  You can accomplish almost anything with Overtime – it’s your time to use, as and when you require it.  If your team comes up with an extra task that you somehow overlooked in your plan – simply get it done in overtime.  If the team starts complaining about the schedule point out how many extra hours there are outside of the 9 till 5 and during the weekend.  Don’t be afraid to tell them how hard you work and the extra hours you put in answering phone calls, writing emails and fiddling with the plan.  Don’t let them tell you that working more than 35 to 40 hours a week is unproductive – that couldn’t possibly be true – more hours means more work gets done, after all you have the plan in MS Project and if you put in more hours the progress moves up a few more percent.

For anyone who’s got this far and not found any irony in what I’ve written, I’ll be adding a new post soon that explains more of the thoughts behind “Project Management Alchemy”.

Posted in estimates, humour, planning, process, software development | 1 Comment

Interview Anecdotes

Posted on September 14, 2010 by Big_GH

I thought I’d capture a few of the funnier things that have happened in the interviews I’ve conducted.  It is quite amazing what people will say under pressure!  This isn’t meant to come across as laughing at other’s misfortune, but a light hearted look at what can happen in a stressful situation.  I do genuinely appreciate the time that people put in to attend an interview and would like to be able to help everyone who I meet, but unfortunately that isn’t possible.

I was interviewing for a programmer in our support team and having asked them to describe something they enjoyed working on, I asked them for something they didn’t enjoy.  The answer – working in support!

It seems this is a question that a few people don’t expect.  Having asked someone else about something they didn’t enjoy they decided to tell us about the time they swore at their manager.  They then swore at themselves in the interview for mentioning it!

One guy had mentioned he’d been having a bad week, but I thought nothing of it and didn’t ask further.  Before the end of the interview he explained that having been made redundant a month ago he was enjoying his time off and wasn’t looking to rush back to work as he had plenty of savings.  He then elaborated on his bad week – the day before the interview his wife had left him and emptied his bank account!  He was now looking for work pretty quickly!

After one of the programming tasks, a candidate asked whether we set all our programmers the same challenge and whether any of them had completed it.  Remember this is a 10 line program that most people should be able to write as quickly as they can type.  When I told him that we do use the same challenge, he replied “Wow, you must have some clever guys working here!”.  We do have some clever people, and hopefully my recruitment process will help keep and attract other clever people to join us.

Posted in humour, recruitment, software development | 1 Comment

Interviews

Posted on September 7, 2010 by Big_GH

Following on from my last post on applying for jobs, this one discusses the interview process.

Firstly, something that continues from the application process is the desire for success.  I don’t like seeing the candidate fail.  I really want to see each person succeed, I want to fill the position.  I don’t want to have to re-advertise, sift through another pile of CVs, and spend days interviewing.  If I find the right person I can stop and get back on with my day job.

I always try to find something in the interview that mimics a task they might do in their job.  For programmers that means they must write some code.   For testers, they need to spot the bugs.  It always amazes me how many candidates fail these tasks.  These aren’t even difficult tasks, the code they need to write is little more than a loop and a few conditionals, the bugs the testers need to find are not exactly hidden away either.  So why do so many people fail in these tasks?

How can they have made a good career in the industry (I’ve recently been interviewing people with 20 years experience on very good wages) when they can’t write a 10 line  program?

Is it just nerves?  Sometimes I think nerves can be an issue.  Most of the time our work is not done under the same pressure as an interview.  I have worked at times where the pressure is far worse, but generally it isn’t and you have the support of a team to help you out.  Working
with some good colleagues can go a long way to taking the pressure off and so remove any nervous feelings, but in an interview you are on your own.  I try to be encouraging, have a conversation rather than an interrogation, and get the candidate in the right frame of mind before we set them the task.  Sometimes that works, sometimes not.

So what else is it?  Is it the support of the team that does it?  Do poor performers get a job somewhere less stringent in its recruitment process and then use their team to prop them up?  Do large companies not understand the performance of their staff so even the incompetant ones survive?  Is employment law so strict that companies prefer to keep poor performers employed than face the issue of dismissal? Or could it be that I have my process wrong?  Am I rejecting perfectly good candidates because they can’t pass my made up criteria?

I don’t have any answers to those questions and in some ways it doesn’t matter too much anyway.  I do manage to find good people using my process, and if I miss a few along the way then never mind, they will do well elsewhere.

Posted in recruitment, software development | 5 Comments

Job Applications

Posted on August 31, 2010 by Big_GH

I’ve been doing some recruiting recently and have been disappointed with the standard of many of the applicants.  I thought I’d offer some guidance as to the things I would expect as a minimum from anyone applying for a job.

Firstly, if the job advert asks for a covering letter then you had better send a covering letter with your CV.   From approximately 120 people applying only around 40 people followed this basic request – the rest of them went in the bin.  Don’t waste your time (and mine) applying if you can’t even follow these basic instructions.

Secondly, don’t send in a CV or covering letter with spelling mistakes in it.  I’m sure that a spell checker is something anyone working with computers is familiar with, and has access to.  It’s not that hard to read through your application before you send it – so do it.  You can
get away with a couple of typo’s, but any more is just sloppy and who wants to work with someone who is sloppy?

Slightly less obvious, but none the less important, is that if you don’t match the requirements for the job perfectly, you need to address the areas you are lacking and emphasise your strong points in the application.  This includes modifying your CV to fit as well.  I’ve seen a few applicants write me a wonderful covering letter, but then send me a CV that doesn’t match what they’ve just said.  Here’s a secret that I don’t think they told many people at school – it’s OK to have more than 1 CV.  In fact I’d recommend having a different CV for every job you apply for.  Perhaps that means keeping one huge CV that you can cut and paste from each time.  The reason for this?  That is covered in my next point – providing evidence.

When you’ve read hundreds of job applications, some of them can start to sound the same.  Many people think that just saying that they are “hard-working”, “an asset to the company” or other such generic platitudes is enough.  Let me tell you it isn’t!  It all sounds a bit hollow and ultimately disappointing when you can’t find any evidence.

Here’s another secret they don’t tell you at school.  I really want you to succeed.  If I could open every application and conduct every interview knowing that every person had ‘passed’ my criteria it would make my life easier.  I have a genuine need to add some more people to
the team – I want to find a superstar and get them started as soon as possible.  Rejecting people is no fun and my team suffers from being understaffed in the mean time.

Finally, keep it brief.  You might be proud of the intricate design of all 27 products you worked on, but I don’t have time to read them all.  Tell me the things I’ve asked for on the job advert and not a lot else.  As I said before, I want you to succeed, and as any good programmer knows there can’t be bugs in code that doesn’t exist.  In the same way, you can’t put mistakes into words that aren’t there.  It is possible to say too little on your application, which is why you need to address the items that have been requested on the advert, but any more is usually just a waste of time.  I want to put your application in the ‘interview’ pile as soon as possible, don’t delay me with stuff that isn’t relevant.

I see applying for a job as a bit of a game – or as one person who I recently hired said

“It’s a dance.  You need to know the right moves, when your partner sways one way, you  sway with them.  When they sway the other, you again move with them.  The movement  must be coordinated otherwise it just looks wrong.”

I make the first move with the job advert.  I put the criteria in place for the application – how to apply, the skills and experience I am looking for.  You then need to respond, dance to my beat, follow my lead, sway with me.  Send me a covering letter, an error free and targeted  CV that shows me why you are right for the job.  If you do your own thing it will look like you are dancing to a different tune – and that’s an embarrassment that no-one wants!

Posted in recruitment, software development | 6 Comments

The Bradford Factor

Posted on August 13, 2010 by Big_GH

As you may have picked up from my last post, I am a Bradford City fan having spent 13 years of my life growing up in the city.  However, this post discusses the Bradford Factor a method recently introduced at my work to provide insight into staff absence.

Its calculation is very simple. Take the square of the number of times a person has been absent from work (S) and multiply it by the number of days they have been absent (D):

B = S^2 \times D

Anyone scoring above 125 over a period of 1 year should be investigated to find out why their score is so high.  Anyone with a score over 500 could face disciplinary action.

So what does that look like for an average employee.  From this article in The Times last year it describes the average private sector worker as having 6.4 days off in a year.  We don’t know how those 6 days are spread, but lets take a look at a few scenarios:

Taking 1 day off 6 times in the year:

B = 6 x 6 x 6 = 216

Taking 6 days in 1 go:

B = 1 x 1 x 6 = 6

Taking 2 days off 3 times over the year:

B = 3 x 3 x 6 = 54

Hmm.  Is that right?  If I have (slightly less than) the average number of days off in the year, but I do so in 6 episodes I will be investigated and have to explain why I have been missing from work.

At the heart of the philosophy of using the Bradford Factor is that it is frequent short absences that are the most disruptive.  That may be true in some sectors, especially where alternative cover must be found, but what about software development?

In my experience, the longer the absence the more disruptive the absence is to the project.  Missing a day on a software project is rarely an issue, but missing a week can destroy its chances of success.  If a software developer has to spend the day at home ill, they are usually so involved in the project, the challenges, the technical problems that need solving that they still spend their time thinking about the project.  This thinking time can still count to the project – after all, the job of developing software is mainly thinking not typing on a keyboard.

Conversely, the longer the absence the more the project fades from memory.  Less thinking can be done to move the project on as the current challenge that was fresh in the mind will either fade or will already have been addressed in thought.  No new challenges are going to  arise without actually trying out the thoughts with new code.

So, in conclusion, please don’t try to make a simple maths formula tell you how to treat your software developers.  They are usually highly intelligent, highly motivated and will be absolutely horrified and offended by the implied accusation that they were taking time off when they didn’t need to.

Posted in peopleware, software development | 5 Comments

Essential Listening 1

Posted on August 13, 2010 by Big_GH

Following on from my reading list, here are the podcasts I listen to:

  1. Hanselminutes – Scott Hanselman talks tech.  He keeps it fairly lightweight and doesn’t get too deep in programming jargon.  The audio is good quality and he gets the most from his guests so this is always worth listening to.
  2. The Startup Success Podcast – Aims to give all information for other startups, but tends to mainly be interviews with other startups giving them the chance to showcase their offerings.  Interesting discussions on how they came up with their ideas, the technology they use and their future plans.
  3. Deep Fried Bytes – Keith and Woody also talk tech, but in their Southern American style.  I’m starting to be a but more selective with this one, so don’t listen to all their shows.
  4. Herding Code – Done by a group of programmers who can get quite involved in the details of the tech they are talking about.  Audio quality sometimes not so good and the topics can drag if they aren’t immediately of interest.  Again a podcast to be selective with.

I’m also going to check out Bantams Banter, but unless you are a Bradford City football fan you probably won’t enjoy this one!

Posted in listening, software development | Leave a comment