The global enterprise software market is forecast to grow at an 8.5 percent compound annual growth rate (CAGR) in current U.S. dollars from 2016 through 2021, according to Gartner. The total market is expected to reach $537.7 billion in constant U.S. dollars in 2021.
Companies that are just entering the software market may think all they need is a solid team of talented programmers to guarantee success. But those who are well-versed in software delivery know that it is a fairly complex process, requiring more than just coding knowledge.
If your team is new to software delivery (or is struggling with it), it may be time to take a step back, reassess, and determine the right path for moving towards success.
The game plan for a successful software delivery process
The most important thing to understand about software delivery is that it is a process. This means success requires a certain amount of discipline.
Immediately jumping into coding (or assuming all you need are coders) is not the right approach. The software delivery process requires several different skill sets.
You need people who can understand who your customers/users are, what they want, what they need to achieve, and how your software can make that easier. You also need individuals with a core understanding of your business, as well as people with skills outside of programming, such as quality control and usability, and experience creating a commercial application.
Success truly does require a team, one that is made up of players with varying talents. All team members must work together to produce a piece of quality software.
The players required for successful software deployment
There are four critical players in the team line-up for a successful software delivery process. Depending on the size and scope of your project, you may very well need more than one team member who specializes in the same skills.
Product Manager
I’ll bet you were expecting me to say “project manager,” but no. There is a very important difference between a product manager and a project manager. Despite the similar monogram, the product manager is the key player in a software development project. On any product development effort (whether software or any other product), the product manager is a key player; they represent the customer, or user, of the product.
It helps to look at and treat every software development effort as if it was a commercial product, even for internal enterprise applications. You need to act like you are creating a product that you have to “sell” to your users and stakeholders, which means product management disciplines should be applied.
The process starts by talking to users (or customers) to understand what they need and how your software can help them get from point A to point B faster. This involves talking to users and gathering requirements. The Product Manager should produce a document outlining business requirements and functional specifications for the software.
As for project managers, they do have their place in some projects, especially complex ones with many teams, but only in a supporting role.
User Experience (UX) and User Interface (UI) Designer
UX and UI designers are responsible for creating a compelling user experience. User research, competitive analysis, user journey mapping, prototyping, and user testing are all needed to create a more usable product, while reducing development costs and speeding up development time by reducing the need for re-work.
For a more detailed look at UX and UI design, consult this article.
Programmer(s) / Developer(s)
You will likely need more than one player on your team to be able to fill this position. The skills required of your developers can vary based on many factors, such as the nature of the product you are developing (and how it relates to the user) and the platform you have chosen for delivery (cloud versus mobile, for example). Different skill sets are often required for different layers of the development stack, for example, and you can put your project at risk by not having the right skills at every layer. While the industry is rife with “full stack developers” looking for work, that can be a little bit like hiring a “full stack home-builder” to do everything from pouring the foundation to framing, siding, plumbing, electrical, painting, and decorating—I’m sure they exist, but it’s risky to stake your outcome on one.
Depending on the complexity of your product, you might need an independent architect who understands and can define the high-level technical structure of your product. This is especially true if you envision your product scaling to service a large number of users.
Size may also impact how you deploy your product. Many large-scale applications require dedicated teams for managing release and maintenance.
Quality Assurance (QA)
Software needs to be tested, and this is where the QA team members are pivotal. Some may be tempted to allow programmers to perform some or all of the testing, but it should be done by people who did not write the code, and by individuals who have the mindset of testers, not developers.
Fresh, disciplined eyes will make sure the software performs as expected and meets all of the necessary requirements. The QA players should also make sure the software is secure—that it cannot be made to do things that you don’t want it to do, like cough up your customers’ private data— so your business is not at risk for a damaging attack on users or your reputation.
Coaching tips on software delivery strategy
There is no one way to win the software development game. Just as a coach can choose from a wide range of strategies and plays, there are a variety of disciplines that you can follow in software delivery. They each have their strengths, and different disciplines apply to different types of products. The scope of the project, budget, and timeline also factor in to the right approach. Despite what the books and consultants say, there is no one software development discipline that’s right for every occasion—but the one thing they all have in common is “discipline.”
The approach that works best for us, and the one we implement whenever possible, is Agile. In the Agile approach, team members work together to define and build the product in small pieces. It is an iterative process, where feedback is constantly incorporated until you have a version that is deemed ready for release. But even after deployment, you continue to repeat the update process, constantly improving the product. Agile is best suited to software that interacts heavily with its users; if your interested in other disciplines and where they fit in, we’d be happy to talk about them with you.
If you’re lucky, you’re never done—because this means your users like the product, are using it, and want more features and functionality added to it.
For more information on the Agile approach, check out this article.
Regardless of the software delivery strategy you employ, here are 10 tips to steer you towards success.
1. Clearly define success.
What does success mean and how will you measure it?
2. Identify the skills required.
We already discussed the types of players required for success, but the right people for your team will be defined by the specific requirements and type of software being built. A software application designed for internal use in a mid-size company will require a different team than one being built for external deployment to millions of users requiring constant updates. Questions to consider include:
- What type of application are you building?
- How large is the expected user base?
- What type of programming and testing is needed?
Answers to these types of questions will help you pick the right team players.
3. Involve users from the start.
Whether end users are external customers or internal employees, they should be involved throughout the software delivery lifecycle. Conduct user interviews to determine what they want and need from the software. Use mockups and prototypes to gather feedback before you spend a lot of time writing code. Incorporate feedback into the product, both during development and throughout the life of the software.
4. Track progress.
Whether you’re using Agile or some other discipline, create a timeline for defined chunks of work and track the team’s progress towards those goals. These smaller blocks of work keep the team focused and productive.
5. Collaborate.
No one player is more important than the others. Foster a culture where everyone understands the importance of all job functions. This respect will encourage everyone to work together towards a common goal. A player who is focused on what “I” need to do may generate great code, but if that person is unwilling to wait for proper user study or security testing or whatever else before moving forward with work, it can jeopardize the success of the end product. There is no “I” in “team.”
6. Use tools to stay organized.
Collaboration and tracking tools such as Jira help your team stay organized and on the assigned deadline. Delays can be addressed immediately, making them less likely to cause a major delay in development. There are many such tools out there; find the ones that suit your team best, and implement them.
7. Measure success.
There are many ways to measure success, so you have to select an approach that makes sense for your project. Examples include:
- Cycle time—How long it takes to make an update to your software and deploy it.
- Open and close rates—How quickly issues are handled and closed after they are reported.
- Crash rate—The number of times the software application fails divided by the number of user sessions.
- Mean time to repair—How quickly a security breach is identified and repaired.
The old management-book adage is “if you can measure it, you can manage it.” Many people find software development to be a black art that defies measurement, but it’s not—look for the metrics that you can calculate, and use them.
8. Test (again and again).
Testing your software repeatedly for bugs and security issues is critical to success. A strong testing process requires the use of multiple tools. While this might sometimes be seen as a roadblock to rapid development, there are tools available to collate and organize the results from testing tools. This makes it easier to identify which issues are of the highest priority and should be addressed first. For more information on application testing, consult this resource.
9. Stay in scope.
Change is an inevitable part of the software delivery process, but changes that completely alter the initial scope and purpose of the application are a sign your project has gone off the rails. Some people think “Agile” means “open to change,” but really it’s a discipline for managing change. Significant changes should be understood and approved by key stakeholders, and the reasons behind them should be explained to the entire team. If a change starts to look like a complete overhaul, it is time to stop, step back, and reassess the situation.
10. Share successes (and failures).
Each software project teaches lessons. What was done well? What went wrong? Pass these lessons on to the next team and throughout the organization so the next project is even more successful. In Agile we build this into the process itself, with regular retrospectives to see what’s working and what’s not. We may be tempted to hide our mistakes, but sharing them can lead to big future gains.
One final point to remember is that when it comes to successful software delivery, your team’s focus should not be on competition. It should be on construction. How your team plays—the process—is what will deliver a win. This starts with picking the appropriate strategy for your project and finishes by adhering to best practices to make sure you create a product you can easily “sell” to your users.
