The many faces of Agile

Agile is an umbrella term, not a monolithic entity. The Agile Alliance describes Agile as “the ability to create and respond to change in order to succeed in an uncertain and turbulent environment,” while giving a longer and much more specific definition for Agile software development.

Beyond that, Agile is being implemented from a variety of perspectives. Here are four interesting Agile methodologies, approaches and strategies that haven’t flown as high on most radar screens as the widely heralded Scrum, Kanban, Test-Driven Development (TDD), and Extreme Programming (XP), for instance.

Mob programming
Mob Programming first received its own formal description in an experience report at Agile2014. In the report, Woody Zuill discussed the experiences of his software development team at Hunter Industries.

The team at Hunter planted the initial seeds for Mob Programming back in 2011 while practicing TDD and Coding Dojos to get up to speed on a project which had been placed on hold for several months. “A gradual evolution of practices as well as a daily inspect and adapt cycle [resulted] in the approach that is now known as Mob Programming,” according to the Alliance.

An extension of pair programming, in which two developers work together while sharing the same screen, Mob Programming requires all team members to collaborate continuously on a single computer. Yet although all of the production code and most of the team’s other work gets done on the “main” computer, developers can use their own laptops for “searching, trying things, reading documents, or whatever an individual would like,” Zuill wrote on the MobProgramming.org website.

Multiple monitors or projectors can be used, too, making it easier to open and share several applications at the same time. The customer is also part of the team, sometimes sitting in the same room as other team members and sometimes chiming in with feedback via remote screen sharing, instant messaging (IM), or phone.

‘Descaling’ the organization
Ironically, descaling is a common practice for scaling up Agile development. “Scaling by descaling breaks down things into smaller bits: small autonomous teams, smaller product backlogs, etc. In practice it works better than complex processes,” maintained Patric Palm, CEO of Favro, in an interview with SD Times.

“Agile teams optimize flow by chopping everything into tiny pieces,” concurred Peter Merel, founder of the XSCALE Alliance, an Agile coaching organization. “Tiny plans, tiny meetings, tiny requirements, tests, sign-offs and retrospectives. Making these things tiny enables teams to review and refactor them in tiny ceremonies, boosting productivity through continuous negative feedback.”

Some Agile experts now advocate “descaling” the entire organization, as well. “Scaling is an anti-pattern. Big meetings, long loops, slow cadence, tight coupling, and deep hierarchies represent bottlenecks no matter how Agile an individual team may be. Descaling refactors your organization into self-managing streams of self-organizing teams working together like pods of dolphins,” contended Merel, writing on LinkedIn.

Australia-based Fairfax Media Group has transformed its Domain Group business into an Agile organization through descaling, illustrated Stuart Bargon, who served as Agile product lead at Domain.com.au.  

“Descaling through organizational change” is actually the primary purpose of one Agile methodology, dubbed Large-Scale Scrum (LeSS).  “Descaling the number of roles, organizational structures, dependencies, architectural complexity, management positions, sites, and number of people. LeSS is not about scaling one team into multiple teams. LeSS is about scaling up Scrum itself in order to achieve organizational descaling,” explained Viktor Grgic, a software developer, Agile coach, and certified LeSS trainer.  

“Just like Scrum, LeSS removes your organizational band-aids that apparently solved the problems, but actually masked them and didn’t address the root causes,” Grgic wrote, in a blog post on the LeSS site.

Crystal methodologies
Alistair Cockburn was one of the 17 software development luminaries who got together in Snow Bird, Utah in 2001 to forge the now famous Agile Manifesto. While working at IBM, Cockburn had developed Crystal, a family of methodologies for object-oriented programming. The most structured of these approaches, Crystal Diamond, is targeted at large projects, whereas Crystal Clear is a much more fluid methodology for teams of one to six developers.

Crystal methodologies revolve around seven properties: frequent delivery; reflective improvement; osmotic communications; personal safety; focus; easy access to expert users; and a technical environment with automated tests, configuration management, and frequent integration.

According to David Lowe of the Scrum & Kanban website, it’s quite apparent that Crystal had a profound impact on the resulting Manifesto. However, not all of Crystal’s terminology made it into the groundbreaking document, including reflective improvement. In reflective improvement, team members get together regularly to talk about how to improve a project – certainly not a revolutionary notion today, but Crystal first saw the light of day in the 1990s.

Crystal is still highly regarded by many Agile experts. Yet as Lowe suggests, its adoption might have been limited by the fact that the methodologies are tailored to Agile developers so advanced that they’re already writing their own rules.

“It’s kind of a catch-22 designed to avoid followers. Evidently I’m no good at business models,” quipped Cockburn, who now teaches about Scrum as well as non-Scrum approaches.

Bell Curve-based Agile Delivery Model
The Bell Curve-based Agile Delivery Model stepped into the limelight earlier this summer in a post by Santosh Balan, technical projects manager at Fujitsu, published in Information Week. As proposed by Balan, Bell Curve-based Delivery enables teams to ease into projects gradually by considering technical complexity along with business value when organizing and tackling items in the product backlog.

By focusing first on tasks that are less complex, but which also deliver business value, an Agile team can gain early wins that build team morale and stakeholders’ confidence, even while the team is still working out the myriad intricacies of onboarding new members and embarking on the project.

The most difficult and critical high-value tasks in the project can be deferred until the team has refined its practices well enough to reach peak performance. Finally, as teams begin to dissolve at the end of the project, members can wrap up by completing non-critical features.

In response, Palm characterized the Bell Curve-based model as a great “way of thinking about the Agile delivery model with group maturity in mind.”

Bell Curve-based Delivery could be overlaid on to various Agile methodologies, such as Scrum and Kanban, Palm theorized. It might also make sense to go after tasks such as technical risk evaluations at the outset, “so that you don’t save the biggest risks until later on,” he told SD Times.

The 2018 Agile conference is going on this week in San Diego. Learn more: