High-Velocity Software Development

Introduction

High-velocity software development is a framework to maximize returns when developing custom software. The approach focuses on integrating a technology partner within the entire business development ecosystem and provides best practices for the entire life cycle of your intellectual property.

Problems High-Velocity Software Development Solves:

1. Loss of control and visibility over your process
2. Skills Gap / Reliability / Security
3. Poor communication between parties
4. Unclear delivery expectations
5. A lack of understanding of “the big picture”
6. Speed of development
7. Software projects do not Immediately generate ROI
8. Aligned IT objectives with business objectives
9. Future-proofing your applications
10. Zero cost-effectivenesses because of hidden costs
11. Problems with language
12. Product quality control
13. Stable Business Partners

To best illustrate this let’s look at Acme Inc and see how this approach can help them:

In a board meeting, some of the members of Acme Inc have expressed concern that there is a need to increase their technological footprint. Competition is starting to take a bigger piece of their pie and they need to respond or risk yearly decreasing revenue in their online sector. Another board member has suggested that they freeze hiring as the overhead costs are starting to have a negative impact on their bottom line. They form a steering committee to review the issues and convene 1 month later.

After a few sessions, the steering committee has determined that moving to a paperless office could greatly reduce the overhead and need for additional employees. It also has determined that a new app that allows customers to easily manage their own accounts online would reduce a large amount of inbound customer support calls. They have also decided that in order to cater to their younger consumers an easy to use app could increase their sales significantly. They decide to move ahead and start discussing implementation.

After reviewing the current workload of his staff, the CIO has determined that they can start these projects in 6 months when the current workload dies down a bit. They could divert one or two individuals, but not all the resources they would need. They would need to hire more personnel to start the project right away. Immediately, the project is delayed.

After a month or so go by, overruns and scope creep within existing projects push the start date out another 2 months. So now in order to respond to the changing market, Acme Inc. needs to wait 8 months before they can get started to address the issue. Now the company has a choice, do we hire more developers, do we outsource the project, or do we wait until our resources are available?

Rule # 1: Do not wait and do not hire right away.

Technology initiatives take a larger number of resources to get out of the ground and smaller teams to maintain or update. This presents the perfect opportunity for outsourcing. By outsourcing, you can start at full speed with a cohesive team from day 1 and add immediate value to your project, while reducing your long-term costs associated with hiring more internal resources.

Outsourcing does not mean giving up control over your project. Whomever you choose as your technology partner should work as an extension of your organization. High-Velocity Software Development (HVSD) focuses on selecting the right technology partner because it is the most important decision made before one line of code is written.

First, identify the people that will be working with your technology partner daily. In-house software engineers, QA team members, and visual designers, etc. Make sure to provide enough engineers as needed to maintain and support the project after completion. This is integral to the success of the HVSD approach. Your technology partner will be expected to mentor and support these team members while your initiative comes to fruition. An invaluable amount of knowledge is transferred between the technology partner and your team naturally over the course of development, leaving you with a highly educated and competent in-house team once your project is completed.

If your company does not have the resources in place initially for maintenance and support that’s ok. Early in the process you should be able to identify the skill-sets needed and hire appropriately. However, hiring for highly skilled positions is difficult and more of an art-form than a science. Select a technology partner that provides hiring as one of their services, take advantage of their experience, and make sure that the process can be tailored to you. The result is faster hiring, a more skilled workforce, and employees that both parties agree upon. Interviewing and agreeing upon hire is something you would do internally, so include your technology partner and leverage the years of experience they bring to the table. In HVSD, your technology partner is treated as an extension of your company.

As stated, selecting your technology partner is the most important step in HVSD. Below are some of the most critical requirements of an HVSD partner. Making sure your technology partner is implementing these suggestions will increase your project's success rate.

Your technology partner must provide a team made up of 100% Senior Level Developers:

• An all senior-level developer team creates a much higher throughput than traditional teams. They are typically more expensive hourly but more than makeup for it with the amount of work they churn out.
• Senior developers look at the project from end to end. They are more capable of aligning business goals with development, understanding the entire dev-ops life cycle, and heading off problems before they become an issue.
• Senior developers can Jumpstart a scalable infrastructure. They typically have experience with cloud-based solutions as well as a host of other practical experience building out infrastructure. No need for a separate team to do this.

Your technology partner must have a proven method of acquiring, and mentoring top notch talent:

• Utilizing your technology partners expertise in hiring highly skilled labor has several advantages. It mitigates risk, allows for a more curated team, and makes sure you are getting the skill-sets needed to complete your initiative on-time and on-budget.
• Internal resources can be brought on incrementally allowing you to gradually build an in-house talent pool capable of supporting and maintaining your applications.
• Your technology partner should provide a means to mentor your legacy team, or new hires, in a way that allows for a natural transfer of domain-specific knowledge. This allows them to drive HVSD elsewhere within your organization.

You must integrate your own team members into the project:

• By integrating a small team within the development process, you can gain much better insight into delivery expectations, quality control, etc. Overall visibility into the project is much greater.
• Your technology partner should be responsible for tech, your company is responsible for vision. This delineation is important. It allows your project to stay closely aligned with business objectives and leaves the implementation of technology to the experienced team you partnered with.
• By being part of the development process, you can communicate the “big picture”. Openly discuss endgame goals and include the development team. It will make the team more engaged, drive better solutions, and ultimately a better ROI.

A typical project management structure for HVSD:

Rule #2: It’s a jigsaw puzzle, start with the corner pieces:

Why do you start with corner or edge pieces when putting together a crossword puzzle? They have the most ROI. Do the same when aligning your business goals to your project deadlines. Take the time to define smaller deliverables that will be able to generate ROI right away. Focus on building out those pieces first and getting them to market. With a structured plan, the development team will be able to work out how to deliver incrementally without having to write the entire application at once or rewrite pieces to make sure they work together.

