If you’ve ever spent any time on project management, you’ll know that there are lots of project management methodologies and techniques out there. Waterfall, Kanban and Agile to name a few. There are many more, and each one has its own advantages and disadvantages. At 729 Solutions we use a derivative of  the eXtreme Programming (XP) Agile methodology called Velocity Based Agile as our number one way of ensuring success and delivering outstanding customer service.

What exactly is Agile Software Development?

Agile is a productivity and project philosophy that emphasizes frequent iterations, adaptive planning, continuous integrations, complexity based estimations and cross-trained, cross-functional, self-organizing teams. Agile is a popular project management philosophy for one main reason: it works. It can be used by any business, from the smallest one-person startup to expansive global corporations. Many companies that are familiar to you, such as Salesforce, Amazon and Facebook all use Agile software development to move quickly with new releases several times per day. This methodology is ideal for modern software development because the end product never matches the initial vision of the project, but it can be used for anything with dynamic requirements. The ability to make regular course corrections combined with a real time understanding of the impact of those changes is what makes some flavor of Agile the appropriate way to approach software development.

What is Velocity Based Agile?

Agile comes in different flavors, with each individual business adopting it to fit individual needs. Based on our experience over hundreds of projects we’ve developed our version called Velocity Based Agile. Founded in eXtreme Programming (XP), Velocity Based Agile’s hallmark is using historical  performance to predict future progress. Velocity is a measure of progress over time using complexity based estimates in place of hours based ones. This approach reestablishes the relationship between Time, Cost & Scope by asking :

“How hard is this work and how many people do we want to work on it?”

It has been our experience over the last 15 years that using historical performance to calculate the cost of X resources used for Y timeblocks at Z rate is extremely accurate. By comparison upfront, time based, estimates are inherently inaccurate and do not provide a mechanism to adjust resource count, milestones or release features to address stakeholder requirements or tangible project goals. Consistently using Velocity Based Agile allows the process to tell us what we can produce in a particular time frame, allowing time, cost and scope to be adjusted accordingly.

We use Velocity Based Agile in our unified Design, Development and Operations (DDO) approach, to keep a holistic and integrative approach to our business across these three different areas.This also ensures that information and talent isn’t isolated in a single department or on a single team. Instead, building projects is seen as a team sport where different team members will work together based on individual skill sets, interests and availability. Information is kept out of a single silo, and everyone is expected to chip in on the team goals.  Teams are important because they democratize knowledge across the company so there is no single point of failure. The next person up takes the next story in queue, regardless of skillset of experience, so the team maintains a sustainable intensity. This also means that the company has a “bus number” greater than one or two. This approach also mean that horsepower is much easier to add so you can scale when you need to. We believe that if you can’t get a new developer set up in an hour and contributing code the first day, you’re not agile and not ready to scale.

What Velocity Based Agile is Not

First, Velocity Based Agile is NOT a free-for-all. The iterative nature actually requires more discipline, not less. It also is NOT the antithesis of traditional management philosophies, but instead is an alternative approach with its own vocabulary that needs to be translated into traditional terminology Velocity Based Agile does not mean every release has to go into production. You don’t want to move so quickly that you end up being short-sighted, but you also want to avoid being bogged down in waiting until something is “perfect” to be reviewed, and possibly released. Instead, Velocity Based Agile requires frequent iterations, with continuous refactoring and improvement to keep the project moving forward quickly.

Velocity Based Agile in the Wild

If Velocity Based Agile is all about success, what does success look like? Here are two examples of how 729 Solutions used Velocity Based Agile to achieve customer happiness.

Larvol

With our project for Larvol, the challenge was helping the company move away from their traditional Waterfall methodology to Agile. We use complexity based explanations as part of story writing in Velocity Based Agile, and let historical performance dictate future progress. Unlike SCRUM, the scope of any particular iteration isn’t locked and using a tool like our partner Pivotal Tracker allows everyone to instantly see the impact of changes to scope or story order has on the timeline.

Key to making this work was to always keep time, cost, and scope in relationship with each other. We were able to give them real time clarity into the financial aspects of scope, resources and timeline.

We focused on their concept of “if it can be measured, if it can be managed” and helped them understand the importance of estimating, measuring, and tracking their project stories. This led to a solid understanding on the management level, with success shown through measured performance.

Namecheap

Our project for Namecheap had a long timeline of 18 months. It can be a challenge to meet expectations when the timeline is that long, given the frequent problems of discovered scope and evolving requirements. Using Agile we scoped and roadmapped the full 18 month project, finishing it within two weeks of the originally proposed time without increasing the cost. We communicated regularly with the client, making sure that our conversations were clear and purposeful. We also emphasized the importance of trusting the process (and trusting the experience of the 729 Solutions team) to allow Velocity Based Agile the time and resources to work.

Want to know more about how 729 Solution has used Velocity Based Agile to help our clients meet their goals? Click the button below to download the the full Case Studies.

Check out our full team of amazing technical and non-technical employees and drop us a line about your project to learn how our unique engineering philosophy can bring your project to the next level.