Return to site

Five tips for smoother software projects

Lessons learned from good times and bad

Over the years I have lost count of the number of, requirements I've written, software releases I've managed, people I have hired, mistakes I've made, and also there's been a lot we've absolutely nailed as team. A lot of the lessons learned however big or small are now put into practice as a matter of habit at Day Digital, but it's easy to take them for granted.
When meeting with clients and potential customers, I realise a lot of people now find themselves responsible for building software that have never done it before. For example, a marketing team that want to build an iPhone app, or a creative agency that suddenly needs to be a bit more digital. This is a trend that will no doubt continue, as digital strategy looms large for teams that never thought they'd have to worry about it, even 5-10 years ago.
What I've decided to do is write down some of the most holistic and widely applicable bits of advice I think will be helpful for people who might feel a little in over their heads on the topic. So rather than smaller more subjective details 'Have some bean bags on the floor and beer on a Friday' This one project management tool is awesome' and so on, I've got a few simple things that should stand you in good stead for building great software teams, and therefore, great software.
Once you have the right people, culture, and processes in place - you can worry about the finer details. Those finer details tend to be wildly different for every person and organisation, hence it makes sense to think big for now.
Please note - I've often hit upon these rules as a result of messing up, and realising how to fix my own mistakes. So I can say that everything below has been a game-changer for me, and I hope it's worth a read at the very least!
1. Standards are absolute, never compromise.
A culture of high standards is probably your best starting point. First, make sure you have great people, and second make sure everyone (starting with you if you are a team leader) has high expectations of themselves, and therefore the work they produce.
The 'standards are absolute' rule is one you can never compromise on when it comes to hiring decisions. A hiring decision made because you need someone to start by next week, next month, 'yesterday', or whenever you have convinced yourself you need this person, is one that will bite you later on.
Your decision to hire someone should never be relative 'this person was the best person we saw', it should always be absolute 'this person meets the exceptional standards we require' - especially for software developers.
If you find yourself at the helm of an average team, trying to execute on the 'world-class' standards your company sets for itself, then you know success is not possible, and I bet you can trace back to where it went wrong (too many bad hiring decisions).
When working for a large company in the Bay Area, I was given a budget to set up a team, and took 6 months to do so. Luckily my manager at the time was supportive, and realised we were building for the future, not for the sake of it. Maintaining high standards for hiring this team was probably one of the best decisions I ever made in my career. I didn't know it at the time, but it was also the inspiration to start Day Digital, and to bring these kind of software development standards to the open market.
The 'lost' 6 months, spent doing interviews, driving around university campuses, or just about anything to find the best people (which was tough to do in the Bay Area because of how much competition there is) - were gained back with interest about 6 months further down the line.
This team of extremely strong developers had done more in their 6 months, than an average team would have done in 12 months. I could also argue (quite effectively) that average people would not achieve the same level of results as exceptional people, even given an infinite timeframe.
2. Do you control the process, or does the process control you?
So let's say you have the right people on board. The next big question is 'How well are you able to execute on the goals that you set for yourself?'
This is a question everyone can ask themselves whatever their responsibility level from an individual contributor (e.g. junior developer) through to someone with a much wider remit (e.g. Head of IT, Marketing Manager, or even CEO).
It's bad enough if anyone feels unable to execute on the tasks they want (especially if this is owing to internal processes), but if you are a manager or senior manager, and not sure you're in control, then something is very wrong. This would suggest that at a company level, you are going to struggle to reach your ambitions.
I personally don't care how you get things done when it comes to building software (you might swear by Post-it notes, Excel, Slack, JIRA, YouTrack, Trello, working from home, working in an office, listening to music, not listening to music, starting at 8am, starting at 2pm), there are so many ways of achieving goals, that I feel it makes no sense to try and force a particular process on yourself, your team, or your company, just because it works somewhere else.
If various obstacles that your own team has created get in the way, then get rid of them.
Watch out for big red flags such as these:
- People follow rules rather than common sense
(e.g. Rule 7a on page 11 of your company handbook says don't do X, even though everyone can see X should not apply in this particular case, you go with the handbook)
- Too many people involved in decision-making
(If the process of going from an idea on a whiteboard to digital reality is too cumbersome, your organisation will simply give up, more often than it succeeds)
- Churn and burn
(piling on work, 'this release is top priority!', team gets tired and demotivated)
- Lack of focus and constantly shifting priorities
(Half-finished projects, nothing ever gets done, everyone's day is lost to meetings, urgent emails, and projects that crop up out of nowhere)
This last bullet point gets its own section below...
3. Pick your battles (ideally 1 at a time)
Don't be a hero. Your list of 20 tasks for today is unlikely to get done. I tend to only have 3 tasks I deal with at most, I will only personally work on the top priority task of those 3, and will delegate (if possible) the other two tasks. Once any of those tasks are done, I re-evaluate the top three priorities, and so it goes.
This system works for larger strategic priorities (again, pick 3 max), or smaller day-to-day tasks. I admit, I do struggle to follow my own rules sometimes, but when I stick to it, I get a lot done.
I would expect the people I work with (software developers for the most part) to know their top priority at any given time, and I try not to load anyone up with too many tasks. As a manager you may feel like you're achieving a lot if you've dumped a load of tasks on your team, and you see them working late into the night - but you've probably just overwhelmed everyone with half-baked ideas, demotivated your team, and set your project up for slow burning failure.
If you are managing a software product, then remember - what you leave out of your software product is often more important than what you put it.
If everything is a top priority, you'll end up with a bloated product, with too many features, it will be hard to understand, not easy to use, and take you ages to build. 
Each shift in priority costs time. So if you are in a management position on a software project, think extremely carefully before prioritising new features, bugs, research, meetings, or whatever else you think is a good idea - because everything swallows up time. Unless it's high value, it's a distraction. 
If that sounds a bit scary, then fear not, you can also plan for the unexpected. So for example, if you have a developer whose top priority is feature X for the next release, and then an unexpected bug crops up that must be dealt with, this needn't throw everything off track.
If you buffer in this kind of 'unexpected' event (that happens all the time) into your estimates then you'll be fine. So let's say each developer will realistically spend 80% of their time on new features, and 20% on dealing with 'unexpected issues' (such as bug fixes, researching how to complete their own tasks, or being pulled into meetings).
4. Measure twice, cut once
Planning is an important facet of software development. It pays to really understand what objectives people want to achieve before diving in too deep with development.
This is particularly useful with business stakeholders. So for example, if a request comes in for new feature X (which seems like a plausible idea, that's simple to achieve), is it better to just get on with it?
In my experience, it makes a lot of sense to sit down with the people who have requested this feature, and get them to describe how this idea might look once it's done, what they want to be able to do, and where things might lead in the future.
This allows you to potentially improve on this idea, or even for the business stakeholder to realise that given this feature will take your team 2-3 months to build, it's really not that important to them (this happens way more than you might think!).
When you do decide to push the button and go ahead with development - having alignment on what you are doing and why (from a business perspective) provides a lot more clarity for everyone involved. Also the tech team can now plan for the future as well - as if feature X expands over time to have more functions, and users, they need to think about this up front in order to plan the best underlying architecture for the product to succeed.

If your team doesn't use prototyping already, then a tool such as Invision might be useful.

5. Keep your developer to non-developer ratio high
A software team should be measured on its ability to build great software. So it stands to reason that you want the leanest team possible that can build you great software. One simple way to track this, is that your developer to non-developer ratio needs to be as high as possible.
Put simply, this is how you want to spend your budget:
  • Developer = someone who can create software for your customers to use
    (e.g. Front-end developer, Back-end developer, Technical Architect and so on)
  • Non-Developer = everyone else
    (e.g. Project Manager, Visual Designer, Quality Assurance Tester, Business Analyst, Product Manager)
Obviously everyone in a software team contributes, and are hugely important, for example without a designer, your software might look terrible - so don't get rid of everyone just yet!
My point is that you should always be conscious of who in a team actually creates software, and who does not. The non-developers must create a lot of value, otherwise your team is probably bloated and inefficient.
This last point might be the only 'controversial' one on this list, so let me be clear - I'm a non-developer myself. As a Product Manager I am often found responsible for generating ideas, writing requirements, task prioritisation, managing business stakeholders, and the development process as a whole, so I'd like to think I'm fairly useful in the software development process. But at the end of the day - I don't sit down and write code.
One software developer with four product managers (1:4 developer to non-developer ratio) would be a terrible team, whereas four software developers and one product manager (4:1 developer to non-developer ratio) would get a lot done.
At a guess I think a ratio, around 3 developers to 1 non-developer is pretty good, if you're much lower (e.g. 1:1 ratio or lower) then the team is probably inefficient.
If you have two developers, flanked by 2 managers, and 6 other non-developers (testers, business analysts and so on), I'm guessing you don't get a lot done.
Remember that it's perfectly fine, and in fact better for everyone if you keep things fluid, and have temporary team members too. We often have visual designers, technical architects, and business analysts at the start of a project, but then they will drop off the team once they are not-needed.
(A technical architect is not very motivated if they are on a project where there are no major architectural decisions left to be made anyway).
When a software team is not performing, or behind schedule, the trap companies often fall into is to add a non-developer (a business analyst, a project manager and so forth) into the team. I'm not saying this is always a bad idea, but I am saying think very carefully before doing this.
If you wanted to improve sales in your sales team, would you add another Sales Person... or would you add a 'Business Analyst', 'Lead Generation Specialist', 'Events Manager', 'Social Media Manager', 'Partnerships Director' or 'Business Development Consultant'?
Any answer is valid, providing you can justify it - but it stands to reason you would think twice before hiring non-sales people into your sales team, because they cost the same money (or more) and are not going to bring in sales directly. When you ask the equivalent question in software terms ('Who do I want in my development team?'), I think people are much quicker to hire the non-developer positions.
All Posts
×

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OKSubscriptions powered by Strikingly