It’s not my fault – Agile made me do it!

I argued in a previous blog that the first of the twelve “Principles behind the Agile Manifesto” misses the mark in naming the highest priority of Agile practitioners. In truth, it doesn’t just miss the mark, it misses the target. As a refresher, the principle reads:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

I contended that the principle expresses a false absolute. More importantly, I believe it advances a false allegiance. I don’t believe “satisfying the customer” should be the highest priority of people using Agile frameworks at all. Customer satisfaction certainly matters and it’s not unfair to say it’s a key business priority for any organization. But to call it a singularly transcendent one that surpasses every other goes too far. Whether Agile standards of care are used in the process is inconsequential in making that determination. There are far more important priorities development teams should recognize.

The first and second Theses of the Denver Method, which I introduced in that blog, offer just two examples of valid business objectives organizations might consider to be equally important to satisfying customers. But far more critical are the ethical and moral values a development team must be duty-bound to uphold. These ideals should soar far above any potential business goal or profit motive when a development team is forced to weigh its loyalties.

Imagine, for example, a situation where a team is asked to build an application that clearly doesn’t fit that team’s area of expertise or skillset. Should its top priority be attempting to ‘satisfy the customer through early and continuous delivery’ of a software solution when the developers know very little about that particular area and probably can’t build the app without major flaws? Or should the team lead just be honest and let the customer know the application requested is outside the team’s sandbox, perhaps suggesting another development group more qualified for the task?

As a more prescient example, consider the case of the infamous software-based Volkswagen “defeat device” which, between 2008 and 2015, illegally altered VW diesel engines to keep nitrogen oxide emissions within U.S. EPA limits whenever the software detected vehicles were being tested for emissions, but allowed the same vehicles to emit up to 40 times that limit under normal driving conditions. Ignoring, for now, the question of whether the developers who wrote and implemented the code were ordered to do so, they clearly created this ‘valuable software’ to ‘satisfy the customer.’ So, if the team members used ‘early and continuous delivery’ to create it, can we assume they should be allowed to plead “The First Principle of Agile” in their defense?

Yes, there was a touch of sarcasm there, I’ll admit. But the point remains a valid one. To say, “It’s not my fault – Agile made me do it!” would be a preposterous rebuttal for criminal behavior, and Agile certainly encourages no such dereliction. Yet, as we enter an age where software drives cars, controls weapon systems, monitors health conditions, powers devices that have the potential ability to spy on us in our homes, and even guides life-and-death surgeries; development teams have an ever-greater duty to exercise a standard of care that exceeds every business priority. What concerns me isn’t that Agile encourages unethical or negligent development practices – it doesn’t. What concerns me is that nothing in Agile’s values or principles actively tries to prevent them. Instead, it calls on Agile practitioners to “satisfy the customer” as the practitioner’s “highest priority.” Therein lies the false allegiance.

Let’s look at the VW case again, supposing this time that executives did indeed order the software engineers to create the defeat device, then threw those developers under the bus when the deceit was uncovered. From the facts that have come to light so far, this appears to be what happened – at least superficially. Even if the software engineers only followed their bosses’ orders, they broke both legal and moral codes of behavior by not refusing to comply with those orders. One might say in such a circumstance the executives were the real “criminal masterminds,” but the developers still chose to be their ignominious “minions,” however coerced that choice seemed to them at the time.

In April of 2017, James Liang became the first VW engineer to go to jail for his role in the emissions scandal after a U.S. judge sentenced him to 40 months in prison and a fine of $200,000 for conspiring to defraud the U.S., committing wire fraud, and violating the Clean Air Act. Speaking on Liang’s behalf, his lawyer said, “We’re not saying he didn’t commit a crime, but he’s a good and decent person. He blindly executed a crime because of a misguided loyalty to his employer.” If that is indeed how Mr. Liang saw his actions, his “loyalty” was “blind” indeed: Blind to the jeopardy it placed on his own career, life and family; blind to the livelihoods of hundreds of VW employees who were unaware of the deceit but lost their jobs because of it; and blind to the good faith it destroyed for millions of VW customers around the world. He clearly didn’t see where his real loyalties belonged.

