CUTTER BUSINESS TECHNOLOGY JOURNAL  VOL. 34, NO. 2
  

It’s been 20 years since the Agile Manifesto was created and published. I remember the excitement and the feeling that all known methodologies at the time (except XP) had suddenly become obsolete.

Agile won global acceptance and became the de facto standard for software projects. It then spread across organizations, influencing other departments, digital­ization initiatives, and projects. As a result of its enormous popularity growth, we now have Agile project management, Agile processes, Agile enterprises, Agile marketing, Agile … everything.

Let’s stop for a moment and reflect on the relevance of the original Agile ideas and methodologies.

In the context of what has happened during the digitalization of all aspects of our businesses and private lives, 20 years is the length of an era. We lived in a very different world in 2001, with only a fraction of businesses online. The majority of people were not using digital tools for work or in their private lives.

Agile was promised as a cure for all the problems inherent in previous methodologies, completely changing every assumption about how people should work with each other.

Twenty years later, there’s substantial criticism about the relevance of so-called Agile methodologies — specifically, how much they’ve become disconnected from the business reality of enterprises and the Agile spirit itself.

Before we go further, it’s important to remember that many of Agile’s practices and base assumptions were and are unrealistic, and some have become obsolete in our present digital world. Indeed, “Doing Agile wrong” has been a popular mantra for the last 10-15 years.

Nevertheless, it’s high time we moved past that and verified Agile’s real relevance. This is the inevitable cycle of progress: we’re in need of a major step forward into a new era of ever-more-digital businesses and lives.

Agile Problems and Solutions

We need new solutions — software developers would call it a major refactoring. It’s likely you will recognize many of these suggestions as changes you’ve already made to address the flaws of the original Agile method­ologies. For those who have just become Agile believers, this may come as more of a surprise. Let’s go through the most common problems with Agile versus reality and discuss possible solutions.

Manifesto as the Source of the Problems

Many practitioners, myself included, believe the Agile Manifesto was too ambiguous, too generic, and too disconnected from the realities of modern enterprises and even human nature. It was so open to misinterpretation that the true spirit of Agile was lost in a set of ceremonies, processes, and procedures within a family of Agile-derived methodologies.

So do we need a new manifesto? Sure, they’re being created, but the truth is we must all find our own way, and it’s usually not necessary to call it a manifesto.

You are free to borrow from multiple sources, old and new, to adopt something fresh, something that will work for you. Actually, new Agile (or Agile replace­ment) is more about personalization than using generic manifestos and playbooks.

Sticking to a single manifesto wasn’t a very agile thing to do in the first place. It tended to become an object of a blind cult with fanatics unable to listen to any feedback, instead blaming the organization when it didn’t work in its pure, fundamentalistic form.

The reality is more complicated, and one-size-fits-all solutions quickly fail.

It’s a 1940s (but never wrong) idea of a constant improvement loop based on results and practical experiences. The current Agile (1.0) seemed to forget about the need to improve itself, especially in Scrum and related methodologies with their artificial ceremonies and false assumptions about people and organizations.

Financial Incompatibility

Let’s talk about money and cost first, as these things are not addressed by Agile at all. Agile methodologies did not survive contact with CFOs and the economy in general. Money is not iterative in its nature, nor are budgets, and there’s a striking imbalance between financial aspects, reporting, and Agile principles. As a result, Agile projects nowadays are often waterfall projects disguised in Agile clothing.

This is too often a combination of flaws from both approaches: waterfall’s hope of not being wrong (i.e., fixed scope, fixed date, fixed feature set) with tons of Agile ceremonies on top of it (i.e., to appear Agile, not to miss out on Agile).

One of the solutions that works is to let go of some of the false impressions of control. Letting go is hard at first, but you’ll get more business value with less frustration in the end.

It might be best to create yearly budgets for constant digital product developments without a fixed scope. Avoid infamous big-bang releases and adopt contin­uous features delivery, technology improvements, and delivery models (e.g., continuous improvement, continuous delivery).

This is all to enable real progress without guessing what will happen half a year later. No one knows what will happen next, and it’s better to stop lying to ourselves and embrace the dynamics of the organization and business context.

Product Owner Case

One of the key flaws of Scrum (for many, it is almost synonymous with Agile) is the definition of the role of the product owner, which in reality is hard to find. In essence, we look for someone, a single physical person, who knows all the business goals, processes, and technologies and has the authority to make final decisions on the spot.

Requirements and their prioritization have been a challenge throughout every project, so here is a “brilliant” solution — simply appoint one single per­son … a magician of sorts … an exclusive business knowledge holder … a technology-savvy genius … who is also equipped with decision-making power.

That would be great and has even happened from time to time, especially in smaller startups. But more often, that role was played by someone with a blurry product vision and not enough power to make clear decisions fast. It was the team that was defining and delivering new features with near-silent acceptance from a product owner present in name only. Everything depended on a single superhero who was too often a utopian idea, especially in large, multidisciplinary projects.

The realistic solution is to involve as many people as possible in ideation and the creative process and not to assume things like “developers cannot deliver great functional ideas” or “developers lack imagination or creativity.” Anyone who can and is willing to con­tri­bute to the product design should not be afraid to participate.

