A development methodology is a set of processes which can be employed to ensure quality, timeliness of delivery and confidence in the success of the project.
Every software project requires a development methodology of some kind, and picking the right one, and using it correctly, is vital to the success of that project.
Some important questions for any business in a service industry are:
I’ll give Softwire’s answers to these below.
There are some new additions to the Softwire office. We expect these new recruits to help us with software development, without saying anything!
It’s long been known that the very act of explaining a problem out loud can, by itself, be enough to solve it. So we’re asking our developers to explain their problems (with their code, their customers or anything else) to their duck in the first instance. If this is successful we’ll save a fortune on task managers.
If anyone’s sceptical, my favourite benefit of “rubber ducking” is this one. Rubber ducks don’t gossip about your private problems with other rubber ducks.
It is essential for any company to be aware of how each of their employees is getting on. Fail to spot and reward good work and you’ll have disaffected and un-incentivised employees. Fail to spot and correct poor work and you’ll fall some way short of 100% productivity.
It’s the nature of a Software house that employees will change teams often, with project lifetimes usually falling between one month and one year. This presents a challenge for monitoring progress, but also an opportunity.
At Softwire we recognise the importance of having some consistency in your management line, but we also consider it imperative that you’re looked after by someone who’s working with you on a day-to-day basis. That’s why everyone here has two managers: a Line Manager (LM) and a Task Manager (TM).
Who is responsible for the successful delivery of a project? In Softwire, the answer is quite illuminating.
Each project is assigned a Project Manager (PM), who is the most obviously responsible for its successful delivery (incorporating commercial success and customer satisfaction).
The PM’s manager is called the “Super Project Manager” (SPM). In Softwire we currently have 4 SPMs, each of whom manages a number of PMs. Here’s what our internal literature says about the SPM’s duties:
The SPM is fully responsible for ensuring that the PM delivers the project successfully by providing oversight and advice as required…
Note that the involvement of the SPM does not in any way diminish the PM’s responsibility to deliver the project successfully. The PM remains fully responsible for successful delivery. The SPM is also fully responsible for ensuring the PM succeeds. I.e. both roles are fully responsible!
A similar principle applies to the portion of a project assigned to each developer. The developer is fully responsible for both the quality and timeliness of their delivery, but so is the PM and the SPM. You may consider this to be logically inconsistent garbage – or worse, some kind of Orwellian brainwash along the lines of “War is Peace”. The flippant response is “You can never have too much responsibility!” However we need to prove that this overlapping responsibility is meaningful in practice.
READ MORE…
It’s important to communicate clearly what you expect from your employees. What you consider to be their key responsibilities also says a lot about what kind of employer you are.
New starters at Softwire are given a presentation by one of the directors, during which they are told about Softwire, our philosophy, some of our more important procedures, and also what is expected of them. This last part has been distilled into five “Key Responsibilities”:
I’ll expand on all of these below:
We acquired a set of actual traffic lights, which are hooked up to an integration server giving our team constant feedback on whether the codebase compiles and passes all our unit tests.
Employee morale is so important for a company of any size. It’s definitely a priority for Softwire, a fact borne out by our recent arrival at 16th in the Sunday Times “Best small companies to work for in the UK” list (see more information here).
Increasing morale will lead to the following Good Things:
Happily, all these Good Things will also boost morale themselves, creating a virtuous circle of job satisfaction.
Employee morale needs to be an all-pervading goal, and should influence policies on everything from how annual appraisals are conducted to what coding languages you use. Much of this will be covered elsewhere on the blog, but there are two specific concepts that are worth considering explicitly. I’ll discuss “Happiness” in the next post, but for now I’ll deal with “Trust”.
In this business, employees are a company’s most valuable asset. That may be a cliché, but it’s a cliché for a reason. They’re certainly what we spend most of our money on, so it makes sense to check we’re getting quality goods from the outset.
When it comes to recruitment for technical positions, our philosophy is that if you hire bright people with good problem-solving skills and the right attitude, training them how to write code, and even manage projects, is a relative doddle.
Softwire started life in January 2000, when our directors Phil, Dan and Pete (respectively below) decided to form the kind of software house where they’d want to work themselves. This meant it needed to be fun, challenging, and profitable.
Ten years on, it looks like they’ve succeeded – we haven’t merely survived the bursting of the dotcom bubble, the credit crunch and the global recession; we’ve ended pretty much every year with healthy profits, and grown to over 60 people with a frankly ridiculous staff retention rate of over 90%.
Over the coming months, I want to analyse how they’ve achieved this, in the hope that some of the information will prove useful to others in the coding business. In a moment I’ll take you through a few of the topics I plan to cover. First, however, I think it’d be useful to outline some of the values that they’ve brought to the company.
Spring Digital