As software becomes an integral part of nearly every aspect of human life; and as that software becomes incomprehensibly complex; we find ourselves racing toward a crisis of loyalty, responsibility and integrity unlike anything the software development industry has ever faced. Imagine, for instance, what happens when an executive insists that a team cut costs “or else.” Now suppose that the developers, already stripped to the bone, determine the only place left to cut is testing. Next, picture what happens when those cuts cause the team to miss a bug in their autonomous driving application, and that bug costs human lives before it is caught and fixed. Finally, consider the developers’ plight when executives, trying to deflect personal blame, accuse the team of criminal negligence for irresponsibly cutting corners.

We must begin thinking about conundrums like these. They are coming. Soon.

I don’t pretend to think I can prevent every crisis of conscience with a few words posted on a blog page. But I do think there are ways to help the development team understand its real priorities and make its decisions a little less arduous or complicated. The secret lies in understanding exactly where a team’s loyalties are. In the Denver Method, this is one of the Aegis’ most important duties.

Each Thesis is written to specifically address the Aegis. I have two reasons for this: (1) Because I first began writing the Theses as a guide for training new Aegises, and (2), because that role personifies the very heart of the Denver Method’s essence. The competence and dedication the Aegis displays in fulfilling that role and manifesting the Theses determines the caliber and integrity of his or her team. This is especially true of the third and fourth Theses, as they embody the ethos and marrow of the Denver Method itself.

THESIS THREE: In all things and above all things, the Aegis must do what is right. An Aegis must resolutely understand where his or her loyalties lie and use them to guide difficult decisions. Preeminent among those loyalties rests doing right for the team: The Aegis is its champion, tasked with the well-being and livelihood of its members. In addition, the Aegis must be loyal without fail to his or her higher being, to the highest service of customers, to the good reputation of the business, to its financial success, and to the law.

My developers and Aegises like to call Thesis Three the “Aegis’ Professional Code of Conduct.” Its substance, however, applies to anyone in a leadership position. Developers and other employees in an organization should find beneficial guidance in Thesis Three as well.

To further define and clarify the Thesis, I’ve written some Corollaries. The first relates to understanding the deeper meaning of the first sentence. Knowing precisely what is right can sometimes be tricky, but Rotary’s well-known “Four Way Test” offers an unlimited free supply of “virtual litmus paper.” Herbert J. Taylor wrote these four simple questions when he worked at Club Aluminum Products in the 1930’s, at a time when the company faced looming bankruptcy. Taylor posted the maxim for other employees to see, hoping to change the company’s ethical climate and thus its fortune. Years later, Taylor became an international director of Rotary and offered the organization his Four Way Test, which it readily adopted. Today, Rotary continues to promote the axiom as the standard by which all behavior should be measured.

THESIS THREE, Corollary 1: It is sometimes difficult to know with conviction what path is the right one, but if it can’t pass Rotary’s time-honored standard of behavior keep looking, because you haven’t found it yet.

“The Four Way Test”

Is it the truth?
Is it fair to all concerned?
Will it build goodwill and better friendships?
Will it be beneficial to all concerned?

NOTE: Okay… I need to admit I’m not being truly honest here; at least syntactically. My exhortation to “keep looking” is meant to ensure the Aegis goes outside the box as far as possible before settling for a lesser path; because any course of action that can’t pass every stipulation of the Four Way Test remains, at the end of the day, a lesser path. Thus, when an Aegis has explored every imaginable alternative with the test in mind and fearlessly resolves that no path is better, then I will trust he or she has found the best solution there is.

I firmly believe that meeting the first two challenges is never impossible; therefore, any course followed must, at the very least, be the truth and fair to all concerned. On rare occasions, however, no practical solution exists that benefits everyone or builds “goodwill and better friendships.” While win/win answers should always be the goal, sometimes the only viable choice – even though it’s as fair as humanly possible – leaves someone feeling they’ve lost. When that happens, the Aegis must look to the Thesis’ hierarchy of loyalties to know whose interests he or she must try to protect.

Notice that the Aegis’ boss, per se, is not one of those interests. This is deliberate. Nothing in the Thesis addresses the organization’s hierarchy of command, because if leadership in general (and the Aegis’ superiors specifically) always uphold genuine loyalty to the company, the community, the customer, and the law – and always have the Aegis’ back regarding the welfare of the team – there will never be a conflict between them. If a leader or group of leaders’ loyalties diverge from the Code of Conduct, however, the Aegis must stand by the Code. There is a Corollary for that, too.

THESIS THREE, Corollary 2: While an Aegis should always be a good corporate citizen and respect his or her leadership, it remains a critical part of the Aegis’ duty to his or her team and to the reputation of the company to know when the instructions of a superior must be resisted in a fair and honorable way. When a directive or policy will result in loss of well-being or livelihood to those the Aegis serves as guardian to, or when it is illegal or immoral, the Aegis has a duty to speak up and take necessary steps to prevent its implementation.

The next Corollary my Aegises and developers jokingly call “The Aegis’ Conduct of Code.” It points out that, as part of honoring the priorities in Thesis Three, an Aegis should realize the software his or her team creates can affect the lives and welfare of countless others.

THESIS THREE, Corollary 3: It is the Aegis’ apodictic responsibility to ensure that every line of code published by the team serves the higher good of the customer, the user, and the community. The Aegis’ vigilance in this duty reflects on the team, the company and everything the Aegis stands for.

In the next blog, I will introduce Thesis Four, which is existentially linked with Thesis Three, defining the way in which the Denver Method creates a thriving culture of genuine engagement; one that is palpable, exciting, and magnetizing for highly creative people.

[Cross-post from the Denver Method Blog]

The Aegis as Shield

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, because 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, and satisfying the customer is affirmatively one of them. But there are others that matter – a lot. And to me, 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:

THESIS 1: The primary business goal of software development is to have the best software developers possible develop the most competitive software possible in the shortest possible time, ideally at the most reasonable cost.

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:

THESIS 2: The primary goal of management in a software development enterprise is to arrange the most ideal conditions possible for software developers to spend every available minute at the single task of creating excellent code, without any interruptions that would interfere with that task.

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 mostly 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, sales people 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 estimating to be done by the Aegis, not the developers. If a sales person or executive needs a quick impromptu report extracted from data in tables owned by the team, the sales person 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.

Elon Musk recently 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.

[Cross-post from the Denver Method Blog]

Apodictic Responsibility for Software Team Leaders

Responsibility

In The Mythical Man-Month: Essays on Software Engineering, published in 1975, Frederick P. Brooks, Jr. shared lessons he learned from the massive project he led to build the OS/360 operating system for IBM’s System/360 mainframe computers. IBM bet its future on the System/360 in the early 1960’s, and the bet eventually paid off as a major success. But it wasn’t perfect in its execution; the project ran woefully late and cost several times its estimate. The book deconstructs what Brooks felt went right – and what went wrong – and tackled popular myths concerning management and manpower issues in large, complex software projects along the way.

Brooks also offered some ideas, long before Scrum, Kanban or XP were ever dreamed of, on how to improve large projects and give them more agility and efficiency. One of these was “The Surgical Team,” an idea Brooks adapted from a colleague of his at IBM, Dr. Harlan Mills, who imagined it as a means of eliminating mediocre software code. Mills proposed dispensing with large teams of conventional developers and replacing them with specialized resource teams dedicated to assisting exceptionally skilled software engineers, allowing these mavens to write and implement code unencumbered by distractions or tedium. Each team would have one such programming genius as its team lead in a role Mills likened to the chief surgeon in a medical team.

