Developers, as a breed, hate processes. This is because they have seen too many processes which are just bureaucratic monstrosities imported from the manufacturing sector of the 20th century. We keep our processes light, more like group activities among a bunch of friends. Our flat culture helps.
Super quick mock UI
We started this practice almost a decade ago, and we can’t live without it now. When we get the spec for a new project, we first translate that into a full set of screens which the client can see on his browser or mobile device, so that he knows exactly what he’s going to get when the system is done. The guiding principle: no surprises.
Detailed design and WBS, where rubber meets road
The specification is converted by our architects and designers into a detailed written specification. Our design documentation can actually be read and understood by young developers — we write only what matters. Our Work Breakdown Structure becomes the burn-down chart for sprint based development after the design is done. If you can’t list each nut and bolt in detail, you can’t build it.
Sprint and exhale, sprint and exhale
We do our coding and testing in sprints, based on the Scrum methodology for fixed-spec projects. Each sprint is just 2-3 weeks, and the client gets to see something real at the end of every sprint. No proof of any pudding like the eating, we say. Clients agree. Develop in a brief bursts and course correct each time.
No-nonsense stand-up meetings
The daily stand-up meetings are our reality check for our project managers. Problems are often identified, but are identified really early and are fixed promptly, or escalated without delay. The sprint team keeps, well, sprinting ahead. Conquer the whole project, one day at a time.
Release management through Git
New releases of any system are moments of truth: all the pieces must fall into place just so. We use release tags in Git to track exactly what we are going to release in the next release, and in the rare instance that there is a snafu, we can roll back to any past release. A release is a very critical checkpoint; make it your friend.
Code review, where we take no prisoners
We have code reviews through automated tools (Sonarqube, remember?) and through peer review of code. Each team member spends an hour each day either having his own code reviewed by his colleagues or reviewing a buddy’s code. Works wonders to break silos within the team and spread the good word about best practices. Share your quality thoughts, let the whole team grow, on clean wholesome code.