Free AI web copilot to create summaries, insights and extended knowledge, download it at here

Abstract

command and control the resources available to the project. We advocate for resources to be pulled on demand and moved between projects day-to-day. Each resource will file manually daily timesheets in excel stating what they do on hourly basis. That’s how we control and bill projects. Resources aren’t entitled to any other form of support than being given minimum hardware tools that they should maintain, carry, and secure at their expenses. People shouldn’t be motivated even contractually with bonuses, holidays, salary increases. Any performance review should highlight mistakes, defects, faults, issues in order to block any possible aspiration to request better working conditions (e.g. salary increase, career progressions…). As far as we can prove to clients the maximum utilisation of our resources we can keep billing for our projects and make revenues. That’s how it is and how it will be without any change.</p><h2 id="96ec">6. The most efficient and effective method of overloading the development team with information, without communicating with them, is via text or recorded message passed from many intermediaries.</h2><p id="6afa">We shot messengers. Especially face to face messengers. Communication needs to be poor, bureaucratic, over complicated, full of noise and empty words. If we pay someone to produce documentation this needs to be reproduced and duplicated in various formats such as excel, power point, email. We believe in printing everything, especially outdated or useless data. We also value whenever a little bit of information can pass from multiple intermediaries either to add noise or to become more confusing. Whenever useful information needs to be issued we will have attached so much noise and nonsense that will become just a rumour. With the advancement of new technologies we advocate for compulsory camera-on and video registration of all meetings so that even those who are absent can re-watch meeting icebreakers. Regarding meetings we promote FOMO (fear of missing out), compulsory attendance of as many participants as possible, meetings without agenda scheduled outside of working hours.</p><h2 id="71d9">7. Working software is irrelevant; obsolete documentation and made up reports are the primary measure of progress.</h2><p id="fb69">We advocate for weekly business reviews and project status updates. We want to see RAG (red, amber, green) icons next to every single micromanaged and irrelevant activity. We want long presentations filled with drama and no actionable items. The only exception is the action to ask the team to work faster. To get busy faster and for longer. No need for demoes of working software. No need for deliverable product increment. No need for product quality metrics and quality assurance. Working software is irrelevant when compared to project documentation which needs to have the priority on any other activity. Reporting is functional to billing which is functional to revenue and stakeholder ultimate satisfaction. If the client is paying with public money we will produce even more unnecessary and complex documentation doubling the number of meetings, printed pages, and made up reports.</p><h2 id="2ba6">8. Anti-agile processes promote unsustainable development. The sponsors, developers, and workers should be exhausted by constant pressure and overtime.</h2><p id="f4f3">We need to reiterate that simply demotivating people isn’t enough. We need to keep everyone busy and stressed at unsustainable levels. People who cannot cope with such pressure should leave the company. People who are not committed to giving free extra hours and all their energies do not deserve the job. People at risk of burn-out will be made redundant. The one who will be successfully resilient enough to remain will win and receive new tasks previously assigned to failing resources. We do not care about respect, focus, openness, courage… as those are scrum and agile values and we are anti-agile. Unsustainable development takes many forms: accumulating bugs, legacy code or libraries, over-production of waste, old ways of working, overtime, harassment, false promises, excuses, toxicity. We want to use people as much as we can, until they will crack under unsustainable pressure. We encourage managers to test in all tedious and painful ways the breaking point of our resources.</p><h2 id="2b70">9. Ignore technical excellence and good design; they are obstacles to incoordination.</h2><p id="9bab">Chaotic drama, spite and petty arguments are crucial for command and control politics. We do not care about coordination, team work, agility, and respect. We always encourage employees to take the old way of doing something. We have no money to waste on innovation, continuous learning, self-growth or improvement. Technical excellence is overrated and clients would not even notice it. Whatever our ignorant top managers will request will become our design principles. We will elevate our old habits to a standard and whenever we can, we will impose to partners, clients, providers our “standard” way of doing business. We will encourage mediocre people to stay in the company. Tenure is the highest level of success. One more year in the company is a pric

Options