Although Mills’ approach was very different from mine, I could clearly see that we shared a similar doctrine concerning software management: If you want great code and you want it quickly, find the best people you can afford, give them everything they need, and eliminate all the time-wasting tasks you can. Then, get out of their way and let them code.

The analogy of a “chief surgeon” as a software team lead intrigued me. Not for the reasons Brooks and Mills had in mind, though, but for something else. When I pictured a chief surgeon, I thought of the tremendous responsibility a chief surgeon has, and I pictured a software team lead having that same kind of awesome burden. A question formed in my mind: What if every person on a software team “owned” the code it creates, but only one person was ultimately responsible for that software?

You see, I’m not a big fan of the concept of “team ownership” commonly found in Agile environments. One issue most Agile methodologies fail to address adequately is software quality, and I think the idea of shared ownership tends to be part of the problem rather than a solution. In almost every company I’ve worked at, I’ve observed some developers for whom ownership doesn’t mean “We own this together;” it means “The team owns this, not me. So I’m not personally responsible for doing anything except my part. Sometimes, giving everyone on a team shared ownership of a software product unintentionally backfires, leaving no one with a duty-bound obligation to ensure the entire team creates quality software it can be truly proud of. Team ownership is not a quality control process or a standard of care; it is simply an ideal – a chain-like bond between team members that is only as strong as its weakest link.

In contrast, few activities in human experience hold greater demand for painstaking quality control than the practice of surgery. The risks of not getting a procedure exactly right can include anything from failure to improve the patient’s condition, to infection or other complications, to the loss of a limb, organ or body function, to – in the worst cases – death. Dosages, tolerances, and vital signs must be monitored constantly and carefully. No procedural step can be missed or done in the wrong order, no incision can be too deep, and no tool or sponge can be left behind in the patient’s body for fear of life threatening complications.

The medical field has a time-honored method for insuring every surgery is performed as perfectly as possible. In every surgical team, a head surgeon bears total responsibility for the procedure and makes all the decisions: What will be done, when, and how. Comprehensive support comes from a skilled team including other surgeons, anesthetists, nurses, and nurse practitioners. These teammates may do any number of things, including, in some cases, surgical procedures. However, everything they do is under the direction of the chief surgeon, and he or she remains totally accountable for the outcome of the operation on every level and in every way.

In logic, when a proposition is so incontrovertible that it is beyond dispute, it is said to be apodictic. This word aptly describes the head surgeon’s accountability in the operating room; it is absolute, automatic and certain. Although every participant has a job to do and responsibility for doing it well, the chief surgeon has ultimate accountability for everything. If anyone makes a mistake that harms a patient, the chief surgeon will be held liable.

Before I go on, allow me to digress very briefly. There’s a rather long story I’ll tell another time about this, but in 2014 my firm needed to build a large software application for a new contract we had won. With our own developers swamped, and being leery of outside contractors after a bad experience, they wanted to know if I was interested in building a new team. I responded with a proposal for a rather unorthodox team I would set up and manage, using some ideas I had been thinking about for a while. As part of the proposal, I set some conditions that would allow me to have complete authority over how the team would run, operating within the company but much like an outside contractor in terms of hiring, policies, and practices.

At first, only a couple of my ideas didn’t adhere to accepted Agile norms; the rest was very typical Scrum and XP stuff with a Kanban board for pull-based workflows. But once our ideas began to show impressive results, we decided to allow ourselves the freedom to think completely outside the box of typical Agile insights and explore new ideas. The outcome was a whole new toolset of processes, methods and basic tenets which we gave names to for working purposes. In early 2017, I started my own company and began building more teams using this toolset. Eventually, we decided on a name for the whole toolbox – the Denver Method. The ideas shared in this blog come from that toolbox, in the hope that they may benefit other development teams the way they have benefited us. I will use the names we came up with to distinguish Denver Method tools and ideas from popular Agile methodologies.

