Building Roads

Posted on May 14, 2013 by

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 software development, planning, estimates, Project Management, agile | Tagged , | Leave a comment

Speed vs Predictability

Posted on April 9, 2013 by

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

Posted on March 17, 2013 by

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 , , , | Leave a comment

Progress – Part 3 (What still needs improving?)

Posted on March 14, 2013 by

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)

Posted on November 30, 2012 by

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

Progress – Part 1 (How things used to be)

Posted on October 23, 2012 by

I started as Software Development Manager about 5 years ago and I’d like to share some of the changes that have occurred since then.  Some of those changes I’ve worked hard to create, some were pushed by others within the business, but collectively I believe we’ve achieved a lot.

So, let’s start with looking at how things used to be in the development team…

We aimed to release a new version of our software every 6 to 12 months.  This involved collecting a big list of requirements and dividing them up amongst the team.  However, what actually happened was that we started with more than we could do.  This was fuelled by a business need to aim high and stretch ourselves.   As the months progressed we picked up more “must do” requirements that we added to the next release and before we knew it our release had taken 18 months to finish!  We often delayed a release whilst we waited to complete something that no-one actually wanted.  The pressure to delay a release while we added something new just got bigger the longer a release was delayed – if the next release was going to be a year away, we couldn’t possibly wait, so it was better to delay the current release a few more weeks whilst we added that item.  A vicious circle of ever delayed releases was created and getting to “done” was extremely difficult.

Not only was this bad for morale, it was bad for our own processes.  As we didn’t have an official release of software we would send out builds done from a developers PC that included the bits a particular customer required.  As you can imagine, trying to keep track of who was running what and supporting our customers was very problematic.  No one had a standard, official release of software so we relied on knowing each customer’s quirky software versions.

This was only made worse by the tools we used.  We used Visual SourceSafe for our version control.  Now it was always pretty reliable for us so I don’t wanted to knock it too much, but it didn’t help us branch and merge our software to handle our various customers and changing requirements.  It was definitely not helping us, but at least we didn’t suffer from some of its well known limitations.  We had outgrown it and needed more if we were to improve.

As I mentioned we often released software direct from a developers PC.  Again our tools did nothing to help with this.  We didn’t have a dedicated build machine (well that’s not quite true, all official releases were done from my machine and that relied on me not doing anything to upset the build).  The build wasn’t automated in any way, so was time consuming and error prone.  We gradually progressed from a checklist I put together so I didn’t forget something from the release, to a home brewed C++ application that did some of the work for us.  However, a build would still take a day to put together and was often unreliable or had missing components.

Another consequence of having such large release cycles was the workload on the test team (all one of them).  They could go months with nothing to test and then we’d apply huge amounts of pressure to get the software tested and released when we were finally ready.  Increasing the size of the test team was not really an option when they were only busy one month in 12, but for that one month we were drastically short of testers.

Our development team had very little structure.  Whilst we had a few Senior members on the team, that generally just meant they got given some of the more difficult developments on the list.  We all sat in a large open plan office, which was great for everyone knowing what everyone else was doing, but terrible for concentration and solving difficult problems.  The other major drawback was that any support issues would take over the whole team.  We just couldn’t focus on delivering the new features as we got too engrossed in solving the interesting problems our customers were experiencing.

Which brings us to the next area; support.  We only employed developers, so they were the ones answering the support enquiries.  They would answer the phone and respond to the emails and the quality of those communications would vary drastically – some would go to great lengths to explain the problem and show how clever they were to have found a resolution, others would expose their grumpier side at the need to explain a trivial issue for the fifteenth time!  Developers could lose whole days or weeks with customers on issues that should have been addressed with better information, training or sales support.  They weren’t writing any software, which for a software developer was unrewarding and for the business was unproductive.

Again, as we only had developers on the team, as well as covering the support side, we were also called upon to do all of the installations and to attend meetings with the sales team and offer pre-sales support.

When we all sat in the office, working on a desktop PC was no problem, in fact they offered good performance for the price, but once we started going out of the office we struggled.  No-one had their own laptop, so we shared an aging Dell laptop.  Somehow this was never quite right, never had the latest source code or tools installed.  Before anyone went on-site they would need to spend a day updating and preparing the laptop for their visit.  As well as sharing a laptop we would share a mobile phone – at least this didn’t require any setup!

