Traditionally, businesses will have a structured hierarchy, and projects will follow a linear process of research, design, creation, and release. While the tech world may follow these rules in some cases, software engineering teams have also developed their own methods of working.
It is important for any businessperson to know some of these working practices so that they can get the best out of their team and ensure that projects are completed on time and within budget. In this post we will look at some of the common working practices adopted by tech teams.
Incremental Releases
If you are building a bridge then you will design the bridge and build it in place. Once the bridge is complete, the team is unlikely to ever need to even think about the bridge again. In the case that the bridge needs some maintenance work in ten- or twenty-years’ time, it will be a completely different team that works on it.
This is not the case for software teams. In the tech world, it is common to create software and then continue to support and update that software for another five years. This happens because technology around the software quickly evolves, so the software will need to be updated to work with the new technology. In some cases, business teams will want to change requirements or features to improve the product for the customers.
When a software team produces the initial release version, it is important to recognise that it will probably not be the final version. All suggested features may not be in the final version, but the team can continue to work on the software and add features later.
Agile Development
Agile development refers to the development methodologies that are able to adapt to changing requirements, teams, and circumstances. This is important as the software might be planned with certain restrictions in mind, but new technology may come along a few months later that open new possibilities – technology is constantly evolving.
One common agile development methodology is called scrum. This methodology is designed for small teams (usually up to 10 members) who work in small iterations known as sprints. Each sprint is between two and four weeks long, with a predefined goal so that the team knows what they need to do with their limited time.
At the start of each day, the team will hold a stand-up meeting (sometimes known as a daily scrum) where they discuss what work they have done, what work they are going to do next, and whether they have found any potential roadblocks in the work. Each of these discussion points should link to the predefined goal, and this discussion helps solve any problems that could occur.
When the sprint is complete, the team will review their work and present it to stakeholders. After this, they can start to plan the next sprint. By breaking work into small sprints of just a few weeks, the team can adapt to changing requirements or problems. If the whole project is expected to last for a year, the work for the year does not need to be planned out, only the next few weeks.
If you are working with a software team, check what development methodology they are using. Even though lots of teams now use agile methods, not all teams use scrum. There are many methodologies out there.
Documenting Work
Certain areas of the business world love paperwork and documentation, believing it is great to have every decision and idea written down. For some software teams, this is the worst part of the project.
Many software developers do not want or need to create five different diagrams explaining how a single algorithm works, when that algorithm is very common, or they can explain it in a single paragraph. Software developers will often agree that it is more productive to just code.
Why? Because software developers leave comments in their code all the time. These comments are a way of documenting their own code so that other members of the team can understand the code. This is standard practice in the software industry. There are also tools that can convert code comments into webpages that give clearer descriptions of the code.
Sometimes it is important for a business to have paper documentation of the project. It is best to discuss this with your software team before the project begins. But it is also important to remember that adding paperwork onto their schedule could double or even triple to project timeframe, especially when many software developers are not trained in writing business documents.
Understanding Technology
So, you have come up with your great new business idea. You have planned out the marketing, the finance, and the software. But there is a problem… you don’t understand how the technology works, so you’ve asked some software developers to do it for you.
When you get into discussions with software developers, make sure you have an understanding of what is possible. Of course, you will not be an expert on software, just as they won’t be an expert on business. But understanding what is possible will help your team when agreeing on requirements.
Building a simple website is possible because you know it has been done countless times. Building the next Facebook or YouTube is unrealistic to ask because your software team of four people does not even compare to companies employing thousands of developers. Maybe you want to use machine learning to translate between languages. Yes, there is tools to do this, but if you want flawless translations then you need whole teams of cutting-edge researchers. Most things are possible with software, but can they be realistically achieved with the resources that you have?
Discussing this with your software team is a good idea, but have some general understanding of what is possible in the world of tech. This is one of the biggest conflicts between the business world and the tech world. Businesses have great ideas, but these ideas cannot always be converted to reality.
Can It Work?
There are many differences that you must accept when working with a software team, and sometimes they can restrict what is possible for your business. But don’t be completely negative. Technology businesses are popping up all the time, which is evidence that the business and tech worlds can work well together.
The key points are to understand how the tech world works and to understand what is possible with tech. These two points will go a long way. Are you planning to create a new technology business? Or are you already working with a software team? Let us know in the comments!