When the surgeon idea I’m discussing in this article came to me, I had been dealing with frustrations I wanted to get away from for at least the remainder of my natural life, if not longer. I didn’t want any more “coaches” who were really project managers, nor “servant leaders” who were really whip lashers.  I had already formed the image of a new kind of “servant leader” who truly belongs to the development team and doesn’t tell the developers they need to “increase their velocity” (Scrum jargon for “work faster or put in more unpaid overtime”). No, this person, whom I decided to call an Aegis, would work side-by-side with them as part of the solution, not the problem. He or she would keep away the distractions that prevent developers from focusing on writing code, mentor them continuously, write code if necessary, protect the autonomy of the developers, and help make the software created by the team the very best it can possibly be.

Fred Brooks’ book made me realize one more duty the Aegis should have: Apodictic responsibility for all software developed by his or her team – the same kind a chief surgeon has.

In the Denver Method, the Aegis is apodictically accountable for every line of code delivered by the team. This is for the same basic reason as the chief surgeon’s accountability: To ensure the best possible service to the customer. While the Aegis trusts his or her developers to design and create software with great care and quality, he or she is the one person the customer or the organization will ultimately look to if there is a problem. This means the Aegis must read and approve every line of code before it is released to production, without exception. If the Aegis believes the code could be problematic, represents a design that might be burdensome to maintain, or simply falls beneath the developers’ normal standard of design and quality, the Aegis returns the software to the developer for rework or has the developer work in concert with another team member to improve the code.

In my experience, apodictic responsibility on the part of an Aegis produces better software than simple peer review. Since the Aegis becomes familiar with every block of code in the repository, he or she has a concise picture of how new code will work within the overall application or module. Also, developers know their work will be reviewed not just for functionality, but for efficiency, simplicity, flexibility and other aspects of quality software design. They quickly learn what the Aegis expects and they deliver it as a matter of habit.

Very few safeguards exist against mediocre peer review. I’m not saying lapses in review standards happen regularly, or even often, but developers might sometimes allow other team members a “pass” on less than stellar code to avoid conflict or extra work for themselves. I’ve seen teams where anti-patterns that don’t seriously affect functionality, such as long methods or duplicate code, will prompt nothing more than a note to the developer recommending optimization or refactoring whenever the developer “has the time” – a day that will likely never come. The Aegis’ apodictic responsibility makes such anti-patterns rare.

In Scrum, the Scrum Master makes sure each iteration is properly sized and completed. Meanwhile, the Property Owner ensures that the software focuses on customer-driven features and priorities. But in my experience, these roles usually only resolve quality issues from a functional or UX perspective. There isn’t one lone individual, experienced in software development, who reads every line of code and won’t release code unless it’s flawless… someone tasked with the responsibility of guaranteeing the product delivered to the customer is the very best the team can produce.

In more traditional organizations, managers and project managers have substantial (but not apodictic) accountability for the product delivered. However, those project managers are too busy counting hours, manipulating Gantt charts, frantically trying to find ways to fit another new feature request from customers into the schedule, or trying to make sure that a roll-out date doesn’t get missed. They rarely look at the actual code being created – they don’t have the time (and frequently don’t have the knowledge). Meanwhile, managers are too busy trying to make sure budgets are met, attending meetings, hiring new people and dealing with HR issues. They never get more than a bird’s eye view of the thousands of lines of code written by their teams.

There is a danger in these situations. If a Scrum Master, project manager, or department manager becomes overly concerned with meeting a target delivery date, pressure may be applied to developers. Under duress, a team may take “shortcuts” that increase technical debt or create buggy code just to get software delivered faster. In the short run this may speed up delivery, but it creates technical debt that demands greater and greater rework later, slowing down development in the long term. High technical debt is already one of the more recognized problems with Agile, and “pressure cooker” negligence may add to rework created by other debt-creating techniques. To use the words of Alistair Cockburn, “If there is anything that’s inefficient and hard to defend in Agile, it’s the amount of rework we do.”

