Do you think your “local agile expert” has read Agile Manifesto? Have you? Well, it’s not a problem… if you don’t use the word “Agile” on the daily basis! But if you do (or your local expert does)… well - that is something like people who talk about religion, but haven’t opened the Bible (political correctness alert) or the holy book of their choice, since their literature classes 10 years ago… We don’t like them. For a reason.
Ok ok, let us not comment other people and their opinions. Let’s, instead, go through the “Agile bible” step by step.
Quotes from Agile Manifesto will be given in
this kind of text block
and our comments will be given in regular indent like this. Let’s go!
The Manifesto, one and only
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
This is such a great idea! It really was revolutionary at the time it was made! But the execution of this idea is something way harder than these few lines could have perceived.
Main problem: Everyone who has had a direct contact with the customer, knows that this Manifesto’s point is at least somewhat tricky.
Sadly, customer is not always sure what does (s)he want, or (s)he wants too many things at the same time, and cannot prioritize them properly! Moreover, it may be that some of those things customer thought (s)he wanted, later did not want…
If we put that aside - the Manifesto’s point does prove its value to the success of the product! But these exceptions should NOT be neglected, as they may be fatal!
Next point covers something similar, let’s continue this topic there.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
This is great. But constant pivoting and pressure on the development team makes the product frail. Coding fast with lots of project redirections, makes the product’s code quality low, so changes become harder. More rational and calm development improves efficiency of making changes in the later stages of product development. We agree that changes should be welcomed, but other contract/agreement clauses should also be changed proportionally! In many cases, product is expected to be deployed in the same time as it would have been in case of no additional changes requirement. Not cool.
Agility is about being ready for the expected changes, and not about changing everything and always. Ones who are accredited to communicate with potential client/customer should negotiate realistic agreement from the very start. Often, 10 minutes with pen and paper in the right time (project beginning) saves days, weeks, and even months of development (redirecting, pivoting, changing) in later stages! This slacking in products start should be considered unprofessional, because it very much is! The “let’s just get the client, later we will think of something to finish the job” mentality is unethical, and too often does it come to developers to “save the day” (work overtime, work weekends, work from home, work in stressful surrounding)… Not cool. And really - not even agile.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
I only have good experiences with this one. It gives possibilities for early traction-testing-learning-improving feedback. Great stuff if Agile concept is applicable in software development of needed type of product. (Not always the case, believe it or not.)
Business people and developers must work together daily throughout the project.
Ok, maybe not daily, but also - thumbs up! We (people) haven’t managed to ruin this one in the last 15 years… Give us time.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
This is where most of the so-called agilists fail to act by Agile Manifesto. They often lack respect to the individuals who are, if not experts, still better professionals considering their field of expertise, than the “agile” project manager. That makes the manager involve too much in other people’s work, which breaks the important “machine gears”, one by one. Making further “machine” agility and reliability for change lower. Which is counter agile.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Well, we cannot say anything against this one. In contrary, hooray for it!
Working software is the primary measure of progress.
Yes. The problem is that many of the so-called agilists also don’t respect this clause.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Hard to achieve, but of course - great guideline.
Continuous attention to technical excellence and good design enhances agility.
Again, sadly, so-called agile project managers often forget about this one, thus making serious, if not fatal, consequences.
Simplicity–the art of maximizing the amount of work not done–is essential.
Hail, simplicity!
The best architectures, requirements, and designs emerge from self-organizing teams.
Ave!
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Amen!