5 things to improve productivity in Software Development - in House | Part 1
Delivery of software development is very often late. If it’s not late, probably you spend more hours to make it on time that you expected. If you make it with an agile approach you end up with less features that you thought you will.
On the other hand all the time we hear about new fancy and easier to develop frameworks, new tools for developers, more mature process and more experienced people. Definitive something goes wrong in between and things you expect that goes smooth goes much more over time and/or budget.
But calm down and don’t fire all “lazy” developers.
Strategic Focus on Productivity
At first you need to measure - Identify the most productivity loss areas and how much time you spent on certain tasks. Try to estimate how much time/energy is needed to change those things and how much of improvement it will provide. It’s a long term process but you are not alone in that. Many people around feel some small pains and are full of ideas. At the end of the day developers are lazy, they really are - that’s why they like to automate and optimize environment around by creating software. It’s just a matter of good brainstorm sessions and continuous improvement.
Below you will find first 5 ways that worked for us without reducing quality of work and demotivating developers by doing crap solutions.
1. Keyboard shortcuts! keyboard shortcuts everywhere…
Step back and observe. Try to see how other people use computers. What actions they perform. Are they writing slowly? How they create and send email, close web browser tab, change channel on slack, go to end of line or document? Do they use mouse or keyboard shortcuts? Imagine that 80% of actions could be achieved much faster by just using keyboard.
We make sure that people know as much shortcuts as possible, even though they often have cheat sheet hanging next to them.
Maybe it sounds simple but try to calculate. Every 0.5 second per action faster * 1000 actions * 20 people * 20 working days = 55 extra hours in a month without reducing the quality.
2. Support layer before developers
Developers’ time is crucial for productivity. It’s important to spend those hours in the right way. When you forward support issues from clients to developers they will waste a lot of time trying to replicate the issue or communicating with the client if the issue is invalid.
To avoid that you could set up a support position or delegate somebody from QA department to take care of that. Developers will receive only valid ticket with right description, screenshot etc. You could control when they have time in current projects to take care of the issues in batch way. Solved issues could be send back to somebody that will validate the task before sending to client which also improve quality. Some of the tasks could be solved by support team even without developers’ involvement.
3. Development Environment Excellence
Each developer should have best possible IDE but even if he does there is no guarantee that he will write code fast. You need them to adopt to one commonly used tool and train them. The best approach is to ask one of them to prepare workshops for others (try to find IDE evangelist inside the team). Devs should use as much keyboard shortcuts as possible, generate small and repeatable part of code, debug easily and be able to navigate between files and projects rapidly. Once it is learned it’s like having 2+ monitors - they won’t imagine work without it.
We are using Jet Brains development environments and its worth every penny spent on it.
4. Small Issues handling
Imagine that you have 200 small task/bugs and each of them take only 5 minute to solve. However you have then handled somehow in the ticket tracking system or spreadsheet. QA Engineer need to create that ticket, then developer have to find in the code and fix it. After it is fixed QA need to test if it is done right. Sometimes there are some extra iterations, deployment communication, some comments, and even more ticket handling. Task that could be done in 5 minutes on development stage will now need 15-20 minutes in total. Now multiply it by 100 and you have a time gap bigger than one week of vacations.
To be able to solve that issue you need to identify its source. Most of it comes from simple details. It happens that developers thinks that they don’t need to test it very well as there is QA department and they will catch it anyway. Meet with them and show the numbers if they still not convinced you could try our way. We organized an action inside the company that for one day developers became QA. They could realize the importance of their colleagues work.
5. Use Right Tools In House
It’s better not to have 100 bugs in the system but if you have it you need to get them documented - screenshot could be helpful. Taking it and describe with some additional comments could take from 1 minute if you do it really fast to 5 minutes if using MS paint. Doesn't make any difference? Well 100 bugs * 4 min = 6 extra hours. Try using Awesome Screenshot Plugin or Sharex.
Do you use spreadsheet to store there your bugs? If Yes - You do it wrong…
After couple of iterations, changes, status changes you don’t have a track but just a big mess without screenshots, history, notifications and much more simple things like permissions etc. There are plenty of issue tracking system available online. We are using JIRA but it’ up to you preference which one you choose. Here you could find a short list of them.
Everybody knows today that using shared documents on which you can work simultaneously it's a must. But not everybody knows that using shared documents and putting issues or things to discuss + using comments (ctrl + alt + m on highlighted text) will produce nice way of notification send via email in aggregated form. That way you could discuss inside the team what is done, what more needs to be specified. You could paste there screenshot or even do the same with your client.
There is hype for slack and it boost your team work definitively. I could write separate article how useful it could be however few simple rules should help you take best of it.
Enforce people to discuss things about projects on separate dedicated channels. Some of them like to discuss things about project in private then other people cannot see what’s happening and make their input if needed.
Browse slack integrations and use those ones that suits you. You want to be informed about last commit from code repository or be able to see new tickets from JIRA? It’s just few clicks away.
Use slackbot to eliminate few small details out of conversations. You could configure slackbot to react for certain words. For example when somebody write “just a moment” slackbot immediately answers “How much minutes?” It often makes you all lot of laugh but in long term people cares more about what they say.
If you find something interesting that worked out for you then do not hesitate and share it with me.