Without ultimate responsibility for code quality and without reading code before it is deployed, these managers and team leaders not only don’t know if the code is up to the standards expected by the enterprise or the customer, they may encourage poor quality unintentionally (or even not so unintentionally) by emphasizing speed. And since they don’t have direct responsibility, they could potentially even blame developers when a serious problem occurs for which someone must be held accountable. Assigning apodictic responsibility for code quality to one person who reads every line of code makes this scenario virtually impossible.

From my experience after using it for several years now, and for all the reasons I’ve listed above, I resolutely believe in giving total responsibility for all code development in a team to one person. Like the team in a surgery room, there are many team players who work together and bring about a successful challenge – and every team member’s role is just as important as anyone else’s – but in the end all accountability comes back to one person. In the Denver Method, that is the Aegis.

[Cross-post from the Denver Method Blog]

Greasemonkey Script to Prevent Smartsheet Emails From Scrolling Off the Screen

On March 23, 2017, Smartsheet deployed a software update that made its alert emails very difficult to use in Gmail. They added blank space to the updated table rows that pushes content far off the right side of the screen. The image below shows the difference. The email on top is what alert emails previously looked like in Gmail; the email on the bottom is how they appear now.

I asked Smartsheet to fix this problem on April 11th. They assure me that the development team knows about the problem but they can’t provide a timeline of when it will be fixed.

Until then, I’ve created a Greasemonkey script that makes the alert emails usable again. Greasemonkey is a browser add-on that lets you run scripts to modify a web page once it is downloaded to your browser. Install Greasemonkey for Firefox here or Tampermonkey for Chrome here. Then click the following link:

Install Userscript to Resize Smartsheet in Gmail

Reload your Gmail tab and the script should be active. This script works by checking that the text “support@smartsheet.com” appears on the page and then removes the width attribute from all “td” elements (table cells) and changes the min-width property to zero.

If you have an improvement to the script, please let me know. If the link above doesn’t work, here is the full script:

// ==UserScript==
// @name        Resize Smartsheet in Gmail
// @author      John Steele, Auxiliary Teams Inc.
// @namespace   https://www.auxteams.com/
// @description Resizes Smartsheet email content to fit inside Gmail.
// @version     2017-07-02
// @include     /^https?://mail\.google\.com//
// @match       https://mail.google.com/*
// @match       http://mail.google.com/*
// @grant       none
// @require     http://ajax.googleapis.com/ajax/libs/jquery/3.2.1/jquery.min.js
// ==/UserScript==

/* 

    LICENSE
    
    Copyright (C) 2017 John Steele and Auxiliary Teams Inc. All Rights Reserved. 
    This work is distributed under the W3C(R) Software License [1] in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
    [1] http://www.w3.org/Consortium/Legal/copyright-software
    
*/

$(document).ready(function(){
  $(document).shrinksmartsheetgmail();
});

$(document).click(function(){
  $(document).shrinksmartsheetgmail();
});

$.fn.shrinksmartsheetgmail = function(){
  $(document).ready(function(){
    if ($('div:contains("support@smartsheet.com")').length > 0) {
      $("td").each(function(){
        $(this).siblings().css("min-width","0px")
        $(this).siblings().removeAttr("width")
      });
    }
  });  
};

568 Days Uptime, 200ms Global Response Time, and How We Do It

Uptime Image

Enterprise RADIUS, or ERAD, is Eleven’s secure 802.1x Wi-Fi authentication system that is used by leading hotel brands. I had the honor of building this system in 2015 and we continue to improve and maintain it. As of today, it has achieved continuous uptime of 568 days; no downtime for scheduled maintenance and no unexpected outages. This system also achieves worldwide response times of under 200 milliseconds.

