vDev - High Velocity Development Methodology

Mon, Jun 1, 2015, by Jeremy Chone

Speed is how fast something moves, velocity is how fast something moves in a given direction. In software terms, we could say that speed is how fast code gets produced (e.g., proof of concept, demo, first pass at something), whereas, velocity is how fast an experience gets delivered.

Unfortunately, speed has been the obsession of our industry lately, to the point that we have become accustomed to switching programming languages and whole technology stacks every couple of years under the promise of new, unparalleled developer productivity and application performance. The assumption is that if one developer could do Y in one day, thanks to a great new technology or framework, then, it will obviously linearly scale with time and developers. Managers hear what they want to hear, developers use what they want to use, and the honeymoon starts.

However, the truth of the matter is that what makes things easy and fast to start with is not necessarily what makes them finish faster or with higher quality. In fact, the opposite is often true, as technologies that overly focus on “easiness” and initial speed of development often have to make design abstractions and tradeoffs that make things much harder later on. In other words "easy technology" often makes a product easy to start but hard to finish. And to make matters worse, we (tech people) have a natural tendency to convince ourselves that the bigger the disruption the bigger the progress, hence, this constant race to rebuild everything for the sake of the holy grail language, framework, or runtime.

The subtlety is to understand that maximizing speed and quality of delivery does not come from finding a new exhilarating language, the latest all-in-one-solve-it-all framework, or the new agile process, but rather, about realizing that software production performance comes with how everything fits together into a comprehensive end-to-end methodology that encompasses process, technology, and best practices that reduce frictions and redundancy to maximize throughput and precision. And that, is more about evolution than revolution. For example, it does not really help velocity if a feature takes a week to develop, but a month to specify, and three weeks to deploy.

Over the years, @BriteSnow, we have been perfecting a holistic High Velocity Development methodology that streamlines design, development, and deployment into a frictionless, highly iterative, and outcome centric process that is combined with a mature, scalable, and modern technology architecture and best practices. This methodology allows development teams to dramatically increase their speed and quality of delivery while investing in future-proof raw technologies rather than in the frameworks and tools of the moment.

