Scrum in Ancient Egypt and Now
Table of Contents
The history of Agile goes back to February 2001, when a document called the Agile Manifesto was published. The text of the document consists of obvious philosophical formulas (simplicity is the art of not doing unnecessary work) and a number of controversial statements (the best technical requirements, design, architecture are achieved by self-organised teams). The document is a curiosity not only for its content, but also for the changes in software development that followed. In the shortest time on its basis were built the techniques of “agile” development methodology, which started their way all over the world, capturing contractors and customers. Adherents present the manifesto as a ‘silver bullet’ for all problems. In the most extreme cases, an ordinary programmer is ashamed to admit in public that he works in a company with a traditional development methodology (waterfall). In this article, I would like to invite you to consider and analyse with me the causes and consequences of this phenomenon, using the most widely used framework - SCRUM.
Let’s start by trying to understand what is new under the beautiful wrapper of Agile and Scrum in particular.
The Scrum of ancient Egypt
Agile methodologies existed before the Agile Manifesto was published, they just weren’t called that back then. They didn’t have a name, they were a natural, efficient way for managers of the time to run internal projects (internal being the key word).
Since we’re talking about ancient Egypt, let’s take the example of building a pyramid. So, an ancient Egyptian pharaoh decides that it is time for him to have his own pyramid (product). He starts discussing the idea of the project with the priests (stakeholders) and appoints his cupbearer to be in charge of the project (product owner). The cupbearer finds a clever bricklayer (Scrum Master). The bricklayer in turn starts recruiting helpers (Scrum Team), who go to the slave market and recruit slaves (Scrum tools: PCs, servers, software, etc.).
The Pharaoh orders that monthly reports on the progress of the building be submitted to him, and the mason and his assistants give a demonstration (demo) of the building to the Cupbearer every month. The Cupbearer in turn makes a report to the Pharaoh based on what he has seen. During the demo, the stonemason and the cupbearer discuss the amount of work already done (retrospective) and the work for the next month (sprint). At the same time, the cupbearer regularly communicates with the priests about their requirements (user stories), which he writes down on separate scrolls of parchment (backlog) so as not to forget, and from which he gleans information to discuss future work with the mason. And so on. We are not going to go into detail about how stickers, scrumboards and burndown diagrams looked in those days. Every competent specialist chooses the most convenient tools to control and manage the project, and it makes no sense to draw analogies with the tools of that time in our case. Excessive details (hello, agile manifesto) are not important, because it is already clear that the methodology worked back then.
This suggests that at all times, competent managers have used agile methodology in the implementation of internal projects because:
- competent enough to design the end result;
- competent enough to control the implementation process;
- have sufficient power over the participants in the process;
- the time, cost and quality relationships are not dogmatic and can be revised if necessary;
- and, most importantly, the end result and the process leading to it are in the same hands and have the same interests.
But none of the items on this list would apply to an external customer, so agile methods were not used for custom work. After all, people in those days were simple and intolerant, and could easily lose their heads if a deadline was missed.
Scrum today
The only novelty that Scrum has acquired today is the fact that it is used to implement external (custom) projects. This side of the framework’s history should not be sanctified, because if someone wants to pull the strings, it will reveal the true motivation of the market participants who met in February 2001 to write the infamous Manifesto. In essence, the manifesto and the whole argumentation of the choice of Scrum is pure propaganda of the contractor’s interest, veiled in the struggle of good against evil, in which the customer acts as the evil. The genius of the solution offered by agile methods is to convince the customer to sacrifice the result for the process.
What happens if the product owner is an employee of a third party company? Firstly, the end result and the process of getting there are in different hands. Secondly, there is now a second stakeholder in the process with its own commercial interests. In addition, the outcome is important to the client, and the process is important to the contractor (because when the process is over, the money stops flowing). And nothing can be done about it, because another philosophical formula applies here - ’nothing personal, just business’.
Agile is good for market players on the executor side because it allows them to do that:
- make money on the process without responsibility for the outcome;
- reduce expenditure on competent managers (why pay expensive in-house specialists when the Manifesto allows you to use the customer for this purpose).
Having seen the benefits for themselves, programming teams of highly qualified specialists with systems thinking turned into companies hiring middle-aged coders and producing products of dubious quality (while squeezing customers financially, which is easy due to their competence and almost always complete incomprehension on the part of the customer).
Let’s imagine the process of building a pyramid for a modern pharaoh. The Cupbearer starts looking for a team of masons and tries to find out the terms and costs of construction, but the foreman tells him nothing:
- we are a creative team, we will work to our own creative process and you will pay for each hour of work, materials and other overheads, including staff meals;
- there cannot be an overall plan for the project as you will probably have suggestions that go against the previous ones, so we will make a plan as the requirements come in;
- we will work out how to incorporate things as we go along;
- if something is done wrong, we will do it again, but you will pay separately for the time and extra materials used;
- every fortnight we will meet and talk about our problems, and then together we will plan what to do for the next fortnight.
Any sane person who knows anything about design or planning will not readily agree. But IT customers agree, which is logical, because they are under pressure from competent executors who say, in clever words, ‘you’re screwed’.
The client not only agrees to unpredictable terms and costs, but also assumes responsibility for the end result (the ancient Egyptian pharaoh laughs nervously). As a rule, the client’s qualification does not allow for a formalised presentation of the requirements for the end result and professional control of the process. It is always easy for a competent professional to confuse and distract the customer (in the absence of at least a general TOR, it is easy) to solve a lot of secondary problems (which actually arise due to the lack of long-term planning).
Consequences of agile worship
The quality of software products is inversely proportional to the prevalence of Agile in the IT industry. Where can quality come from when the development process is focused on solving the problem in the easiest, fastest and cheapest way possible, and planning ahead is officially banned by the methodology!
As a result, we end up with software products that resemble ‘patchwork quilts’, where parts of the same software are made by completely different people. On one software screen you will find a mixture of different design styles, different approaches to ergonomics, and the icing on the cake are different algorithms for similar elements. This is logical because there are no TORs for the product, everyone is doing what they are used to and comfortable with, and the testers are constrained by tight sprint deadlines.
What’s the point of writing it?
The above might lead you to believe that I am an avowed opponent of Agile. But I am not. As Paracelsus said, “Everything is poison and nothing is without poison; it is only the quantity that makes a substance non-poisonous.
Agile methods are suitable for small and medium-sized internal projects. The size of the project is only limited by the ability of a given manager to ‘see the wood for the trees’, i.e. to keep in mind all the details of the work, the desired outcome, and to systematise it.
Flexible methodologies are limited in their application to external projects. In this case, the same requirements that apply to the internal project manager should apply to the client. That is, the client must be an IT professional, not a secretary doing the job part-time. He or she must be able to check the qualifications of the hired team and constantly monitor the quality of the product being developed. In addition, the product to be developed should allow for the replacement of the development team. This is the only way to ensure that there will be no resentment over wasted effort.
Agile methodologies have their place in the sun, but they are severely limited in the realm of contract IT development. But what if your project doesn’t fall into the Agile-applicable category?
The interesting fact is that agile development has not taken root anywhere except in contract software development. Spaceships, rockets and aeroplanes, even cars are not built according to Scrum. The wisdom of our ancestors gives us the knowledge that even a birdhouse cannot be built without a design (even a pencil sketch with dimensions) and a TOR (even just a list of tools and materials). Everything you see around you has been created thanks to the old tried and tested ‘waterfall’. So why don’t you use it? You won’t believe it, but it will work.
Instead of a conclusion
The above is a consequence of my observations over 10 years of contract web development using both traditional and progressive approaches. The motivation for writing this article was the overwhelming feeling of getting my hands on a project that had been developed according to Dr Frankenstein’s rules.
Use development methodologies like medicines - as prescribed)