I didn’t set out to break the rules; at least not all of them. I just found certain popular Agile practices seemed to limit performance or reduce flexibility, so I wanted to try something different. When the team discovered significant improvement resulted from the first few changes, we decided to make all the rules optional. And we began taking a closer look at the original Agile values and principles themselves.
We agreed at a visceral level with the most basic concepts of Agile: Openness to change, incremental development with frequent feedback loops, collaboration with customers and other stakeholders, and putting people above processes or tools. But we began asking ourselves if we agreed with every principle as the founders of Agile wrote them. Beyond that, we questioned how various modern Agile practices implement those principles – did processes get in the way of ideas? A quest began; a mission to learn by taking Agile apart and inspecting its pieces, and by breaking it to see what happened.
For my part, this introspection led to a journey of discovery and insight. Beginning with the four values of the Agile Manifesto, then moving on to the ‘Twelve Principles Behind the Manifesto’, I found I agreed strongly with some things but not with others. Reflecting on and rethinking these principles changed the way I – and everyone on my team – interact and develop software.
During this quest, I discovered some of the values and principles I agree most strongly with don’t seem to have the emphasis they deserve when I look at software development today. I discerned that others needed a bit of tweaking to make them say what I thought they needed to since their wording seemed unclear or didn’t make a strong enough point. But it also seemed to me that a few critical elements of being effective at software development – and of my own Weltanschauung (my ‘world view’) – weren’t there.
As I experimented, I came up with some tenets of my own, which I decided to call Theses. My Theses don’t attempt to replace the Agile Manifesto values or principles behind it. Rather, I see them as augmenting, clarifying or furthering the Agile canons (except, of course, where they don’t; but we’ll get to that later). This blog is about these Theses and the things I and my teams have learned by employing them. We’ve gained tremendous benefit from these inspirations, and I hope by sharing them others may benefit, too.
My first Thesis came as a counterpoint to the first principle listed in the ‘Principles behind the Agile Manifesto’ listed on the agilemanifesto.org webpage. The original principle states:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
This statement isn’t wrong, as far as it goes. However, I think a number of goals compete for a software team’s highest priority. While satisfying the customer is affirmatively one of them, there are others that matter – and in my mind some that matter more. This is particularly true since it seems to me that satisfying the customer “through early and continuous delivery of valuable software” seems to focus on process, not principle.
I’m a capitalist (among other things), and software development is a business. So, another perfectly valid perspective in establishing priorities for a software development team should be the primary business objective. I think any businessperson would instantly agree that, from that viewpoint, the following statement fairly articulates the number one business priority of our industry:
That business priority translates to certain obligations for a manager. A manager’s job is, in part, to implement the business objectives of the company. Another duty is to make sure the human resources he or she is responsible for are utilized as effectively as possible. It has always been a key part of the Weltanschauung I mentioned earlier – the axioms and paradigms I live by – that the best way to manage teams is to find the best people one can, give them everything they need to do what they do, and eliminate every time-wasting task possible. Then, get out of their way and let them code.
With that thought in mind, I believe the highest business priority of software development management looks like this:
Although I try to word my Theses as precisely as I can, it isn’t always easy to do so and stay succinct. If taken very literally, I think the meaning should be rather self-evident, but I can’t afford the slightest equivocality in this instance. So, let me provide some examples to ensure my intent is abundantly clear:
- I don’t believe software developers should be estimating software, individually or in groups.
- I don’t believe they should attend group meetings to update managers on their work. That includes daily standups.
- And I don’t believe they should be taking direction from any member of the company who is not their immediate supervisor. More specifically, they should never be asked to work on “pet side projects” for executives, managers, or salespeople. These activities distract from the goals of the team as a unit.
Oh! And there it is… do you hear it? A cacophony of objections! Executives, project managers and even a few managers (but few, if any, developers) protesting my words and questioning my heritage. “What? Wait! That’s impossible! We need to know when we can deliver the finished product! We need to know how a project is doing! What about emergencies that come up? How will we get them handled if we can’t talk to the developers? We can’t possibly do that! No software enterprise could function that way!”
I respectfully disagree. Over the past few years, my teams and I have developed an approach to enterprise software development that does exactly what the second Thesis says. And it has worked far better than we ever anticipated. At the company where we first began using this approach, my five-person team produced high-quality software at three times the throughput of the company’s main 20-person “Agile” development team. And we did so with fewer errors. But just as importantly – or perhaps more importantly – this approach resulted in a level of job satisfaction for my developers (and for me) that is almost unheard of in the software world today.
The key to this approach was the invention of a new and unique multi-faceted role that replaces a slurry of typical roles in traditional Agile models. I call this role the Aegis. The Aegis can be thought of as something of a ‘Jack-of-all-Trades’ who performs as, among other things, the technical architect for the team, its “junior project manager” (or even project manager in smaller organizations), its task scheduler, the immediate owner of all software created within the team, and the person responsible for reviewing all software before delivery and deployment. But all these functions (and more) are done as part of the Aegis’ one primary function, which, according to the intention of Thesis Two, is to protect the developers in his or her team from anything which keeps them from spending every working hour creating awesome software.
In Greek mythology, the aegis was the shield of Zeus. In modern English, ‘aegis’ means ‘protection’ or ‘backing,’ e.g.: “We are allowed to practice free speech under the aegis of the Constitution.” Accordingly, in the Denver Method the Aegis operates like a firewall, providing protection to his or her team so the developers can work in what they call their ‘coding Utopia’.
In a previous post, I discussed the Aegis’ apodictic responsibility for the quality and performance of a team’s software, and in a future post I will explain how the Aegis holds the same degree of responsibility for the delivery schedule. These duties represent two ways in which the Aegis protects developers. By accepting accountability for delivery dates and monitoring code as it posts to the trunk, the Aegis disencumbers developers from the albatross of worrying about schedules or making sure others maintain quality standards.
The Aegis also protects the team by serving as a liaison between the team’s developers and anyone outside the team, including product managers, project managers, salespeople, and executives. If a product manager needs to have estimates of when various tasks will be completed, it is up to the Aegis to provide them and for that estimation to be done by the Aegis, not the developers. If a salesperson or executive needs a quick impromptu report extracted from data in tables owned by the team, the salesperson needs to speak with the Aegis. The Aegis’ goal in these situations is to keep developers from being distracted from the work they are focused on.
When it does become critically necessary to interrupt developers, no one should question that the Aegis should be the one making that decision. Since the Aegis has apodictic responsibility for the software and the schedule, if any developers get pulled away from their primary work to solve an issue, it will be up to the Aegis to manage whatever adjustments must be made in resources, time or scope. If executives, project managers and other stakeholders respect this responsibility, they’ll willingly route their requests through Aegises.
Another way the Aegis protects the team is by keeping developers out of unnecessary meetings. I include in this category any meeting that doesn’t assist with designing, writing, testing or delivering software. Alistair Cockburn often complains of the “hour-long 10-minute standup” as a problem in Agile environments. I think the easiest way to fix that problem is not to have them. Standups, unless focused on design or testing problems, mostly serve to inform management of project progress and developers’ daily goals for project work. If project managers or leadership really need to know these things (and I submit they don’t; I see such detail as unnecessary micromanagement), they can be obtained through brief emails, quick phone calls or other methods that might take about the same amount of time for the requestor, but only a minute or two for developers responding individually.
In 2018, Elon Musk received accolades from the media for a memorandum he wrote to staff at Tesla, recommending, among other things, that employees improve productivity by avoiding or even walking out of meetings that are overly long, excessively frequent or not of value to all participants. I agree, but an even better piece of advice would be to never have such meetings in the first place, and I see standups as matching all three conditions Musk identified.
There are other ways the Aegis runs interference for developers. For example, if a critical failure occurs in another team’s system, but the developers in the Aegis’ team need that system to do their own work, it’s up to the Aegis to find a quick resolution by working with the other team’s Aegis. When developers need equipment, servers or other resources, the Aegis does the legwork. In short, for every situation that arises which could hamper the performance of developers, the Aegis makes it his or her job to handle it with as little interruption as possible to the developers.
It is the Aegis’ job to shield developers from distractions. Many times that job is accomplished by holding that shield up like an umbrella to provide shade and shelter so that developers can do what they do best; write great code.