Boost your development team
Alberto Gimeno - 11th July 2017
Whether you are a product owner, client, product manager,… you should care on making developer lives easier. Why? Basically because development time can grow exponentionally when unexpected things need to be implemented or changed. So communicating clearly what needs to be done, and why! is really important.
Tell the whole story
I’ve seen many times things poorly implemented just because the developer didn’t understand WHY something needed to be implemented in a certain way. A developer is not a robot: if you don’t tell the whole story, a developer may not undertand all the cases and will leave things unimplemented or just implemented the wrong way.
A developer didn’t get the whole story
Don’t just tell the users “this is not working”. A developer sometimes needs a lot of information to reproduce a problem (different environments, different user data, settings, etc. can be involved). Even with all that information the error sometimes cannot be reproduced because it only happens at a specific time of the day, or things like that.
An image is worth a thousand words, so take screenshots. Even better: take and annotate screenshots!
On macOS I use Annotate which is super handy for taking and annotating screenshots. You can also pixelate parts of the screenshot if they contain sensitive data.
An example annotated screenshot using Annotate
With annotate you can also create GIFs, but for recording the screen I prefer something like Screenflow because I can edit the video before sending it, such as cropping, trimming, etc.
On iOS, starting at iOS 11 you can take and annotate screenshots anywhere! Just take a screenshot by pressing the home and sleep/wake buttons at the same time, and starting at iOS 11 you will see a thumbnail of the screenshot on the screen. If you ignore it, it will disappear shortly, but if you tap on it you can draw on it!
UI for annotating a screenshot on iOS 11
Starting at iOS 11 you can also even record the screen just with your iOS device! (not jailbreak needed, not cable needed). It’s easy for you and it will save a lot of time of communicating things to the development team.
Communicate in advance
Many times as a developer I’ve had to deal with big refactorings because there were things we didn’t know in advance that the client knew! It feels like:
Team, you made a great work building this skyscraper. Just a minor thing, we knew from the very beginning we needed it in a different location, so just move it, ok?
Many times knowing something in advance and doing it in a different way (like choosing a different location for a building) makes no (or little) difference from a development perspective, but once it’s done it’s hard to change.
A good example for this is when you will need multiple something. Such as: a user should be able to log in with multiple email addresses. Or a user should be able to have multiple projects, etc. Designing it like that from the beginning would be a lot simpler than adding that later.
Split and purge big tasks
It’s super stressful to have long-lasting tasks in the ticketing system. I strongly suggest to split bit tasks into smaller ones in the first place, and when a sprint finishes (or some deadline happens), don’t move the tasks that are already started if they have some progress: instead create new ones with the unfinished stuff. For example when there’s a new design, I prefer to adopt them gradually to not block progress on other functionality. So I do first the big changes, but the minor details could need a lot of back and forth between the designer and the developers that could last several weeks, but the big changes could have been adopted in the first few days. In this case I prefer to create small tickets for the small details.
Listen to the people with experience
Ignoring good advice creates a bad atmosphere.
Imagine you suggest going from one city to another by car but somebody dicatates you to go by bike.
It’s double penitence: your advice is ignored and you have to deal with the bad choice.
In order to boost your development process you need your developers to be comfortable. It’s all about communication, trust, and taking care of people. These are just some good practices I’ve detected in my experience. Do you have more?