Decentralised Software Development and the Many Methods of Agile
Lean, Kanban, Feature-Driven Development, Crystal, Pack, Scrum: can you guess which isn’t a software-development process?
Agile processes have multiplied with the rise of software as a service. Software used to be a top-down affair governed by the dreaded waterfall method of rigid requirements etched in stone for a product released many months into the future. These days, your company could have already pivoted between stand-up meetings.
Agile is the brave new-ish world many developers find themselves in. Developers are no longer the coding automatons implementing requirements from layers of management on high. Instead, management caters to the developers and self-organisation is the buzzword for managing fluid requirements, timelines and goals as code gets continually deployed for immediate impact.
Why Agile Coaches Can Feel So Strange
You know how all those external Agile coaches seem a little peculiar? There’s an important reason for that.
Self-organisation and external Agile coaches are in contradiction. Self-organisation isn’t happening if someone from outside the team gets contracted to organise you. Wherever possible, processes should adapt to the self-organising team rather than the team adapting to the organising process.
As such, there is no one perfect Agile methodology that will fit your self-organising team. Existing conditions matter. Individual team members matter. How the business operates as a whole matters. That’s why there’s so many different and imperfect Agile variations: each one is trying to fit the workings of different organisations.
How Adnuntius Does Agile
I work for a company called Adnuntius. We’re going pretty damn well. We don’t specifically follow any Scrum or Kanban or whatever else Agile methodology you can think of.
Despite our doing well, no other company should exactly follow our process. We’ve developed a process over time that works for us as an organisation and probably won’t work for yours. Nevertheless, there might be a thing or two about what we do that could be of interest to how you run your organisation.
Adnuntius: An Outline
Software development is directed out of Melbourne, Australia. I’m one of five senior software engineers in Melbourne who develop our products and who largely handle how we and everyone else across the organisation gets development done.
We have another three developers in Northern Europe, plus a team of five people in Sri Lanka who act as our support staff, script writers and testers.
The business is based out of Oslo, Norway. We have salespeople and account managers all around the world, but the majority of our customers are in Europe.
Adnuntius: How We Develop Software
We do a lot of the technical stuff you come to expect from a SaaS-based development team: distributed version control; continuous integration; oodles of automated unit, integration and system tests; code reviews; frequent deployments. None of us like or do pair programming nor strict test-driven development, but that hardly seems revolutionary anymore.
The most interesting thing about our development process is everything that isn’t technical. We have no business analysts or development managers. Rather, every developer at Adnuntius is a mature head that is charged to look after their own stuff in a decentralised manner organised around responding to customer requests, understanding business goals that feed into a loose roadmap and continual improvements to technical processes.
We organise around Slack, Trello and Wikis. Once upon a time we used Jira, but the business and we developers found it a chore to use. Getting bogged down into how long individual tasks would take, what is considered “done” and how many bugs were squashed had no benefit. As such, there are no iterations, no burn-down charts, no story points, no retros.
Instead, the onus is on continual feedback with a heavy emphasis on shipping things as early as possible to test out what’s produced with real customers. Stand-up meetings and loose organising happen in and around Slack. Requirements are continuously refined over time and we have some important customers with whom we have a tight relationship based around a history of trust and close connection. It also helps that our customers like our jokes!
At any given time, a new feature might be developed out of the blue. Last week, I implemented a great customer idea to do with our advertising layouts, rolled it out and let the customer know directly. No one but me, my code reviewer and the customer were directly involved in conceiving of the feature and having it deployed. That’s the fluidity we work with and the kind of distributed decision making that is a hallmark of how we do things.
Our decentralised processes are only possible thanks to the trust in our decision making that the business has. The business has its ear to the ground, setting out what opportunities are available and pushing more short-term priorities as needs arise. We have a direct line to our business-oriented Norwegian CEO, who does an excellent job of using and understanding our software, and we developers are intimately involved in deciding what gets done and how the business goals are shaped.
Two examples of how the development team drastically shaped the business goals of the company come from two brand new products. Adnuntius Data was the brainchild of our Swedish developer and I conceived of Adnuntius Native, a spin-off of our core product, Adnuntius Advertising. Both relatively new offerings are getting plenty of traction around the market, opening us up to a broader range of customers.
Despite being very Agile, our current set-up fits into no existing Agile methodology. We’ve evolved organically, drawing on the strengths of the team we have, our relationships and the needs of the company.
It’s unlikely how we work will work for your organisation. It’s also unlikely how we work will continue to work for us in the future. Times change, people change, and our processes will need to adapt to match. For now, though, we’re on a winner with the current revision of our Adnuntius Agile method.
And if you’re wondering, there’s no Agile method called Pack — at least not at the time of writing…
