Software developers used to get a raw deal. Consigned to a life working in some windowless basement office location, their predilection for low-grade pizza and excessive consumption of Coke or Pepsi helped to craft a stereotype that endured for many years.
But now it’s chic to be geek. Elevated through star hacker roles in Hollywood movies and championed in various TV comedy series, the coder community has gained a new level of respect. An asteroid is about to hit Earth and the planet’s laser beam defences have been compromised by non-state actors sharing contaminated applications across the dark web, you say? No problem, call the software engineering team’s super-hack SWAT squad. Only coders can save us now.
If we could take some of the hyped-up go-getters on The Apprentice TV show and give them a month’s hard coding, we’d all be in a better place
But software professionals aren’t just for asteroid attacks or Christmas. They play a special role in translating business logic into the “requirements” phase that precedes application development. They know how to create secure apps that work as intended and can change when needed.
Nobody needs to be told that the world had to reinvent many of its operational systems, supply-chain integration points and end-user interfaces throughout the Covid-19 contagion. But, equally, few will perhaps realise how exacting and essentially agile the architectural systems engineering was that went on beneath the surface.
Going forwards, then, what major lessons can an organisation’s business function “suits” learn from developers when it comes to working in an agile way?
Programming perfectionists
Software engineers are perfectionists, which is a good thing. It’s a good thing when it comes to the security of the banking app on the smartphone in your pocket and it’s a good thing when it comes to keeping the apps that run the national grid operational.
OK, the national grid doesn’t run on an app, it runs on a comprehensive tier of management software that features heavily custom-built optimisation and specific controls for its use case. That’s not the point. The point is that it works. Software developers call non-functional software code brittle or flaky, both of which are quite emotive terms for something so essentially virtual and digital.
Because they work with algorithmic logic in a mathematically defined world, software professionals see a comparatively chiaroscuro view of the world. Something is either correct or it isn’t.
While this black-and-white approach won’t necessarily work for care workers, teachers or undertakers, the lesson for businesspeople is still there. Look for the negatives, audit for inefficiencies, discover statistical outliers, find the superfluous white noise clogging up human workflow systems and address it.
We can apply an additional business-centric layer of empathy and understanding here (please don’t fire everybody working at less than 101% capacity tomorrow) and take this mindset forward.
Technologists wouldn’t leave a book unfinished and often don’t leave their keyboards until the sun comes up, if a job isn’t complete. Yes, businesspeople do that, too, but they’re often looking for ways “around” a problem; software engineers are looking for ways to “solve” a problem.
When an organisation starts to dovetail this approach across its business function and its technology function, then it arguably becomes the most agile version of itself that it can possibly be.
Developers accept the inevitability of chaos
Picture our software developer hunched over their keyboard. Some of that stereotype is still there, with the unkempt hair, heavy metal band T-shirt and an insistence on wearing shorts in winter. But look closer for a moment. There’s an almost hangdog look about the expression on our coder’s face – and that look means something.
The agile engineer’s air of slightly benign resignation is because of users. The developer needs them because somebody has to use the software at the end of the day. But essentially, as always, the user will either ask for unreasonable application functionality changes or break the existing software system by attempting to do the wrong thing with it.
The software team accepts the inevitable chaos that users and, indeed, the development team itself will create on a daily basis. This is the epitome of agile software methodology, ie, the constant of change. As the Agile Manifesto states: “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”
If we had built our international business systems with just one percentage point more of this ethos in mind, we might have been able to activate change more rapidly throughout recent times of disruption.
The developer knows that however perfect their software product is on the day it hits “live production” status, once users get involved, things will happen. For them, it’s like taking a Labrador puppy to a children’s birthday party; it might start out looking clean and tidy, but it’s bound to come back covered in cake and ice cream.
Understanding the inevitable chaos that exists in the real world is an important business lesson but too many businesspeople can only see the win-win. If we could take some of the hyped-up go-getters on The Apprentice TV show and give them a month’s hard coding, we’d all be in a better place.
Makers and hand shakers
If all the business world were software engineers, there would be no human resources function. OK, that’s not true – the software team still needs payroll, benefits, holiday allocation and information to guide its members to the office party. But what the developer and IT operations function doesn’t typically need is incentivisation.
Technologists don’t need to be incentivised because they start off with a hard-wired incentive to make, create and generally be great. The reason The Big Bang Theory’s Sheldon is super-confident and amusingly smug is that he thinks he’s right and that he thinks his work is great.
The agile business manager may have to take this lesson with a pinch of salt. A super-confident approach often helps salespeople shine but too much of a good thing is, well, too much, isn’t it? The commercial lesson here comes down to why software engineers are happy: it’s because they are makers who are busy making.
This ideal has translated into modern business management already; the maker movement’s culture that emphasises learning through doing is industry, product and service agnostic.
To promote this form of agility, we can begin by just talking to each other. Remember the stereotypes we started with? In fact, effective agile software engineering is all about (now sanitised) handshakes and interaction, despite the image of the solitary geek who wants to sit alone at lunch.
As the Agile Manifesto once again specifies, the most efficient and effective method of conveying information to and within a development team is by face-to-face conversation. “Business people and developers must work together daily throughout the project.”
Open systems of meritocracy
Software engineers love work. They love what they do and they would probably do it even if they didn’t need to work for a living. In fact, most developers have generally spent their spare time coding as “hobbyists” long before they were gainfully employed in enterprise environments.
What this reality means is that software professionals intrinsically recognise hard work. They understand the effort that goes into good work, they know what it means to the person who has carried out the tasks in hand and they know how others will feel about the product or service that a person’s work has resulted in.
This is the mental construct around which much of open source is founded. The community contribution model of software application development championed inclusivity and belonging-focused teamwork before it became a favourite of post-millennial management consultants.
Open source also strives to promote systems of meritocracy over any system of hierarchy. People, products and software code should be brought to the top of the pile if they are good, not because they have good connections, good parents or a good education. It is what you do that matters and that’s all that matters.
The Agile Manifesto stipulates that we should “build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” The straightforward lesson for business is to recognise effort, potential and drive as well as innovative thought and action.
Additionally, we should recognise good work in any form. Open source wants programmers to submit “code commits”, but it also wants non-technical support for documentation (and its international translation) and commercial strategy – so, yes, businesspeople, that means you.
Easter-egg engineering
In what might be a lesson drawn from life, commercial business or perhaps showbusiness, agile software engineers love to show off their dexterity with unexpected extras. Sometimes obscured from normal view and sometimes more obvious, games developers are notorious for building hidden features, known as Easter eggs, into their software.
Microsoft engineers have incorporated a variety of other functions and mini-apps inside Windows over the years. Many users will know the famously hidden (although quite basic) flight simulator that used to reside behind the core user interface in the Excel spreadsheet. There are plenty of other examples, too, and the Cortana speech interface has carried this effort forwards with a few super-smart sassy replies.
In terms of business agility, there’s a clear message here and it comes down to competency. The developer is saying: “Not only was I able to build you a product with everything you wanted, I was also able to use my engineering prowess to create features that you may never even find or use.”
In business, we call that going the extra mile, being service-centric or being customer focused. It’s right there in the Agile Manifesto’s core 12-principle mantra, if we look for it: “Continuous attention to technical excellence and good design enhances agility.”
Business agility can stem from the same DNA. The “if a job’s worth doing” mantra has been around since biblical times for a reason. Organisations that successfully instil this approach in their own operations at a deeply granular level – as low-level as software code – can build operational agility based upon a precise knowledge of what resources and competencies they run with on any given day.
Inside the agile software scrum
Scrum is an agile project management framework that helps teams work together, and is used frequently in software engineering. Similar to the huddle of the same name, when a rugby team plays on the field, the scrum methodology encourages teams to self-organise while trying to solve a problem, to learn through experience and to keep improving by reflecting on their wins and losses.
Agile technology engineering and the adoption of the “scrum” approach to building software through “sprints” – short time periods when a team works together to complete a specific task – is rooted in self-organisation and adaptability. This central truth means that coding tasks could be shared between individuals where cross-functional competencies exist.
Once again, this statement is made in the context of software application development but it could be completely applied to business if we remove one word: coding. Now that it’s trés chic to be geek and we live in an age where software runs the world, perhaps it’s time for our agile IT engineers to clean off their rugby boots and get the key to the corporate washroom.
Roles within an agile development team
Many of the roles within a typical software engineering team will have a broad-brush designation used for recruitment processes, company promotion and customer-facing interactions. Software engineers are often known as just that; software engineers. But looking in more specific terms at internal parlance and team lingo, these engineers typically take on some of the following roles within the software umbrella, as follows:
Software engineer: a programmer of almost any description.
Scrum master: responsible for managing team members and the communication channels between them.
QA leader: a specialist in quality assurance with a good knowledge of regulatory compliance and legislation.
Project manager: a member of the scrum team who works at management interface level with more exposure to users and the business function.
Systems architect: a specialist in systems integration and network structure, often tasked with gathering (and managing) user requirements.
Configuration management specialist: a holistic thinker, the config manager is responsible for the code repository inside of which the software team’s product versions reside.
Test engineer: an engineer who looks after unit testing (pieces of code that have yet to be integrated into the total system), integration testing (testing the process of integrating code), development testing (testing integrated code to ensure it works) and wider user acceptance testing, to determine whether people can actually work with the software that has been created.