We are calling this methodology High Velocity Development Methodology (#HighVelocityDev).

High Velocity Process - (5Ds process)

At the heart of the methodology is a highly iterative process with well-defined phases that consist of defining and pushing small actionable parts (i.e. feature spec or micro-story) from the definition phase to the distribution and distillation phases. The key here is to define the atomicity of the parts in such a way that they can be defined, designed, implemented, and distributed (even if the distribution is only internal) mostly independently. This will maximize parallelism, simplify problem solving, and dramatically increase the responsiveness and feedback cycle.

Here are the five phases we are using.

(Idea to requirements) This phase is about conceptualizing and prioritizing the vision into a set of “top features” (often organized by Modules) that are then articulated into set of “actionable business wireframes.” The magic of this phase really happens when the business/visionary contributors are taking the time to articulate their requirement into a “business wireframe.” A picture is worth a 1,000 words, not only for the people looking at the picture, but also for the one(s) creating it.

(Requirements to Spec) The “business wireframes” gets re-organized into fully thought out user task flows to be fully visualized into UX mockups as “actionable screen flows” (i.e. stories). Note that the most important point of this stage is screen flow and layout (i.e. UX) as the look of the application is something that can be gradually improved over the development of the project. At this phase, keeping the user experience as simple and minimalistic as possible really pays off as functionality grows.

(Spec to App) Each “actionable screen flows” output from the design phase often result to one “ticket” in the issue tracking system, and with the right technical architecture, can often be coded and tested in parallel to others (even when related). The trick of this phase is to keep all the project actors (QA Engineers, Designers, and PMs) as close as possible to the code and the developers, hence, the great benefit of keeping everybody using GitHub and its issue tracking, which can be made extremely powerful and extensible when using the right label methodology.

(App to User) Once a business milestone is reached, or a set of fixes or micro enhancements are ready to be deployed, the distribute phase is about deploying those new bits into the production server and measuring system performance, usage, and user feedback. Here, monitoring is key, as gathering usage and performance information will help the next phase and because it is instrumental to understand what needs to be optimized. Blindly optimizing everything we can think of based on some best practices can be counterproductive.

(User to Idea) And last but not least, once the product is running, one of the most important phases is to analyze usage and user feedback and to coalesce it into a new, comprehensible set of ideas that can be injected in the definition phase of the next cycle.

It is important to understand that many of these “5 phases process wheels” can roll at the same time, as one could be for your beta 01, another would be focused on beta 02, and some other can run on a feature branch.

Guiding Principles

While describing our technology stack and best practices will be a topic for other posts, here are some of the principles that are guiding our technical choices and approach.

Keep Things [truly] Simple: Don’t over anticipate complexity by proactively adding indirection layers, complex tooling or processes, or other types of unwarranted complexity. Start with what you have to have (e.g. Github, JS/HTML/CSS, server, and database) and see what is the minimum needed to make the environment and process scalable. Know where complexity would fit in the architecture or process when and if it will be needed, and keep environments, process, and best practices as minimalistic as possible. Chances are that most of the time you won’t need the added complexity everywhere, allowing you to better focus where it is really needed. For example, favor the best of breed technologies over all-in-one-solve-it-all high-abstraction frameworks, choose technologies and tools that enable best practices rather than enforcing them, and prioritize simplicity over easiness.

Embrace Your Environment, Don’t Fight It: Using technologies that completely abstract an underlying environment (e.g., language and native APIs) into something completely different but familiar often results in quick and exciting starts but laborious and frustrating finishes. At the end of the day, frameworks come and go, languages and runtimes stick around. Consequently, choose minimalistic frameworks and libraries that empower the underlying environment (API or runtime) rather than those that completely abstract it into something completely different. In other word, if you do Web, learn the DOM, if you do database, learn SQL, if you run on a JVM, learn Java, and if you do AWS, learn AWS tooling. Too many “very smart” frameworks or tools are trying too hard on disfiguring their respective runtime environments for the sake of productivity, which actually end-up hindering them.

Favor Maturity Over Trendiness: Use mature tools and technologies with modern best practices rather than changing tools and languages too often for the sake of some magical productivity. Most of the time the programming language is not the problem, but how it is used. Obviously, this is not to say to not evaluate new tools from time to time, but the switching driving factor should not be taste, but real values across the full development process and technology stack. For example, changing a runtime language is more than a technical choice, but also has a strong social and cultural impact in a development organization.

Make everything actionable: Commonly produced, long, and holistic descriptions, specification, or documentation tends to be very costly to create, maintain, and communicate. On the other hand, splitting information and definition into smaller actionable parts dramatically increases collaboration between the project actors by making these smaller parts easier to define, describe, and execute.

Reduce friction by reducing tool proliferation: One of the most unintuitive aspects of this process is to acknowledge that the proliferation of tools, documentations, and languages often adds more friction than the value it brings. The art of the high velocity development methodology is to build a highly scalable development process with the minimum set of tools and languages. In other word, use less tools but share them more across all of the phase’s contributors.

Make the product become the spec: One thing that all modern software managers should realize is that the time of a complete, holistic, up-to-date product specification is over. Software development is going too fast for this, and we should all embrace that eventually (around the last beta or 1.0), the product becomes the spec.

Be Disciplined: The least fun of all, but probably the most important. Quality does not come by luck but with discipline. In a high velocity development process, everything goes very fast, and while it is tempting to adopt the “cowboy attitude,” it is critical to have strong discipline. Have a clear process and technical approach and best practices. Only break rules when strictly needed and fix them as soon as possible.

Conclusion

In short, High Velocity Development is more than a framework, a tech stack, a process, or even best practices, it is about how everything fits together into highly iterative methodology that minimize frictions and unwarranted complexity to maximize speed and quality of delivery.

Now that we have gone through the top down description of our High Velocity Development methodology, our next posts will be about getting into the bits of our process, technology stack, and best practices.

If you liked this blog post tweets and shares greatly appreciated.

vDev Process & Roles & Deliverables >>

BOOTSTRAP YOUR WEB APPLICATION

Idea to Pilot in 3 weeks (hosted on AWS)

Get Started Now