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 time blocks 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 aren’t isolated in a single department or on a single team. Instead, building projects are 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 the queue, regardless of the 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 means 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 it can be managed” and helped them understand the importance of estimating, measuring, and tracking their project stories. This led to a solid understanding of 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 road mapped 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.
Check out our full team of amazing technical and non-technical employees
Drop us a line about your project!
Learn how our unique engineering philosophy can bring your project to the next level.