eless badge to celebrate in the company chat with a virtual icon showing virtually popping champagne. We want employees’ brains, knowledge, and technical skills to decay slowly so that our employees will not have enough confidence, inspiration, energy, willingness or even hope to find a better job. In the rare case that someone not so lazy would get a better proposal from one of our competitors, we encourage managers to make a counter offer: propose to the disloyal employee to work more hours! Don’t ask how the competitors are doing better thanks to innovation and technical excellence. Let them spend the money and then copy their ideas.</p><figure id="1e98"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*s0zsd6UzY32q1xFoyr7AKw.jpeg"><figcaption></figcaption></figure><h2 id="f8b7">10. Complexity–the art of maximizing the amount of useless effort–is essential.</h2><p id="f879">We can’t reiterate enough that keeping people busy, at the maximum of their capacity, is the business core principle of any anti-agile organisation. Resources need to be busy in as many projects as possible, making a lot of effort. No matter how useless the result is. The more complex the better. Simple things are visible, transparent, and inspectable. Unnecessary complexity it is essential to mask billing hours and activities. We believe projects can be extended but at the same time new projects can be added to dying projects in order to prolong the agony of a business relationship. We do not accept errors, mistakes, liabilities, but if obliged we can offer a new project as compensation for any dispute. As far as the new project will sound and appear more complex than the previous.</p><h2 id="8c73">11. The best architectures, requirements, and decisions are enforced hierarchically top-down by non-experts.</h2><p id="8719">There are no better SMEs (Subject Matter Expert) than the owners and managers who ran the business so far. They can make technical decisions on behalf of qualified professionals who are paid mainly 1) to increase margins on project bills 2) because the law or contract require so. Only as a gesture of good will the shareholders or executives will allow qualified professionals to speak, provide views, suggest design, propose actions. Decisions, architecture and quality standards will be enforced from the top in spite of the expertise, skills, qualities and capabilities of the team. We believe the best businesses have been run by people without a degree, without qualifications, without even respective international or local laws. Gut feelings and bribery together with a solid command and control are enough to run a business. Especially if homeostasis, scapegoating and secrecy covers for failures due to ignorance and arrogance. True innovators make their own rules and they can even bend rules of nature described by physics and mathematics.</p><h2 id="4ae4">12. At irregular intervals, workgroups blame each other, talk on each other’s back, overreact, argue on how to become effective, then ignore and repeat their behaviour accordingly.</h2><p id="9205">We truly believe that in order to demotivate people, add meetings to project hours, destroy self-esteem we need to provide employees with unrequested and manipulative feedback. We will not do this at regular intervals but rather whenever there is a gap in people’s schedule. We will also use these feedback sessions to block any career improvement or aspirational hope. We will use feedback to make people feel unsafe, insecure, guilty. We will not offer any support. We encourage managers to call for all hands and town hall to disclose someone’s fault. We encourage everyone to make a big deal out of it. We believe that sticks and carrots are powerful learning tools. We will discourage the employee from taking any initiative or action that could lead to an improvement. We will encourage drama and back-talking. We will tolerate mocking, disrespectful pranking, and harassment. We will not change any behaviour and keep playing the same old blaming reefs. As long as the resources get busier and busier, that’s ok.</p><p id="ee73">I write about organizational patterns, transformational leadership, healthy businesses, high-performing teams, future of workplace, culture, mindset, biases and more. My focus is in leading, training, and coaching teams and organizations in improving their agile adoption. Articles are the result of my ideas, studies, reading, research, courses, and learning. The postings on this site and any social profile are my own and do not represent or relate to the postings, strategies, opinions, events, situations of any current or former employer.</p><p id="4743">This article may have been published for the first time on <a href="https://www.danieledavi.com/">danieledavi.com</a> by the author Daniele Davi’. © Daniele Davi’, 2020–2023. No part of this article or the materials available through this website may be copied, photocopied, reproduced, translated, distributed, transmitted, displayed, published, broadcast or reduced to any electronic medium, human or machine-readable form, in whole or in part, without prior written consent of the author, Daniele Davi’.</p></article></body>

Manifesto for Anti-Agile Software Development — explaining the principles

In my previous articles I presented the Manifesto for Anti-Agile Software development (values) and principles. I then expanded on the meaning of the anti-values (here) and in this article I am going to elaborate more about the meaning and impact of each of the 12 principles.

1. Our highest priority is to satisfy ourselves through late and sporadic delivery of mediocre software.

We do not advocate for continuous delivery of software. We have no time or capacity. Our clients would either not be able to sustain the rhythm of frequent updates or would demand a peace we can’t offer. Why bother asking, contracting or collaborating on this? We just don’t. We make clear this is what we do. If they like it as is, their clients pay for it. Leave or take is what satisfies us. Our shareholders aren’t interested in getting continuous feedback from users and clients because product improvements aren’t free. Our top managers are focused on pleasing their superiors. If our executives need to compromise the software quality to satisfy internal stakeholders they should do so.

2. Reject changing requirements, yet be late in development. Anti-agile processes resist change until it becomes urgent, for our own convenience.

Company owners have the right to demand changes at any time. Sometimes the need to change may arise from external factors: changes in law, technology, library, security, discovery of threats or vulnerabilities or data breaches, opportunities, client requests, articles, scientific progresses… it doesn’t matter. The middle management will make sure to create frustration, confusion, unnecessary stress and pressure so that the team will hate any possible change and take the longest, most complex and painful route in order to resist the change.

