Software ‘geeks’ have much to teach the suited and booted about agility in business

Soft­ware devel­op­ers used to get a raw deal. Con­signed to a life work­ing in some win­dow­less base­ment office loca­tion, their predilec­tion for low-grade piz­za and exces­sive con­sump­tion of Coke or Pep­si helped to craft a stereo­type that endured for many years.

But now it’s chic to be geek. Ele­vat­ed through star hack­er roles in Hol­ly­wood movies and cham­pi­oned in var­i­ous TV com­e­dy series, the coder com­mu­ni­ty has gained a new lev­el of respect. An aster­oid is about to hit Earth and the planet’s laser beam defences have been com­pro­mised by non-state actors shar­ing con­t­a­m­i­nat­ed appli­ca­tions across the dark web, you say? No prob­lem, call the soft­ware engi­neer­ing team’s super-hack SWAT squad. Only coders can save us now. 

If we could take some of the hyped-up go-get­ters on The Appren­tice TV show and give them a month’s hard cod­ing, we’d all be in a bet­ter place

But soft­ware pro­fes­sion­als aren’t just for aster­oid attacks or Christ­mas. They play a spe­cial role in trans­lat­ing busi­ness log­ic into the “require­ments” phase that pre­cedes appli­ca­tion devel­op­ment. They know how to cre­ate secure apps that work as intend­ed and can change when need­ed.

Nobody needs to be told that the world had to rein­vent many of its oper­a­tional sys­tems, sup­ply-chain inte­gra­tion points and end-user inter­faces through­out the Covid-19 con­ta­gion. But, equal­ly, few will per­haps realise how exact­ing and essen­tial­ly agile the archi­tec­tur­al sys­tems engi­neer­ing was that went on beneath the sur­face. 

Going for­wards, then, what major lessons can an organisation’s busi­ness func­tion “suits” learn from devel­op­ers when it comes to work­ing in an agile way?

Programming perfectionists

Soft­ware engi­neers are per­fec­tion­ists, which is a good thing. It’s a good thing when it comes to the secu­ri­ty of the bank­ing app on the smart­phone in your pock­et and it’s a good thing when it comes to keep­ing the apps that run the nation­al grid oper­a­tional. 

OK, the nation­al grid doesn’t run on an app, it runs on a com­pre­hen­sive tier of man­age­ment soft­ware that fea­tures heav­i­ly cus­tom-built opti­mi­sa­tion and spe­cif­ic con­trols for its use case. That’s not the point. The point is that it works. Soft­ware devel­op­ers call non-func­tion­al soft­ware code brit­tle or flaky, both of which are quite emo­tive terms for some­thing so essen­tial­ly vir­tu­al and dig­i­tal.

Because they work with algo­rith­mic log­ic in a math­e­mat­i­cal­ly defined world, soft­ware pro­fes­sion­als see a com­par­a­tive­ly chiaroscuro view of the world. Some­thing is either cor­rect or it isn’t. 

While this black-and-white approach won’t nec­es­sar­i­ly work for care work­ers, teach­ers or under­tak­ers, the les­son for busi­ness­peo­ple is still there. Look for the neg­a­tives, audit for inef­fi­cien­cies, dis­cov­er sta­tis­ti­cal out­liers, find the super­flu­ous white noise clog­ging up human work­flow sys­tems and address it. 

We can apply an addi­tion­al busi­ness-cen­tric lay­er of empa­thy and under­stand­ing here (please don’t fire every­body work­ing at less than 101% capac­i­ty tomor­row) and take this mind­set for­ward. 

Tech­nol­o­gists wouldn’t leave a book unfin­ished and often don’t leave their key­boards until the sun comes up, if a job isn’t com­plete. Yes, busi­ness­peo­ple do that, too, but they’re often look­ing for ways “around” a prob­lem; soft­ware engi­neers are look­ing for ways to “solve” a prob­lem. 

When an organ­i­sa­tion starts to dove­tail this approach across its busi­ness func­tion and its tech­nol­o­gy func­tion, then it arguably becomes the most agile ver­sion of itself that it can pos­si­bly be.

Developers accept the inevitability of chaos

Pic­ture our soft­ware devel­op­er hunched over their key­board. Some of that stereo­type is still there, with the unkempt hair, heavy met­al band T‑shirt and an insis­tence on wear­ing shorts in win­ter. But look clos­er for a moment. There’s an almost hang­dog look about the expres­sion on our coder’s face – and that look means some­thing. 

The agile engineer’s air of slight­ly benign res­ig­na­tion is because of users. The devel­op­er needs them because some­body has to use the soft­ware at the end of the day. But essen­tial­ly, as always, the user will either ask for unrea­son­able appli­ca­tion func­tion­al­i­ty changes or break the exist­ing soft­ware sys­tem by attempt­ing to do the wrong thing with it.

The soft­ware team accepts the inevitable chaos that users and, indeed, the devel­op­ment team itself will cre­ate on a dai­ly basis. This is the epit­o­me of agile soft­ware method­ol­o­gy, ie, the con­stant of change. As the Agile Man­i­festo states: “Wel­come chang­ing require­ments, even late in devel­op­ment. Agile process­es har­ness change for the customer’s com­pet­i­tive advan­tage.”