Now, I don’t want to mislead you. These statistics are for the user interface component of ERAD. Most web technologies also have a backend component. In ERAD’s case, the API backend has achieved uptime of “only” 252 days.

How did we achieve these results? There are 3 keys to our success with the frontend component of ERAD:

  1. The frontend consists entirely of static files.
  2. The static files are hosted on AWS S3.
  3. The files are globally distributed using AWS CloudFront.

First, and in my opinion most important, is that the user interface is purely static. There is no server side processing — no dynamic logic. The files hosted on the server are sent as-is to the user’s browser. By doing this, we are able to host the files on Amazon’s S3 service, which has excellent up-time statistics.

Using purely static files does introduce some difficulties but these are good difficulties to have. It forces a separation of concerns, requiring application logic to be contained in the API and not the UI. For example, there is nowhere in the UI that a connection to the database can be made because doing so would mean embedding the database credentials in the source code that is sent to the user’s browser. Instead, the UI must interact with the database through the API, as would be expected when following best practices.

This configuration is highly stable and results in long uptime statistics because it is able to use mature services such as S3 and because it enforces best practices, which help improve stability. And because these files are hosted on S3, they can be globally distributed via AWS CloudFront, which is how we achieve 200ms response times

Why Agile?

I have had the benefit of seeing the Agile development philosophy from both the developer’s and the manager’s perspectives. From my experience, it seems that developers whole-hardheartedly embrace Agile while managers often seem to do so begrudgingly. This article is for managers and explains the primary benefit managers receive and should embrace from an Agile philosophy.

Agile Avoids Waste, Reduces Risk, and Responds to the Market

A primary premise of Agile is to deliver early and often. Delivering early means getting features in front of users, even before they are complete and polished, so that users can give feedback. This feedback is critical to assuring that features aren’t being developed that will either be unused or unusable.

Extensive, multi-year studies by companies like Microsoft, Netflix, and Quicken Loans show that two-thirds of software features fail to provide the benefit they intended to provide. The vast majority of software written simply doesn’t provide value to users. Companies throw billions of dollars at the problem of figuring out what users want and get it wrong over and over again.

The answer to this problem is delivering early and often. By getting features in front of users as quickly as possible, users can give feedback about whether the feature is valuable. That feedback can be used to iterate: decide to continue on course, change course, or scrap the feature and spend development resources where they will provide higher value.

Ready to put Agile to work for your organization? Get started with Auxiliary Teams today.

What is Managed Software Development?

Let’s face it. Managing developers is like herding cats and you have more valuable ways to spend your time. Hiring developers from Auxiliary Teams isn’t hiring contractors that you still have to manage and supervise. You get a team leader who is your organization’s single point of contact. This team leader is the technical architect who designs a cohesive system and ensures all code merged into the production repository adheres to that vision. With managed software development, you manage the ideas, we manage the development.

Managed Software Development

We follow a surgical team model, as described in the Denver Method. The model is that a single individual, a highly talented and experienced developer, is the head of the team and responsible for every line of code put into the project. That individual is surrounded by a team of great developers who also write production-ready code but all of that code is presented to the team leader for acceptance. On a surgical team, the head surgeon is responsible for every incision. One primary reason for this is to make sure the action takes place in light of all other information. The other team members might not perceive the full situation or might not be experienced enough to recognize the interaction between two different and seemingly unrelated activities. The head surgeon has the experience to assimilate all of the information together into a cohesive picture and the ability to visualize hidden pitfalls before they occur. We believe following this model in software development also reaps similar benefits resulting in greatly increased code quality.

When hiring a typical software contractor, the managing company has to closely supervise the individual. Contractors are usually hired only into an existing software development infrastructure. On the other hand, managed software development can fit into an existing infrastructure, with much lower supervision requirements, and can also fit into a company that has no infrastructure for software development and can provide immediate benefit without significant ramp-up time.

Ready to try managed software development from Auxiliary Teams? Get started today.