A collaborative spirit should also be applied to decision making about features and priorities. 

Communication

Agile emphasized direct verbal communication, creating another set of problems. A verbal format is not optimal for team members who want time to analyze the question, research different options, and prepare for a discussion. Often, it’s better to write up/draw up something ahead of time and give people a chance to analyze it, or even sleep on it.

Additionally, verbal communication is not effective and motivating for shy people or introverts, characteristics of many IT professionals. Conversations are often dominated by extroverted personalities rather than those with excellent ideas that add value.

Eventually, this turned into meetings for everything, along with calls, teleconferences, and gatherings to address items that could have been achieved by a simple message on Slack/Teams or a shared document with a request for comments. This obsession with meetings is a main reason for diminished productivity, reduced attention spans, and increased anxiety.

Another common misconception (not related to the manifesto but often attributed to Agile adoption) is waiting until the next meeting to discuss important communication activities or make decisions. In the modern era, it’s better to embrace a continuous time spectrum. When something is important and needed, it should be done without waiting for a ceremonial gathering the next morning. That applies not only to sharing information, but also key project decisions.

In this new era, what is going to work is the combina­tion of tools that take into account human nature and new technologies while being open to remote work. Let people do their jobs. Synchronizations are needed, but they also are distractions; focus is what we really need to move projects forward.

Architecture and Product Design

Architecture is a key success factor for software projects. It was, unfortunately, deliberately omitted in the Agile Manifesto. It’s time to bring the good practices back. Evolutionary architectures and composable architectures are better responses than avoiding architecture design completely and hoping things will somehow happen.

Data Aspect

Data has become the fuel of modern enterprises, and vast amounts of data growing exponentially require new approaches and tools. Machine learning is fed with data, and real-time analytics is a standard now, not in the future. Data is a missing part in the original manifesto that must be addressed in all data-driven organizations.

Velocity vs. Business Value

Pretending there’s progress because every two weeks (default Scrum sprint length) something visibly changes is another problem that can lead to perfectly (or imper­fectly) executing the wrong idea. Burning money is irreversible, and the encouragement to iterate is often misunderstood and brings with it a lack of focus on the goals.

There will always be another sprint, so let’s move it to the next one. There’s also: “Let’s overestimate the sprint items to make sure the managers won’t accuse us of not delivering the expected results on time.” This attitude is safe for developers but extremely counterproductive.

The business value, meaning the assessment of what really was achieved, is much harder to evaluate than points in the Agile productivity measurement tool. It becomes more rewarding for developers to pick simple tasks and become velocity leaders.

This has to stop immediately, as we cannot lie to ourselves by confusing velocity with productivity or business value. Yes, it will be harder to work with a business value perspective (assessing the business benefits of given feature sets), but far more productive and satisfactory in the end. Most project team members want to make an impact, see the results of their work, and feel they are making a difference for business users.

Micromanagement in Disguise

The Agile-esque methodologies of enterprise projects are the bureaucracy that younger generations want to avoid. They hate daily Scrums and feature/task management with yellow sticky notes posted all over whiteboards or their digital equivalents. Things that were fresh and cool for the early adopters of Agile seem strange and unnecessary to newcomers. Again, 20 years have passed.

Agile is a type of discipline, but today it’s too often used as a micromanagement technique, which goes against the spirit of Agile. Getting rid of daily sprints is becoming a default response to these frustrations, but it’s just the first step.

Disrespect for Documentation

A lack of documentation is often attributed to the Agile Manifesto; this is then used as an excuse for the lack of discipline within the project teams, resulting in system maintenance and further development becoming a nightmare. This is one of the major misinterpretations of the Agile Manifesto; probably the biggest one.

For instance, passing a product through the various phases and managing it without adequate documen­tation requires hours of one-on-one sessions with the previous developers. I witnessed a famous consulting company once propose the methodology of taking over the system development from one vendor by another.

To me, losing the ability to document things, despite the big advancement in dynamic documents for collab­oration (live documentation), is nothing but a sad degradation of organizational maturity.

Today, I see a movement back to documentation. A new kind of documentation that is useful and readable, but documentation nevertheless. Verbal communication is not the only solution for trans­ferring information and knowledge, nor is it the most efficient.

In the API-driven world, developers need good documentation more than ever, so let’s bring it back and appreciate it in a new form, eliminating this harmful misinterpretation of the Agile Manifesto and the resulting consequences.

Constant Team Assumptions

Project managers tend to like this one because they can use it as a justification for not sharing developers with other projects. People are confined to the space of a single project — some like it, but others consider it a huge artificial limitation.

Not changing team members for a long time is a recipe for burnout. Everyone needs a break or change eventually.

The solution is to embrace more flexible models, letting developers contribute to a variety of projects while staying open to new team members with different degrees of seniority and skill sets.

Seniority and Experts

Agile promoted a so-called T-shaped model (a broad range of skills possessed by each team member) to allow team members to fluently change tasks and reduce wait times. It’s a nice concept that is now being reinforced with new trends like full-cycle development and full-cycle developers.

