Scrum is a great way to rethink code-writing strategy, but only for companies whose structure supports it. Trying to layer a scrum approach on top of a traditional developer environment can deliver painful frustrations, as companies find themselves tripping over their own virtual feet.
That’s the lesson we have learned through 2017, as we tried to integrate scrum teams into existing waterfall operations for hundreds of custom development projects across more than a dozen verticals. The scrum benefits of much faster time-to-market and greater control of the appdev process melted under the load of a client’s architect and a client’s project manager.
In short, scrum almost always works faster than how a company works. Scrum is then slowed down to the pace of the original company, which is ironic because that company invariably sought the scrum talent and process because they needed to accelerate their time-to-market.
Bottom line: the only way to truly enjoy the benefits of a scrum development process is to embrace it fully, with all team members reporting to a certified scrum master in a full scrum environment. It doesn’t make much sense to deploy a scrum team within a traditional structure. The scrum approach was never designed as a hybrid answer to the struggles of software development.
The scrum approach itself is wonderfully straight-forward and is the ultimate manifestation of agile development. It breaks the project into smaller and more manageable subsets. Done properly, scrum development delivers quite a few concrete benefits. Yes, it accelerates overall development, which in turn accelerates time to market.
But that’s small compared with its other benefits that impact quality, security and functionality. By breaking the code into chunks, management gets to examine key parts of the code far sooner, allowing for much more immediate feedback. Instead of waiting for everything to be complete before management sees anything, it enables far quicker feedback. That allows direction corrections to happen much sooner in the process, at a stage before the bulk of the code has even been written.
That segmentation also makes security stronger, both by making it easier to find security problems in the (fewer lines of) code as well as identifying such issues much sooner. This also deals with an unfortunate corporate psychological reality. In a traditional appdev process, the code isn’t reviewed until it’s in an ostensibly final and complete form. At that stage, there is significant pressure to publish it quickly. That often shortens how much testing time—whether for functionality or security—is permitted, with no more elongated testing cycles.
In an agile scrum approach, the code is being tested in parts and finished in parts. That, in turn, takes a lot of the pressure off as executives understand that the code can’t yet be published. This allows more time for all forms of testing.
No longer do executives have to discover, through docs, what was the original intent of a specific product feature. The exec is connected much more directly to the developer and the product owner.
The problem with a halfway approach to agile development—an amalgam of scrum and waterfall—is that by trying to execute both, the company ends up with neither. The remaining waterfall elements burden the scrum team with labor-intensive manual interventions, which not only slow down development time but also delivers a far higher total cost of ownership, both in terms of personnel and in quality and speed of final deployment. Contrast that with the complete continuous integration and delivery options in a full scrum approach. A full scrum approach would allow companies to improve their system architectures and evolve the organization’s project design and execution maturity, while simultaneously accelerating app deployment at a higher quality level.
This leaves companies wanting to embrace agile and scrum and realize the full benefits with two practical options: Rework its internal development organization and process to internalize scrum; or outsource the process to a developer entity that has already deployed a full scrum environment.
A full scrum process requires personnel focused on project management, design, development, quality assurance, product delivery as well as sandbox hosting. Scrum requires team members to function in distinct and defined roles, all of which require different specialized skills. The team would manage numerous code reviews—featuring robust automated test suites—along with the establishment of a help desk.
Jira admin, project management and operational reporting, automation and release management would also have to be included. The size of the team would, logically enough, be based on the size and nature of the project.
In a very real sense, the problem of companies trying to make scrum work as an addon to an existing waterfall structure is a wonderful example of Harvard Professor Clayton Christensen’s theory of the Innovator’s Dilemma. That concept, the centerpiece of Christensen’s 1997 book The Innovator’s Dilemma: When New Technologies Cause Great Firms to Fail, argues that value per iteration makes innovation difficult, unless a company focuses on the long-term—a rare happening when most C-levels have been beaten into submission with Wall Street’s quarter-to-quarter focus.
In a developer environment reality, these halfway measures force coding to happen within a company’s existing infrastructure, which makes true innovation difficult and makes revolutionary improvements just about impossible.
The scrum approach is also better because it’s a more natural fit for the best developer talent. Envision artworks where painters had to clear each color choice and how thin every brushstroke would be. Coders are creative professionals. Leverage that creativity, rather than beat it into submission.
A more corporate analogy might be the company mission statement. For far too many businesses, that mission statement is written by committee and is often void of passion and a perspective. It’s been sanitized to the point of having no soul left. In a sense, forcing creative coders into traditional approval processes similarly dilutes the quality of the code, just as a committee can dilute the quality of a mission statement.
This may be just a process problem, but it’s an immense one. A robust scrum deployment is inherently not risky as it allows management to see activity as the coding is happening. Any hiccups should be identified—and fixed—far earlier, making scrum a perfect diet for any risk-averse executive. But like most diets, it can’t be executed partially, assuming you want to see the benefits.