3. Deliver buggy software rarely, from a couple of quarters to a couple of years, with a preference to the longer timescale.

The first principle demands us to deliver mediocre software and to do so via sporadic big-bang, massive, waterfallish untested releases. With this principle we want to clarify that sporadic means no more than two releases per year. It is understood that whilst waterfall SDLC entails one or more phases for testing, we do not recognise its value and we will not waste money on testing or debugging activities. We will release software rarely, with delays on the agreed timelines and rest assured it will be buggy!

4. Business people and developers must work separately throughout the project.

We believe that being in the same office or even open space doesn’t mean working together! Project and people managers will hold the right to make demands and requests to teams and workgroups. Top managers have the right to: check on progress constantly; breath on the neck of workers; monitor workers (including using cameras, emails, chats, logs…); sending confusing messages; adding competing priorities; schedule hundreds of unnecessary and mandatory meetings; disrupt team activities; distract team focus; pressurise people; add unnecessary stress and drama at each request; consider any “no”, “maybe”, “let me think about it” or any other form of rejection as outrageous and unacceptable behaviour. We believe in micro-managing, “yes-sir” people-pleasing, segregation and separation of roles based on hierarchical levels. We value scapegoating as a reaction to failures. We discourage bridging and shared responsibilities.

5. Conduct projects using demotivated human resources. Give them the minimum resources and support they need, and micromanage them to keep them busy.

We believe in keeping our (human) resources busy with projects. Projects are the core of our activities. We do not believe in designing or building products. We certainly do not believe in doing so through the participation of motivated people. We select self-motivating people so that we do not have to waste money on motivating and engaging initiatives. We do not need learning and development initiatives. We believe projects can be stretched in time and renewed even if people are not inspired to learn more or improve. Micromanaging is key to command and control the resources available to the project. We advocate for resources to be pulled on demand and moved between projects day-to-day. Each resource will file manually daily timesheets in excel stating what they do on hourly basis. That’s how we control and bill projects. Resources aren’t entitled to any other form of support than being given minimum hardware tools that they should maintain, carry, and secure at their expenses. People shouldn’t be motivated even contractually with bonuses, holidays, salary increases. Any performance review should highlight mistakes, defects, faults, issues in order to block any possible aspiration to request better working conditions (e.g. salary increase, career progressions…). As far as we can prove to clients the maximum utilisation of our resources we can keep billing for our projects and make revenues. That’s how it is and how it will be without any change.

6. The most efficient and effective method of overloading the development team with information, without communicating with them, is via text or recorded message passed from many intermediaries.

We shot messengers. Especially face to face messengers. Communication needs to be poor, bureaucratic, over complicated, full of noise and empty words. If we pay someone to produce documentation this needs to be reproduced and duplicated in various formats such as excel, power point, email. We believe in printing everything, especially outdated or useless data. We also value whenever a little bit of information can pass from multiple intermediaries either to add noise or to become more confusing. Whenever useful information needs to be issued we will have attached so much noise and nonsense that will become just a rumour. With the advancement of new technologies we advocate for compulsory camera-on and video registration of all meetings so that even those who are absent can re-watch meeting icebreakers. Regarding meetings we promote FOMO (fear of missing out), compulsory attendance of as many participants as possible, meetings without agenda scheduled outside of working hours.

7. Working software is irrelevant; obsolete documentation and made up reports are the primary measure of progress.

We advocate for weekly business reviews and project status updates. We want to see RAG (red, amber, green) icons next to every single micromanaged and irrelevant activity. We want long presentations filled with drama and no actionable items. The only exception is the action to ask the team to work faster. To get busy faster and for longer. No need for demoes of working software. No need for deliverable product increment. No need for product quality metrics and quality assurance. Working software is irrelevant when compared to project documentation which needs to have the priority on any other activity. Reporting is functional to billing which is functional to revenue and stakeholder ultimate satisfaction. If the client is paying with public money we will produce even more unnecessary and complex documentation doubling the number of meetings, printed pages, and made up reports.

8. Anti-agile processes promote unsustainable development. The sponsors, developers, and workers should be exhausted by constant pressure and overtime.