However, specialized expert team members with highly focused skills are also of great value and should be appreciated, not avoided. They are underappreciated in Agile, but again, real-life projects demand an effective combination of experts and T-shaped developers in the right proportions at the right time.

Seniority and experience were completely neglected by Agile through the false assumption that everyone is the same. Even worse, many people misinterpreted Agile as a process for twentysomethings. Young, dynamic teams can greatly benefit from more experienced people, especially when it comes to architecture, code design, and product design: essentially, any area that benefits from experience.

Technologies change, but not as often as some initially thought (Java is more than 20 years old; HTML is the same), so the practical experience of senior team members can be of tremendous worth. The same applies to business domain knowledge, as it’s invaluable to the success of the project.

The focus should be on creating a balanced team so that experienced individuals work alongside less costly, less experienced workers. Everyone deserves equal respect and attention, but we’re all different, so the unrealistic utopia of equal team members should be abandoned once and for all.

Collaboration vs. Distraction

Agile teams often showed off their colorful offices full of nice gadgets, with everyone working in a large room, close to each other to enable collaboration. For many developers, this was a nightmare, stealing their ability to focus and killing productivity and creativity.

People wearing noise-cancelling headphones all day are too common in open spaces; they are trying to focus on their work by minimizing distractions. Offices built around this concept need to change. There’s time for brainstorming, discussions, and even quarrels or going to lunch together, but most of our time should be spent on the deliverables of the projects, which require focus. That means a return to smaller, preferably individual, rooms (these could be remote) with physical offices that serve as collaboration spaces rather than working spaces.

Servant Leaders?

Many organizations renamed managers, calling them leaders and telling them to earn their Agile certificates so they could become “Agile leaders.”

True leaders don’t just do the project reporting, they actively participate in the project. Converting generic project managers with no technological and/or business background into true leaders is seldom possible and requires a great deal of training.

By the way, in the original Agile Manifesto, there’s no one responsible for the project, but of course, by definition, everyone is responsible for the project as a team of peers with shared responsibility.

Does this happen often in the enterprise? No.

In reality, there’s always a person appointed as the project manager. So, this isn’t an Agile thing at all; let’s call this person an Agile project manager. Ok, now it sounds better, but let’s not forget that we’ve just rolled over the idealistic Agile assumption that no project leader role is needed.

A common Agile misinterpretation is that servant leaders should simply make sure all the requests of the Agile team are met and not interfere with the work. In return, the team will create the best products. Hierarchies of any kind are so out of fashion.

But what about hiring people, promoting people, and managing their careers and salaries? Yes, some interpret these in the Agile way, but it’s up to the team to decide all that. This usually results in an explosion of salaries and cost, plus constant infighting, resulting in chaos and a loss of focus on the project itself.

Another false assumption is that people are the same and have no other ambition other than to deliver the best solution.

Of course, we are humans, so there are always leaders in the group. It’s better to name them and give them additional responsibilities than to pretend there are no leaders just because it’s Agile. This idea goes against human nature and can be easily fixed by recognizing leaders and outlining what is expected of them.

Where Is DevOps?

DevOps is often believed to be the cure for Agile problems. Many practitioners, and I concur, think it was born out of desperation to address the efficiency prob­lems of the inevitable friction between development and production. Indeed, DevOps came about as a way to introduce transparency and promote effective collaboration between operations and developers.

This can happen in practice, but more often, the idea becomes another situation in which the DevOps teams are unable to communicate efficiently with both developers and operations, making the problem it was supposed to solve even worse.

The solution is to embrace the original meaning of DevOps: tasking developers with ops as well, add­ing one or two DevOps tool experts as internal consultants and coaches, but not as separate teams, thus avoiding the creation of DevOps silos.

Goodbye Agile Manifesto, Long Live Fusion

Budgets and time frames of digital transformation programs are exceeded by huge percentages, and it’s getting harder to deliver on promises made to investors and business owners. We can’t continue to pretend that current Agile methodologies are still the best way to go.

Let’s embrace the foundations of productivity and the feedback loops for continuous improvement, along with valuable criticism and skepticism. Get rid of Agile ceremonies that don’t work in a particular context, inventing new ones if the team needs them but keeping them to a minimum.

Let people focus on what they do, don’t force them to be physically cramped, and above all, don’t mix up velocity with adding business value.

Recognize that people are different, and don’t force them to behave as if they are the same — embrace seniority and embrace the experts. Do not fall into the trap of servant leader failures. Bring back the discipline of documentation using modern tools.

The time has come to set free the Agile spirit, abandoning its original manifesto and replacing generic, first-generation Agile with a personalized one of our own, a fusion of better methodologies for the 2020s and beyond.

Horses were replaced by cars, zeppelins were replaced by modern airliners, paper libraries replaced by the Internet, and waterfall by Agile. In the digital age it’s only natural that the pace of change will keep on accelerating. We need revolutions, not evolutions, and right now that means the dawn of the post-Agile era.

It’s so exciting to be an active part of this transition. Yes, there will be mistakes, but they will be fixed eventually, until … a completely new idea arrives and steals all the thunder.