That the words agile, lean and scrum are by-words in the tech space is a cliché of epic proportions and yet, confusion abounds. Nonetheless, there’s no knocking the expediency of agile methodologies. The trouble with these methods though is their ever-present penchant for disordering an organisation.
Agile concepts have been extensively defined and by all indications, these meanings will continue to be refined. For the noobs, however, this is a dummy’s focus on scrum.
Firstly, agile methodology has a number of frameworks and methods in addition to scrum including kanban; feature-driven development (FDD); extreme programming (XP); lean software development (lean); adaptive software development (ASD); dynamic systems The Hunger Games Saga development methods (DSDM). Most of these are not standalone approaches for the delivery of the entire software development life-cycle. In the spirit of acronyms, here’s another – SDLC.
In practice, engineering teams will more than likely adopt some form of hybrid strategy by mixing these methods to realise the full SDLC of the products they build. Indeed, regardless of the organisation’s preferred methodology, certain frameworks are better suited for certain circumstances or stages of the SDLC. In the end, there’s a broad utility for each.
- Why Scrum
With the scrum approach, madness (read boldness) is right at home. The basis for Scrum is the empirical process control theory which postulates that in the absence of clear and verifiable requirements beforehand, the developer team will build a little by little of the product while simultaneously testing it for adherence to the client’s ambitions.
Guild Digital has a waterfall spirit and as much as possible, we try to set out from a linear place. Nonetheless, our engagements have a natural proclivity towards the scrum approach because as it turns out, we seldom have elaborate timelines. In addition, the roster of clientele we serve is, in a sincere sense, largely non-tech. This group have an oversimplified impression of software development. We euphemistically refer to this client type as “toggle”. It gets worse once they hear the magic words ‘open source’. And this is how we came to christen them.
“Non-tech” clients have a propensity for vacant and superficial demands as if in an attempt to determine the extent of the developer’s skill level. To establish their actual requirements, we have to actively sort the torrent of demands with open-mindedness. Quite often requests are made well beyond what is practically required to satisfy the formal objectives of an engagement. And for what is actually required, that must be delivered yesterday. This is where the scrum framework registers its greatest utility. With the transparency of information from the client, matched by a readiness to adapt by the developers’ team, as well as regular inspection, the scrum framework tends to produce decent results. But not without a cost. There is a downside to an agile culture that, while imperceptible at first, is usually consequential on the team and organisation.
- Mitigating with Open Source
The shift towards open-source technologies has long since gained momentum irrespective of industry, and the health space is no exception. Platforms and community thinking do guarantee more staying power than even the most popular products. This is especially true for small business tech entrepreneurs looking to sustain growth. History is rife with the litany of heedless giants that have succumbed to the momentum of platforms. Read Nokia, Blackberry, and Motorola.
While monumental success stories like Linux are all the rave, the health space has some notable successes including, CHT, Open SRP, Open Hospital and OpenEMR. Open source software custodians typically permit, and in some cases, incentivise the rights to use, scrutinise, adapt, and circulate software to anyone usually to further a universal vision. And therefore such software is typically developed in a collaborative manner.
The advantages of open source are ubiquitous but more to the point, the momentum of the strategy is inevitable. In addition to flexibility; cost-effectiveness; responsiveness; relative security; and low maintenance costs, there are more nuanced benefits enjoyed by tech entrepreneurs who adopt the open-source strategy. These might address the operational problems arising from agile and scrum cultures.
The source code of digital public goods is usually thoroughly refactored and reviewed. This does limit the propensity for poor practice like hard coding to meet short deadlines. Agile methodologies, and the scrum framework by extension, tend to normalise substandard work. The idea that complex features can be built from scratch in a few days’ sprint is reassuring but dubious. And this frequently translates to significant technical and design debt down the line or loop depending on your project dispensation (see Image 1).
In addition to insubstantial and reactive requirements, there is limited opportunity for documentation in the agile context. With the exception of sober backlog management, a lot of the documentation is facile, incomplete or non-existent. In addition, inattentive backlogging encourages premature expectations from the client and may frustrate the developers. Upon disappointment, the organisation’s brand may suffer. Open source, on the other hand, thrives on deliberate review of requirements and elaborate documentation. Brand points are saved in turn.
Considering the drizzle of requests characteristic of ‘non-tech’ clients, excellent backlog optimization goes a long way in keeping the engineers’ team from the certainty of burnout in an agile setup. With the open-source route, foundational attributes are built; properly tested; and documented before any adaptations. Building onto this and managing the resultant backlog becomes relatively lighter on account of the heavy lifting that went into the core.
- Final Thoughts
Getting your strategy and methodologies mixed right for different phases and scenarios directly affects the efficiency and delivery of quality software products. This is the hallmark of the successes Guild has registered. At Guild, we have capitalised on the best method mix. We find that along the SDLC, there is a complementarity of attributes among the different methods and frameworks.
Different methodologies equip an organisation to respond better to questions arising at disparate stages of the delivery cycle. The prohibitive and unpredictable nature of timelines and scopes underlines the need to dice and cut or hitch a platform. This flexibility significantly reduces turn-around time and saves against the cumbersome work associated with always starting from scratch.