By introducing your application and then incrementally adding features, you not only start generating ROI immediately, but your user base will recognize that the application is being continually improved. New features are exciting and help to retain your user base.

Rule #3: Be agile, use agile, but make it your own:

According to agle-procees.org, “the most important thing to know about Agile methods or processes is that there is no such thing. There are only Agile teams. The processes we describe as Agile are environments for a team to learn how to be Agile.” Most companies will say they use “Agile Software Development Methodologies” but as we just said that really doesn’t mean anything.

There are literally hundreds of ways to formulate your project management structure. What we have found most efficient over the last 20 years is to utilize an Agile Scrum methodology, coupled with pieces from Kanban, Extreme Programming, Feature Driven Development, and many other project management styles. If you followed Rule #1 you have already put yourself in a better position to have a truly agile team.

Agile Scrum typically organizes delivery schedules in two-week time-frames called sprints. Each sprint has tasks that specifically address part of a business objective. The tasks are split up among the team members, organized in Kanban, and discussed daily during the stand-ups.

The product owner should work with the project manager to outline what success looks like for the next sprint. As we stated in Rule #2, start with the pieces that provide the most ROI and build upon them. Outline user stories and requirements for each task into Kanban cards for tracking. Review them with the team during sprint planning sessions to get a group consensus on timelines and the amount of effort needed to deliver. Senior-level engineers are much more equipped to interpret cards and their impact as it relates to implementation, so it only makes sense to include them in the planning process.

Each person on the project will have a slightly different view of what the “most valuable” thing to do next is. By collectively determining these tasks, identifying blockers early, and being transparent with responsibilities, each team member understands how their tasks affect one another. Every day during the sprint the “Scrum Master” holds a brief meeting where everyone can address blockers or concerns and outline what they were able to accomplish the day before. These meetings are called stand-ups and should only take 15-20 minutes. All team members participate in stand-ups, effectively eliminating the concern of visibility into your own project.

Stand-ups allow you to take advantage of group communication daily, however, there is still a need to track a lot of individual and team accomplishments. Make sure your technology partner has a means of bug tracking, versioning code, and that you have access to said information. GitHub, Trello, Slack, etc., are several tools commonly used to track and manage an agile project. They have the added benefit of working well in remote environments.

Rule #4: Set measurable success criteria every two weeks:

Incrementally measuring success avoids a project spiraling out of control. Reviewing your accomplishments every two weeks maintains a level of quality control without micromanaging team members, allows early insight into problems, and helps to eliminate scope creep.

Success criteria for your technology partner and the internal team should be different. When using HVSD your technology partner is responsible for the implementation of technology, mentoring, and delivery. Your internal team is responsible for the vision, direction of the application, and making sure they can support what has been developed. Both should be judged accordingly and evaluated constantly for areas of improvement.

At the end of each sprint, the QA team should make sure that what has been produced is meeting all end-user requirements, and that they meet quality expectations as defined in the beginning of the sprint. Bug count is one example of measurable criteria. A high number of bugs could indicate that the skill set of your team is not up to par, or your explanation of the requirements was not clear. In either case act to correct the issues as soon as possible by explaining the issues to, and getting feedback from, the entire team.

Rule #5: Future proof your application:

According to Moore’s Law the power of processing doubles every 18 months. It’s a foregone conclusion that your applications are going to become out of date quickly. This does not mean that they are no longer useful, but it does mean that security fixes and other updates will become more difficult and less available as time goes on. One way to mitigate the cost of aging software is to build your systems as a collection of smaller, digestible pieces, called Microservices.

Microservices have several advantages over traditional monolithic applications. First, they are created in isolated environments, generally with smaller scopes, making them less complicated and easier to understand. They can be written in whichever language makes the most sense for that component, or the resources available. This isolation also reduces risk because a single issue does not take down the entire application. It just affects one system and allows others to continue running uninterrupted. They can also be upgraded, patched, replaced, or scaled out without needing full regression testing like you would in a monolithic application. Microservices are just one way to aid in the future-proofing process. Your technology partner should be able to provide solutions for your specific application, and together, you should decide on the best strategy.

Consider the pros and cons around High Availability, Redundancy, API’s and partner integrations, cloud-based technologies, infrastructure, security and compliance, processing of data, etc. This will help to shape the cost, time, quality triangle and determine how to proceed with your development resources.

Summary:

High-velocity software development is a collection of best practices, that when put together produce quality code faster than traditional methods. As does the technology, best practices will evolve and are continually adjusted to reflect most efficient use of time, cost, and quality.

During the creation phase technology initiatives need larger teams in order to get your vision out of the ground. Once accomplished the support and maintenance stages typically require fewer resources, making it a prime candidate for outsourcing.

Select a technology partner that will mentor your internal resources and prepare them to maintain and upgrade your applications. It is imperative to include members of both companies to ensure visibility and the transfer of knowledge organically throughout the development process. They should work cohesively and interact daily with your technology partners' team.

Remember not to boil the ocean and isolate your project into smaller chunks, or better yet services, that can be developed independently. Judge your success every two weeks using measurable criteria like bug count. Focus development efforts around the ones that you believe will return the most ROI first.

Future-proofing your application may be one way to generate an ROI. Since technology initiatives take time and money, it’s best not to have to reinvent the wheel every 5 years. By selecting a distributed architecture your applications can be upgraded independently, respond faster to changes in technology, and are cheaper to maintain due to their smaller scopes.

HVSD strategies greatly reduce or eliminate many of the challenges associated with a traditional approach to software development.