If we had built our inter­na­tion­al busi­ness sys­tems with just one per­cent­age point more of this ethos in mind, we might have been able to acti­vate change more rapid­ly through­out recent times of dis­rup­tion. 

The devel­op­er knows that how­ev­er per­fect their soft­ware prod­uct is on the day it hits “live pro­duc­tion” sta­tus, once users get involved, things will hap­pen. For them, it’s like tak­ing a Labrador pup­py to a children’s birth­day par­ty; it might start out look­ing clean and tidy, but it’s bound to come back cov­ered in cake and ice cream. 

Under­stand­ing the inevitable chaos that exists in the real world is an impor­tant busi­ness les­son but too many busi­ness­peo­ple can only see the win-win. If we could take some of the hyped-up go-get­ters on The Appren­tice TV show and give them a month’s hard cod­ing, we’d all be in a bet­ter place.

Makers and hand shakers

If all the busi­ness world were soft­ware engi­neers, there would be no human resources func­tion. OK, that’s not true – the soft­ware team still needs pay­roll, ben­e­fits, hol­i­day allo­ca­tion and infor­ma­tion to guide its mem­bers to the office par­ty. But what the devel­op­er and IT oper­a­tions func­tion doesn’t typ­i­cal­ly need is incen­tivi­sa­tion. 

Tech­nol­o­gists don’t need to be incen­tivised because they start off with a hard-wired incen­tive to make, cre­ate and gen­er­al­ly be great. The rea­son The Big Bang The­o­ry’s Shel­don is super-con­fi­dent and amus­ing­ly smug is that he thinks he’s right and that he thinks his work is great. 

The agile busi­ness man­ag­er may have to take this les­son with a pinch of salt. A super-con­fi­dent approach often helps sales­peo­ple shine but too much of a good thing is, well, too much, isn’t it? The com­mer­cial les­son here comes down to why soft­ware engi­neers are hap­py: it’s because they are mak­ers who are busy mak­ing.

This ide­al has trans­lat­ed into mod­ern busi­ness man­age­ment already; the mak­er movement’s cul­ture that empha­sis­es learn­ing through doing is indus­try, prod­uct and ser­vice agnos­tic. 

To pro­mote this form of agili­ty, we can begin by just talk­ing to each oth­er. Remem­ber the stereo­types we start­ed with? In fact, effec­tive agile soft­ware engi­neer­ing is all about (now sani­tised) hand­shakes and inter­ac­tion, despite the image of the soli­tary geek who wants to sit alone at lunch. 

As the Agile Man­i­festo once again spec­i­fies, the most effi­cient and effec­tive method of con­vey­ing infor­ma­tion to and with­in a devel­op­ment team is by face-to-face con­ver­sa­tion. “Busi­ness peo­ple and devel­op­ers must work togeth­er dai­ly through­out the project.”

Open systems of meritocracy

Soft­ware engi­neers love work. They love what they do and they would prob­a­bly do it even if they didn’t need to work for a liv­ing. In fact, most devel­op­ers have gen­er­al­ly spent their spare time cod­ing as “hob­by­ists” long before they were gain­ful­ly employed in enter­prise envi­ron­ments. 

What this real­i­ty means is that soft­ware pro­fes­sion­als intrin­si­cal­ly recog­nise hard work. They under­stand the effort that goes into good work, they know what it means to the per­son who has car­ried out the tasks in hand and they know how oth­ers will feel about the prod­uct or ser­vice that a person’s work has result­ed in.

This is the men­tal con­struct around which much of open source is found­ed. The com­mu­ni­ty con­tri­bu­tion mod­el of soft­ware appli­ca­tion devel­op­ment cham­pi­oned inclu­siv­i­ty and belong­ing-focused team­work before it became a favourite of post-mil­len­ni­al man­age­ment con­sul­tants. 

Open source also strives to pro­mote sys­tems of mer­i­toc­ra­cy over any sys­tem of hier­ar­chy. Peo­ple, prod­ucts and soft­ware code should be brought to the top of the pile if they are good, not because they have good con­nec­tions, good par­ents or a good edu­ca­tion. It is what you do that mat­ters and that’s all that mat­ters.

The Agile Man­i­festo stip­u­lates that we should “build projects around moti­vat­ed indi­vid­u­als. Give them the envi­ron­ment and sup­port they need, and trust them to get the job done.” The straight­for­ward les­son for busi­ness is to recog­nise effort, poten­tial and dri­ve as well as inno­v­a­tive thought and action.

Addi­tion­al­ly, we should recog­nise good work in any form. Open source wants pro­gram­mers to sub­mit “code com­mits”, but it also wants non-tech­ni­cal sup­port for doc­u­men­ta­tion (and its inter­na­tion­al trans­la­tion) and com­mer­cial strat­e­gy – so, yes, busi­ness­peo­ple, that means you.

Easter-egg engineering

