While many software executives are beginning to realize that agile development, lean startup methodologies, and high speed to MVP are more than just disruptive technology or the latest trendy tools, most of the literature on those subjects tends to be either too abstract or too tool-focused to provide enough insight on what really matters.
Our goal behind this series of High Velocity Development (vDev for short) articles is to fill this void by sharing our end-to-end (i.e., idea to application) experience of building great cloud Web and mobile Web applications and showing concrete examples of how to apply this methodology with real product initiatives.
As a passionate software builder, I have become obsessed with speed and quality of delivery, and after almost two decades of building and managing software development and one decade of building cloud applications after cloud applications for our clients, the three following core development principles have been a recurrent theme:
- Discipline drives quality
- Focus drives precision
- Expertise drives speed
While those terms might sound too old school to trend, it is how they get applied with a lean but structured process, clear roles, and “forward deliverables” that really make the difference. In fact, our vDev agile development methodology is the product of those three core principles and the cherry picking of the best parts (i.e., avoiding the dogmatic parts) of modern and agile software development processes such as Kanban and Scrum to name a few.
The gist of the vDev methodology is to bring discipline with a lean and iterative process, progressive focus with a clear set of roles that encourage constant prioritization and clear actionable deliverables at all levels, and expertise by providing modern best practices based on mature and robust technology.
Following our previous vDev methodology introduction, this article goes the next level down to explore how the right set of roles and deliverable goals can dramatically improve speed and precision of vDev 5D process.
The Process (quick recap)
As mentioned in the previous vDev article, we have defined the following five iterative phases (5D process).
It is important to note that those process cycles are highly incremental, meaning that you will do a full cycle for each milestones (e.g., Alphas, Betas, and MVP), allowing you to focus on the next most-important product value to expose while gathering feedback for the next milestone.
As we are going to see in the next section, the vDev methodology secret sauce is about mapping this structured iterative process with a clear set of roles and actionable deliverables.
From our experience, no matter how you look at it, effective software development always requires the following six key roles.
Optimally, a lead role is fulfilled by one and only one individual, but in smaller organizations, such as in a lean startup environment, multiple roles can be fulfilled by the same individual assuming he or she has the corresponding expertise. In some circumstance, one role can be shared among multiple individuals, although it often is more optimal to have one individual assuming its lead position.
Regardless of which actor is playing which role, the most important point is that each role be played whole-fully and truthfully, allowing each role to have an independent voice fully focused on its respective purpose. For example, if the Dev Lead assumes the role of the Functional Lead as well, it is critical that the “what” (i.e., Functional Lead role outcome) does not get too tinted by the “how” (i.e., Dev Lead responsibility).
Forward Deliverable vs. Content Deliverable
Now that we have a common understanding of the vDev basics, process, and roles, we need to define what each of those five phases should produce for maximum overall velocity, and that is where the magic happens.
Commonly, even in modern agile software development methodologies, phase deliverables are thought as "content deliverables," which is a set of documents and assets that get produced to holistically express each phase’s intent in its most convenient format. Each deliverable produced then needs to be re-articulated by the next phase’s actors to be effectively consumed to produce the new-phase deliverables. For example, a definition phase might output a long bullet-point-formatted Google document, which the designer will need to re-articulate and split apart into a set of wireframes to produce another complete set of UI specifications, which will in turn need to be split apart into a set of actionable work units by the Dev Lead. In short, a lot of slicing and dicing. While, modern agile development processes and the lean startup methodologies do help this process a little by shortening and simplifying cycles, they tend to stop short of redefining the deliverable model, and this is where the “forward deliverable” model comes in.
The "forward deliverable" approach is about focusing each phase’s outcome to produce the strict minimum information needed for the next phase in its most optimal and incremental consumption format. In other words, rather than having each phase produce long and holistic documents that often get lost in translation, each phase would produce a stream of incremental and actionable parts in the most optimum format for the next consuming phase. For example, the Define phase will produce a stream of small bullet-point lists and corresponding “business wireframes” per core features, which in turn will be further refined (or refactored) by the Design phase into another stream of incremental actionable developer work units in the form of GitHub tickets.
Process, Roles, and Forward Deliverables
Bringing everything together, we get the following iterative workflow.
First, the Business Lead defines the core product value, the target audience(s), and business opportunity, and then works with the Product Lead to crystallize and prioritize the product features into a very short list of bullet points and a set of raw but meaningful wireframes. Those “business wireframes” are not thought to be full UX wireframes and can be done in PowerPoint, keynote, balsamic, or optimally in SketchApp, but they must express the fully thought-out core values (i.e., core features) of the product and be organized optimally.
The Product Lead then works with the Design Lead to structure those “business wireframes” into a stream of incremental, fully thought-out “UX wireframes” that can be directly entered into the developers’ favorite ticket system, which is inequitably GitHub nowadays. With the model, the look and feel of the application can come progressively as the application is being developed, because the most important thing to get right is the structure and flow (i.e., UX) of the application.
The Dev Lead works with the Design, Product, and QA Leads to define the “micro-spec” and issue formats so that most of them represent at most half to one developer day of work. While there might be some bigger specification that would need to be split into smaller tickets, maintaining relatively small work unit granularity will help with development velocity and visibility.
The Operation Lead, with the Dev and QA Leads, defines an iterative, repeatable, and high-fidelity Dev to QA, to Stage, and to Production process. The Operation and Dev Lead also need to consistently refine their tech stack and respective environments to continuously simplify production requirements while maximizing developer productivity. Simplicity is something that you continuously have to work toward. For example, putting too much emphasis on the “micro-service-for-everything-and-anything” can be as detrimental to velocity as an all-in-one-monolithic application.
And finally, the Operation and Dev Leads work together to provide usage, performance, and feedback data to the team so that the distillation process can initiate the next cycle.
The key to this process is to strike the right balance between functionality breadth (i.e., number of functionalities) and specification depth (i.e., how fully thought-out functionality specifications are), and while this take some expertise to get it right, the concept of “forward deliverables” really helps each phase’s actors to focus on what matters most for the next phase, which maximizes momentum while keeping the workload as efficient and incremental as possible.
To summarize, the crust of an effective agile and high-velocity development process is less about fancy naming and disruptive tools or languages, and more about defining a well-thought-out iterative process with a clear set of roles and forward-looking deliverables that bring a minimalistic but robust and predictable production chain.
In the upcoming vDev articles, we will move to the next level regarding how we can implement an incremental and scalable structured development process based on Git and GitHub issue tracking and labeling (i.e., 100% GitHub, 0% Jira).
If you liked this blog post, tweets and shares are greatly appreciated.