Sometimes it seems that jokes about management implementing Agile to do more with less aren't far from the truth. I've rarely seen development teams understand Agile as anything more than a set of ceremonies, most often associated with Scrum.
Projects are bound by constraints. The three fundamental ones are time, cost, and scope.
Let's delve into the "Constraint Triangle":
The combination of these constraints — time, cost, and scope — is often referred to as Constraint Triangle. Some even call it a tool. I suggest treating it as an illustration of the interdependency among these three constraints.
Imagine you can pull on the corners of the triangle, but changing one corner inevitably affects the other two. If we want to do more work (scope) in less time (schedule), it will likely increase the cost. If we aim to reduce costs, then either the schedule will extend, or the scope will have to decrease. This is a constant struggle and balancing act that all teams and project managers face.
A project that has a chance of success begins by fixing one constraint, such as the budget. Then, based on the budget, the timeline is calculated and fixed, and if necessary, the scope is adjusted.
Businesses are often willing to add resources, such as people, to the team to shorten timelines. However, this can be very challenging and not always possible. At best, the timeline remains the same, or it might even increase.
Saving on quality is also not part of Agile. Usually, when talking about quality, many think of bugs or defects. But there is also technical quality, which reflects how productively the team can work on tasks in the future. The worse the internal quality, the more time the team spends adding new functionality. If technical quality is high, you can "borrow" from the product in the short term. Remember, though, that this will cost the business in terms of reduced team productivity in the future. Moreover, repaying technical debt later will be more expensive than doing it right the first time. Technical debt can be seen as a bank loan: you will have to pay back more than you borrowed. So it's crucial to understand why this is done and where this "debt" will be "paid off" later (I recommend reading an article that technical debt is not only a problem for the development team). If this approach is used thoughtlessly, it will be like people taking loans to cover loans, which were taken to cover other loans. In the end, the product will face technical bankruptcy.
Nevertheless, companies strive for optimization. They want more features and faster. Therefore, some send employees to courses and training, and if they have the means, they hire a coach from a consulting company. At the same time, a truly advanced external consulting organization does not guarantee results. They just mere commit to move iteratively. With the option to terminate the contract by paying for the last phase. Essentially, you are buying time without a guaranteed result. They understand they are selling a standardized process that, without changing the mindset of key leaders, the team, company values, and business, will not yield the expected results. They will tell you how great and easy everything is, but won't mention that this is not the main thing. Rather, they will mention it to later say, "Well, we told you, it's your own fault!"
But they will do their job: introduce short sprints, establish regular stand-up meetings where everyone strictly reports what they did, what they plan to do, and what problems they encountered. They will schedule demo dates, sprint reviews, backlog refinements, and other trendy artifacts. However, stakeholders and the business will likely won't change theirselves, because they truly confident, that the problem in the team. So then, they will remain dissatisfied with the team's results, and seeing no other options, they will have to accept the existing situation. As soon as they tire of Agile and loosen control over the process, the team will develop its own "Agile".
So where is the magic of "doing more with less"? It doesn't exist. You can manage the scope of work. But the business disagrees. Because when someone has already thought through how to do it and submit it to the development team as a set of specifications with decomposition into user stories, any management of the scope is seen as simply refusing to complete certain backlog items.
The business thinks it needs everything. In reality, not, but it thinks it does.
A small feature of region selection was developed in a project. It went through automated testing, acceptance testing, and was released, making everyone happy. However, when telemetry was analyzed, it turned out that only testers used the region selection feature over the year. Users did not need it, meantime initially, the feature was considered required for the first version of the product.
In this approach, developers are given the freedom to choose, but only within the details of implementation. For example, they can decide whether to create a simple pop-up window with an error message or add extra features. Following Agile principles, the team jointly decides that a standard message is enough. It makes the impression that the decision is made collectively — here’s Agile in action! However, the Product Owner initially preferred a simpler option that would take less time. But since the coach insists on Agile, "flexibility" was proposed, so the coach not to interfere with work.
If the development team proposed an automatic error handling option instead of a message, the Product Owner would start negotiating changes with their management and other stakeholders. And since the Agile coach demanded not to define requirements in advance but to discuss them with the team, the Product Owner did not share the pre-signed by CEO and other major stakeholders and nailed-to-the-wall requirements.
When the organization has changed, being supported by the CEO, the team and the product owner have given the real authority to decide how work would be done, the processes became more flexible, and the work improved. This allowed the product owner to fully utilize their potential in new conditions, where the company's structure and approaches facilitated more effective work.
The business will want to see implementation as quickly as possible. But if someone influential keeps the scope rigid, developers more or less maintain quality at an acceptable level and do not increase technical debt, then timelines (and costs) suffer. Work goes on, developers make efforts, but they do not meet the deadlines.
There hasn't been an invention to change this Constraint Triangle and create some loophole to bypass these bounds.
Let's start with the fact that, as we discussed at the beginning, it is very difficult to change something if business representatives have a waterfall mindset. It is intuitively simpler, clearer, and more familiar for them. Sometimes it can’t be done any other way, for example, when outsourcing development (it's not actually fully correct). But if there is an opportunity, you can adjust the scope without abandoning functionality by revising ideas and approaches to the solution. The same problem can be solved in many ways. When developers are involved in discussing the problem and understand the benefit they want to bring to the user, the likelihood of discovering an unexpected and effective solution increase. Thus, the problem will be solved, and time will be saved.
Software Developers (the good ones) are inherently lazy and will be happy to propose a simple solution to a problem.
Salespeople needed to see the contact details of potential clients in the CRM. Contacts details could be found in an external system. The development team was tasked with changing the CRM to synchronize data from this system. However, after talking to the salespeople and understanding their real needs, the team decided to abandon the initially proposed plan and developed a Google Chrome extension. This extension allowed the necessary data to be automatically displayed directly in the CRM forms without data manipulation, simplifying the process and reducing development time several times over.
So, to prevent Agile/Scrum from turning into a waterfall with frequent iterations, the team must be involved in solving business problems. The product owner's job description should exclude the requirement to sign requirements with stakeholders and instead grant them the authority to independently commit to these requirements based on dialogue with the team. For the business, it is not important how a problem is solved. Business exists by solving problems that either bring in revenue or reduce costs. The goal is to solve the problem as economically as possible so that the solution brings in significantly more money than the team's salaries and other expenses. Preferably, several times more.
If the requirements are determined before the development team is informed about them, it is definitely not Agile. There is nothing wrong with that; it is just important to properly perceive the situation and not to have false expectations. Short iterations themselves do not make a team Agile. If the requirements are defined in advance, do not be surprised that one sprint is spent on designing the feature, three sprints on development, followed by a stabilization and testing phase. And of course, you should accept that even this timeline will be failed.