In what might be a les­son drawn from life, com­mer­cial busi­ness or per­haps show­busi­ness, agile soft­ware engi­neers love to show off their dex­ter­i­ty with unex­pect­ed extras. Some­times obscured from nor­mal view and some­times more obvi­ous, games devel­op­ers are noto­ri­ous for build­ing hid­den fea­tures, known as East­er eggs, into their soft­ware.

Microsoft engi­neers have incor­po­rat­ed a vari­ety of oth­er func­tions and mini-apps inside Win­dows over the years. Many users will know the famous­ly hid­den (although quite basic) flight sim­u­la­tor that used to reside behind the core user inter­face in the Excel spread­sheet. There are plen­ty of oth­er exam­ples, too, and the Cor­tana speech inter­face has car­ried this effort for­wards with a few super-smart sassy replies.

In terms of busi­ness agili­ty, there’s a clear mes­sage here and it comes down to com­pe­ten­cy. The devel­op­er is say­ing: “Not only was I able to build you a prod­uct with every­thing you want­ed, I was also able to use my engi­neer­ing prowess to cre­ate fea­tures that you may nev­er even find or use.” 

In busi­ness, we call that going the extra mile, being ser­vice-cen­tric or being cus­tomer focused. It’s right there in the Agile Man­i­festo’s core 12-prin­ci­ple mantra, if we look for it: “Con­tin­u­ous atten­tion to tech­ni­cal excel­lence and good design enhances agili­ty.”

Busi­ness agili­ty can stem from the same DNA. The “if a job’s worth doing” mantra has been around since bib­li­cal times for a rea­son. Organ­i­sa­tions that suc­cess­ful­ly instil this approach in their own oper­a­tions at a deeply gran­u­lar lev­el – as low-lev­el as soft­ware code – can build oper­a­tional agili­ty based upon a pre­cise knowl­edge of what resources and com­pe­ten­cies they run with on any giv­en day.

Inside the agile software scrum

Scrum is an agile project man­age­ment frame­work that helps teams work togeth­er, and is used fre­quent­ly in soft­ware engi­neer­ing. Sim­i­lar to the hud­dle of the same name, when a rug­by team plays on the field, the scrum method­ol­o­gy encour­ages teams to self-organ­ise while try­ing to solve a prob­lem, to learn through expe­ri­ence and to keep improv­ing by reflect­ing on their wins and loss­es.

Agile tech­nol­o­gy engi­neer­ing and the adop­tion of the “scrum” approach to build­ing soft­ware through “sprints” –  short time peri­ods when a team works togeth­er to com­plete a spe­cif­ic task – is root­ed in self-organ­i­sa­tion and adapt­abil­i­ty. This cen­tral truth means that cod­ing tasks could be shared between indi­vid­u­als where cross-func­tion­al com­pe­ten­cies exist. 

Once again, this state­ment is made in the con­text of soft­ware appli­ca­tion devel­op­ment but it could be com­plete­ly applied to busi­ness if we remove one word: cod­ing. Now that it’s trés chic to be geek and we live in an age where soft­ware runs the world, per­haps it’s time for our agile IT engi­neers to clean off their rug­by boots and get the key to the cor­po­rate wash­room.

Roles within an agile development team

Many of the roles with­in a typ­i­cal soft­ware engi­neer­ing team will have a broad-brush des­ig­na­tion used for recruit­ment process­es, com­pa­ny pro­mo­tion and cus­tomer-fac­ing inter­ac­tions. Soft­ware engi­neers are often known as just that; soft­ware engi­neers. But look­ing in more spe­cif­ic terms at inter­nal par­lance and team lin­go, these engi­neers typ­i­cal­ly take on some of the fol­low­ing roles with­in the soft­ware umbrel­la, as fol­lows: 

Soft­ware engi­neer: a pro­gram­mer of almost any descrip­tion.

Scrum mas­ter: respon­si­ble for man­ag­ing team mem­bers and the com­mu­ni­ca­tion chan­nels between them.

QA leader: a spe­cial­ist in qual­i­ty assur­ance with a good knowl­edge of reg­u­la­to­ry com­pli­ance and leg­is­la­tion. 

Project man­ag­er: a mem­ber of the scrum team who works at man­age­ment inter­face lev­el with more expo­sure to users and the busi­ness func­tion.

Sys­tems archi­tect: a spe­cial­ist in sys­tems inte­gra­tion and net­work struc­ture, often tasked with gath­er­ing (and man­ag­ing) user require­ments.

Con­fig­u­ra­tion man­age­ment spe­cial­ist: a holis­tic thinker, the con­fig man­ag­er is respon­si­ble for the code repos­i­to­ry inside of which the soft­ware team’s prod­uct ver­sions reside.

Test engi­neer: an engi­neer who looks after unit test­ing (pieces of code that have yet to be inte­grat­ed into the total sys­tem), inte­gra­tion test­ing (test­ing the process of inte­grat­ing code), devel­op­ment test­ing (test­ing inte­grat­ed code to ensure it works) and wider user accep­tance test­ing, to deter­mine whether peo­ple can actu­al­ly work with the soft­ware that has been cre­at­ed.

---