We need to reiterate that simply demotivating people isn’t enough. We need to keep everyone busy and stressed at unsustainable levels. People who cannot cope with such pressure should leave the company. People who are not committed to giving free extra hours and all their energies do not deserve the job. People at risk of burn-out will be made redundant. The one who will be successfully resilient enough to remain will win and receive new tasks previously assigned to failing resources. We do not care about respect, focus, openness, courage… as those are scrum and agile values and we are anti-agile. Unsustainable development takes many forms: accumulating bugs, legacy code or libraries, over-production of waste, old ways of working, overtime, harassment, false promises, excuses, toxicity. We want to use people as much as we can, until they will crack under unsustainable pressure. We encourage managers to test in all tedious and painful ways the breaking point of our resources.

9. Ignore technical excellence and good design; they are obstacles to incoordination.

Chaotic drama, spite and petty arguments are crucial for command and control politics. We do not care about coordination, team work, agility, and respect. We always encourage employees to take the old way of doing something. We have no money to waste on innovation, continuous learning, self-growth or improvement. Technical excellence is overrated and clients would not even notice it. Whatever our ignorant top managers will request will become our design principles. We will elevate our old habits to a standard and whenever we can, we will impose to partners, clients, providers our “standard” way of doing business. We will encourage mediocre people to stay in the company. Tenure is the highest level of success. One more year in the company is a priceless badge to celebrate in the company chat with a virtual icon showing virtually popping champagne. We want employees’ brains, knowledge, and technical skills to decay slowly so that our employees will not have enough confidence, inspiration, energy, willingness or even hope to find a better job. In the rare case that someone not so lazy would get a better proposal from one of our competitors, we encourage managers to make a counter offer: propose to the disloyal employee to work more hours! Don’t ask how the competitors are doing better thanks to innovation and technical excellence. Let them spend the money and then copy their ideas.

10. Complexity–the art of maximizing the amount of useless effort–is essential.

We can’t reiterate enough that keeping people busy, at the maximum of their capacity, is the business core principle of any anti-agile organisation. Resources need to be busy in as many projects as possible, making a lot of effort. No matter how useless the result is. The more complex the better. Simple things are visible, transparent, and inspectable. Unnecessary complexity it is essential to mask billing hours and activities. We believe projects can be extended but at the same time new projects can be added to dying projects in order to prolong the agony of a business relationship. We do not accept errors, mistakes, liabilities, but if obliged we can offer a new project as compensation for any dispute. As far as the new project will sound and appear more complex than the previous.

11. The best architectures, requirements, and decisions are enforced hierarchically top-down by non-experts.

There are no better SMEs (Subject Matter Expert) than the owners and managers who ran the business so far. They can make technical decisions on behalf of qualified professionals who are paid mainly 1) to increase margins on project bills 2) because the law or contract require so. Only as a gesture of good will the shareholders or executives will allow qualified professionals to speak, provide views, suggest design, propose actions. Decisions, architecture and quality standards will be enforced from the top in spite of the expertise, skills, qualities and capabilities of the team. We believe the best businesses have been run by people without a degree, without qualifications, without even respective international or local laws. Gut feelings and bribery together with a solid command and control are enough to run a business. Especially if homeostasis, scapegoating and secrecy covers for failures due to ignorance and arrogance. True innovators make their own rules and they can even bend rules of nature described by physics and mathematics.

12. At irregular intervals, workgroups blame each other, talk on each other’s back, overreact, argue on how to become effective, then ignore and repeat their behaviour accordingly.

We truly believe that in order to demotivate people, add meetings to project hours, destroy self-esteem we need to provide employees with unrequested and manipulative feedback. We will not do this at regular intervals but rather whenever there is a gap in people’s schedule. We will also use these feedback sessions to block any career improvement or aspirational hope. We will use feedback to make people feel unsafe, insecure, guilty. We will not offer any support. We encourage managers to call for all hands and town hall to disclose someone’s fault. We encourage everyone to make a big deal out of it. We believe that sticks and carrots are powerful learning tools. We will discourage the employee from taking any initiative or action that could lead to an improvement. We will encourage drama and back-talking. We will tolerate mocking, disrespectful pranking, and harassment. We will not change any behaviour and keep playing the same old blaming reefs. As long as the resources get busier and busier, that’s ok.

I write about organizational patterns, transformational leadership, healthy businesses, high-performing teams, future of workplace, culture, mindset, biases and more. My focus is in leading, training, and coaching teams and organizations in improving their agile adoption. Articles are the result of my ideas, studies, reading, research, courses, and learning. The postings on this site and any social profile are my own and do not represent or relate to the postings, strategies, opinions, events, situations of any current or former employer.

This article may have been published for the first time on danieledavi.com by the author Daniele Davi’. © Daniele Davi’, 2020–2023. No part of this article or the materials available through this website may be copied, photocopied, reproduced, translated, distributed, transmitted, displayed, published, broadcast or reduced to any electronic medium, human or machine-readable form, in whole or in part, without prior written consent of the author, Daniele Davi’.