This is a practical guide on improving predictability: you’ll learn how to recognise when you need to work on your predictability and how to set the right goals to achieve the results you want. At the very end of this article we also talk about the future and what the next steps will be for Netguru as we grow and mature as a company.
This is the third and final part of our article series about improving predictability at software development and consulting companies. Check out Part 1 for background information and advice on introducing a major change to your colleagues. Part 2 includes the detailed descriptions of the steps we took to improve our predictability, create appropriate metrics and measure our results efficiently.
A caveat: if you want to increase the predictability at your company, we don’t recommend faithfully recreating every step of the process we introduced at Netguru. Instead, you should understand why we made the decisions we made and took the actions we took, so that you will be able to do what’s best for your particular situation.
We believe that every business can benefit from measuring and increasing the predictability of its processes. But here are a few situations in which making the decision to go ahead with such a process should be really easy:
This is not an exhaustive list. Another good reason to increase your predictability is simply if you feel that it will be good for your business. If you aren’t sure, start small. Pick one area to change and see how it goes. You don’t have to do things in the same order we did – think about what will work best for you.
Use as much technology as possible and automate processes. You want to make your life easier and spend the time you save on other tasks.
Remember to use the iterative Agile approach. It will be easier to control your process this way, and you won’t get stuck so easily.
Decide what you want to achieve – it’s always going to be specific for you and your organisation. For us, the key thing was clients’ happiness. Since we’re software consultants, we know that predictability and stable quality are extremely important.
That said, what you don’t want is actually even more important, so decide on that. Here are some examples of things you might not want:
Identifiable issues within your business are where the will and motivation to improve comes from. Once you find those issues and realise you can fix them, it’s hard to resist not to jumping right into improvements.
It’s probably the most popular project management methodology right now. We know it in theory and in practice, but Scrum wasn’t introduced in Netguru wholesale. We took the elements we needed and happily ignored everything else. That’s the correct way of using a tool – only take what’s actually useful to you.
Here’s the list of the elements we adopted:
The idea here is to break down the process of software development into small, easily manageable chunks. This makes the process more predictable and allows us to focus only on the scope of a given sprint. It is essential that each sprint meets a business goal, moves us forward in the development of the app and brings us closer to the final product.
The team meets to answer three questions. What happened yesterday? What’s the plan for today? Are there any blockers? Depending on the team, the meeting takes from 5 to 15 minutes.
This meeting is held at the beginning or before the beginning of a sprint. The team analyses the project backlog and decides what they will work on during the sprint. They also commit to it and declare that they will be able to complete the work within the sprint.
Demos are a very important element. We present the effects of our work to the client/product owner and the team. We make sure that what we’ve created aligns with the client’s vision.
Internal meetings of the team. We consider what went well, what didn’t, and what we can learn from the finished sprint to work better and more effectively in the future.
Each of these rituals is open to the client, should the client wish to participate. Participation is not mandatory, but we always welcome clients/product owners if they want to join us.
Estimations are by no means innovative, but we tailored them to our reality. We adopted a story-point approach based on the Fibonacci sequence (an adaptation of planning poker). We don’t do it the way the rest of the world does it, but the current solution fits our business. The conventional way of doing it is to estimate for each project separately. You pick one base feature per project, set its value to 1 point, and estimate according to that. This means that the basic feature has the complexity level of 1. There might be several features of this level in the project. According to the Fibonacci sequence, the next complexity levels are 2, 3, 5, 8, and so on. Each feature planned for the project is assigned a complexity level by comparing it to the base level 1 feature.
You repeat this for every project. The first thing you need to do is find the value of 1. Your base level 1 feature will differ from project to project, so it might actually be slightly more or less complex.
We needed a system for all of our projects that would compare one project with another and allow us to learn from the data. We adjusted the system by creating reference tasks for each technology (e.g. React Native and Node.js) we work with, and we apply it to all projects. This is why we can give clients estimations measured in weeks or months: we have historical data from other projects that inform our predictions.
We would prefer it if clients didn’t want estimations, but we realise it’s pretty much impossible. Clients need to make plans and want to feel the security of a clear prediction: “the project will most likely end in about X months, you have that much time to prepare for launch, and you need this amount of funds to develop the complete MVP”. We understand that this is an important, if somewhat detrimental, part of the business of software development.
It’s detrimental because it goes against the Agile methodology. The more you set in stone, the less you are able to adapt to changing circumstances quickly. Many projects would benefit from a more flexible approach, but estimations are a part of long-term planning. The important thing is to remember the pros and cons of both approaches.
After months of work, we noticed a clear improvement in our predictability – and we can tell, because we know exactly how to measure it now. We also conducted some tests jointly with our marketing team – our NPS score is well above 8. Clients point out how reliable we are and recommend us to other business entities.
The change has brought us much good. We feel more confident in using our tools and processes, and we know how to spot potential problems. This is the most powerful benefit of using data – it gives you an efficient way to keep up with a quickly growing company.
Since we started collecting the data described above (e.g. the percentage of sprint realisation, tickets added to a sprint, points delivered, etc.), we have noticed there were more data points, within projects and elsewhere, than we expected.
We realised we could use AI and machine learning and innovate: take advantage of our data, machine learning, and AI technology to create a program that will help us predict crises.
We have a lot of project-related data in Salesforce that we could use. So we started building a Machine Learning (ML)/Artificial Intelligence (AI) tool, which will work in the following way:
Here’s an example decision tree. It shows us which decisions might lead to trouble (the grey nodes).
We want to showcase this technology in the near future. Stay tuned for exciting future updates!
The process described in this article will most likely never end for us, because continuous improvement is part of our culture. This is why machine learning and AI seem so attractive – they make continuous improvement more scalable.
We started out as a company delivering solid results with a certain amount of confidence in our predictability. Now, we know exactly why we’re predictable, we know which data to collect to improve our measurements, and, finally, we know how to improve the predictability of our processes. Every company should go through a similar process, at least as an exercise. It’s likely the tools for improvement are already there, waiting to be used, and you could get large benefits with little effort.
Predictability in business matters. It not only benefits your clients, but also helps you plan for the future, see where quick fixes are required, and where more long-term action should take place. I’m not going to say that working on predictability will save your business when times get rough, but it very well might.
If you have any questions about the process or our reasoning, don’t hesitate to ask.
Netguru is a software consulting agency based in Poland. We have been growing rapidly – we’re among Forbes Diamonds and have been recognised as one of the 500 fastest-growing businesses in Eastern Europe. Our clients are both startups and mature companies interested in introducing innovation.
We offer expert consulting on product design and user experience, build software products from scratch and help improve existing ones. Predictability is important for us, particularly in the context of our software development process.