By Belatrix Software | Topics: Software Development
One of Agile software development’s most attractive features is that it offers immense potential to increase Velocity. High Velocity levels translate into consistent releases of product into the market, harmonious Business and IT stakeholder goals, and ultimately happy end users. Velocity is a measure of how effectively a software development team is in completing its objectives (for example, user stories) during a given sprint, or series of sprints. However, simply adopting Agile isn’t an automatic recipe for optimizing Velocity. Achieving strong Velocity levels requires an understanding of the concept and a comprehensive understanding of what factors influence it. The paper addresses key factors to consider in enhancing your company’s software Velocity so that you ultimately can accelerate your innovation efforts. It also includes a success story on how one firm implemented changes to achieve higher Velocity levels.
Agile has immense potential to accelerate software development. It offers greater innovative solutioning, pulling in the collective engineering sophistication and wisdom of the team. While opting to go Agile opens up potential upside, achieving that potential — and accelerating Velocity – requires wise execution, and in depth understanding of what factors drive Velocity both directly and indirectly.
Velocity (V) is an important software performance indicator. Software Velocity can be defined simply and elegantly as follows:
In other words, how much has a given project team been able to accomplish over a defined period or iteration. Since no two Agile projects are alike, it’s important to pinpoint what units mean. Examples might include use cases, user stories, test cases, new functionality or bugs. Sprint is defined by the actual period of time in which the sprint is done. For Agile, this is typically two weeks but you might opt to define it in hours. It important though to be as consistent as possible in your definitions.
To arrive at a Velocity measure, you first have to come up with a baseline estimation. Typically, this is done by using approximately 1/3 of the time it takes you to define the project requirements and scope the total engagement. J. Jeffrey Hanson has a great paper that lays out how to define and measure Velocity.
Agile’s greatest strength is perhaps iterative approach. At the end of each Sprint, we can validate each team member’s delivery time rates to contrast with the next Sprint’s plan. At the end of the project, all of the story points are measured and velocity calculated by measuring how long it took for the project team to accomplish all of the story points during a given sprint. By sprint 3 or 4, most project teams have hit their stride. At the end of all of the sprints, you take the total # of units completed and divide by the # of sprints. That’s your velocity measure.
We now have a good understanding of the mechanics of measuring Velocity. But what are the key influencers of Velocity? What Best Practices can we apply to accelerate Velocity? There are countless factors that contribute to Velocity.
Fluctuating teams disrupt your ability to measure velocity accurately. While realistically team members can shift during the course of a project, it’s far more efficient to keep the team as stable as possible. This is important whether you are conducting a project with solely in house team members or blending a team with a partnering organization. Belatrix places a significant emphasis on stable teams. By design, Belatrix enjoys an extremely low attrition level. This helps to keep distributed agile projects on track and produces a more reliable rate of velocity.
Assembling a team with strong technical expertise is a given. It is also equally important to configure the team with the right collaboration mindset. You can assemble the best engineering talent. However, if those individuals do not naturally embrace teaming and collaboration, you will struggle continuously. Product development efforts depend on this instinct more than other areas of application development. Belatrix profiles its candidate engineers for their capacity for engage successfully in teamwork and collaboration. Not all engineers can work in an agile manner. Optimizing talent recruitment and screening processes is one best practice that Belatrix employs in setting up the project team for success.
Clients sometimes cite experience with other development teams where organizational hierarchy and culture slow down project velocity. This factor is often overlooked when constructing cross-regional teams. Yet, culture and organizational factors contribute significantly to a project team’s success. These factors can either accelerate Velocity or impede it, resulting in protracted projects, increased costs, and missed time-to-market cycles. Belatrix’s organizational structure and culture is purposefully designed to optimize the flow of information inside the team, and outside. Engineers are encouraged to think outside of the box. They can seek special technical solutions and ideas outside of the project team to accelerate overall knowledge, for example. This enables rapid iterations to get to their defined goals, and increase Velocity.
Distributed agile whether within the virtual four walls of a company or with a partner like Belatrix requires exceptionally strong communication. Furthermore, that communication needs to happen in real-time. At daily standup meetings, for example, it’s imperative that a developer be able to share a realistic picture of his/her task status. It’s equally important for the Scrum Master to be able to intuitively see if there might be a difference between what is said, and what’s actually reality. A blockage in communication can impede velocity. One best practice is to establish, and reinforce, high standards for communication. Belatrix promotes a culture of communicating, and over communicating. The goal is to create a “no surprises” environment. That translates into high transparency and accelerated velocity. This is very much a value for the firm, and is embedded in all aspects of the co-innovation process, including frequent project governance meetings with senior executive level participation.
The success of an Agile project can hinge on just how resourceful a developer is. But leaving it at that is missing a significant opportunity. Training, with a capital “T” and a small “t” can influence the technical reservoir open to that team member. This increases the likelihood that a solution will be developed quickly during the course of a Sprint. And remember, that since the goal is Velocity, speed is of the essence. Belatrix stresses the importance of its training investment, as an important contributor to overall project agility and velocity. That’s “Training” with a capital “T” referring to formal organization investment into programs with experts that cultivate deep technical insight. But there’s also the small “t” training which refers to having a culture of engineers who share their knowledge with team members and clients. That investment in continuous training, formal and informal, further increases the chances that that engineer will have, or create the best solution possible.
Product teams can achieve Velocity at great cost. For example, releasing software with bugs can carry significant product risk, to say nothing of the inherent brand exposure. Yet Agile’s strength in terms of rapid iterations and release cycles can become a liability unless Agile Testing is employed. Agile aligned testing is a best practice in increasing Velocity while still achieving high quality standards. Belatrix practices Agile Testing. Using advanced Test Automation practices enables software development to achieve rigorous release cycles which reducing the associated risk. It’s a best practice in achieving strategic product Velocity.
Here’s an example of how one of Belatrix’s client engagements effectively solved challenges and achieved high Velocity rates.
Belatrix partners with a West Coast based Financial Services firm which delivers its solutions to some 1200 companies throughout the country. The client engaged Belatrix to run alongside other providers who were working from Asia and the United States. For all of the team, story points were defined, and the teams worked in 4 week Sprints. The collaboration focused on improving the client’s technology and specifically, its application architecture.
Building a Bridge to Client’s IT – Despite a swift ramp up of all product development teams, the client’s IT group lagged behind in provisioning each team to get access to key applications. Recognizing this impediment, Belatrix met with the client’s IT department to find a solution. The answer was to create a tunnel between Belatrix and all of the client’s applications required for the development process. The solution reduced delays and increased overall Velocity going forward.
Frequency & Duration of Meetings – At the project start, the client stipulated that all QA engineers meet on a daily basis for 90 minutes. The meetings included some 20+ people from Belatrix in South America, other resources in India and the US client team). Despite lengthy daily sessions, agenda items were rarely 100% covered, resulting in additional meetings. Belatrix’s QA resources complained that the meeting prevented them from meeting sprint goals effectively. Belatrix’s Scrum Master discussed the issue with the client. The number and duration of meetings were decreased. This streamlined the Scrum process and enabled the team to be much more effective, leading to all story points met per sprint.
UX Bottleneck — Another challenge faced early on in the project involved a bottleneck in UX resources. Before progressing to acceptance, the Belatrix team needed to validate the front end of the application with the client’s UX resource. The challenge though was that there was just one UX Engineer on the client side. That resource covered not only the Belatrix team in Mendoza, but also the US and India teams. As a consequence, even when developers completed story points, it would take an extra day to get the acceptance criteria, decreasing Velocity. Belatrix recommended the client added a UX resource from Belatrix. The client saw value in this. The result. The team became much more Agile, and accomplished “Done” concepts earlier.
While comparing Velocity across multiple teams is often discouraged. In this particular engagement, the client attempted to keep certain project parameters highly consistent across projects. This allowed them to “control” Velocity inputs much more. At the end of the project, the client reviewed the Velocity measures across all of its teams – Argentina, US and Asia. Belatrix’s teams were found to have the highest productivity (even higher than those in the US).
There are countless benefits to using Agile. Increased Velocity is an important benefit and has immense potential to accelerate your innovation efforts overall. To reap the fullest rewards of Velocity, companies should strive to better understand its key influencers – organizational structure, vision alignment, communication, and people empowerment. While it does take investment, that investment pays dividends in overall innovation, software quality which in turn translate to better revenues, and loyal end users.
“Our unique platform and business model is nuanced and at times complex. I was particularly impressed by how Belatrix’s teams were able to dig into existing software applications to begin providing value early and throughout our relationship.” — Director, SW Engineering, PolyRemedy
Contact Belatrix Software to learn more about how we accelerate the Velocity of our Client Partners.