It wasn’t just laptops that were lacking in the equipment department.  Developers worked from a single CRT display and still developed using Visual Studio 6.  The test team didn’t have a single representative hardware platform to test on, they just used the 2nd hand developer PCs.  This made any form of compatibility and performance testing very difficult to complete.

The test team, not only lacked representative hardware platforms to test on, they lacked test systems to exercise our product properly, i.e. the sorts of systems our customers were using.  They’d developed test scripts that were very effective at finding bugs in the first few versions of software, but no longer found the issues our customers were experiencing.  In fact several releases of software were sent to customers where even the basic functionality didn’t work!

Another area that we covered as developers was I.T. support.  Perhaps unsurprisingly this area was also lacking.  We ran a central server with limited storage space and an unconvincing backup process.  Our remote access into the office was also unreliable.

I’m pleased to say that the developers I had in my team were all very talented and had a fantastic understanding of the product we worked on, but that wasn’t always the case.  We’d had several colleagues in the past who could talk a good game, but really couldn’t perform.  As we had no defined interview process, we were very much in danger of repeating this mistake (and we should all learn from our mistakes).

The final area to mention was the general state of the office we worked in.  Whilst it was located in a beautiful and picturesque location, inside the space was being wasted, the walls looked shabby and the desks looked very tired.

Next time we’ll look at how these areas have changed from the primitive practices described above to something more modern.  However, before we do, I think it is worth noting that even with these obstacles to success, the team still triumphed.  No matter how good or bad the environment, processes and other practices, it is the people that matters the most.

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

Learning from Mistakes

Posted on September 5, 2012 by

Wouldn’t it be great if everyone learnt from their mistakes?  Well, I like to think I’m a glass half full sort of person, so I believe that people do learn from their mistakes.  However, what happens when they don’t realise it was a mistake?  How can they learn?

I’ve a story here of a mistake that has been made, but not recognised and I think I might be contributing to hiding that mistake.  This is really tricky, as the consequences of letting someone see the full extent of their mistake is not going to be pleasant for anyone.  We’re all supposed to be on the same side so shouldn’t we always try and help each other out?  Isn’t tidying up after someone else the right thing to do?  I’m sure it is, but if that stops them realising they made a mistake in the first place, then actually I’m the only person who suffers and those mistakes will keep being made and I’ll keep being asked to sort them out.

So, here’s the story, and I think it will be very familiar to many software companies.  The software development backlog is growing and the board is becoming impatient that their ideas are not being realised quickly enough.  They are tempted by an offer too good to be true; why not outsource the development?  Fixed cost, plenty of people saying yes, and guaranteed good results or you don’t have to pay; what’s not to like?  Don’t worry about those negative know-it-alls who caution against giving up control of how the software is written and the hidden costs of supporting the outsourced software for the next 5 years.

I’d like to say this story has a happy ending, and in a way I suppose it does.  Of course, the outsourced software was terrible (as we said it would be) and the next 6 months were lost as a team of 5 people tried to bring it back in line and 2 of the original team quit the company after this.  So instead of accepting the internal estimates of trusted experts with a track record of producing quality and being realistic, the words of the outsourced Johnny-come-lately were believed instead.  As we saw previously the true cost of development was not considered.  The actual costs were more and the end results below original expectations.  It has only been the hard work and expertise of the team inheriting the outsourced software that has produced the eventual good results.  They have dealt with the mistake and helped tidy up the mess.  After this work, the software looks pretty good, and customer feedback is now very positive.  So here’s the problem, the mistake isn’t recognised, the lesson isn’t learnt.  Even worse is that the ends are now starting to justify the means which is only going to encourage more mistakes like this.

So what should have been done differently?  Should we have left the product to rot, perhaps refused to touch it all and made it clear that every single piece of that outsourced software was wasted?  Maybe, but is that really what a team does to each other?

Note:  If’ you’d like some help learning from your mistakes, I can recommend this essay from Scott Berkun: http://www.scottberkun.com/essays/44-how-to-learn-from-your-mistakes/

You can also find lots more of these great essays in Scott’s book Mindfire: Big Ideas for Curious Minds

Posted in costs, planning, Project Management, reading, software development | Tagged , , , | 1 Comment