This post is quite special because I am translating a French Post talking about Agile.
It is rather a long one (about 9 pages), but the author states some sharp truths and view points, which let you think for quite a while!
With the authorization of the author, I translated it entirely. Here is the original French version "L'Agile est mort"
http://douche.name/blog/2011/08/08/l-agile-est-mort/
I share most of his views, except some points such the one concerning Scrum (no! I am not a Scrum consultant and started my agile quest in 2001, as a developer working for an ISV that had to be a UK market leader in his field. Moreover, I currently work for another software vendor. I am just an agile lover).
To my perspective, Scrum is not that bad:
- If you
ignore its related marketing aspect,
- If you are
already understand the philosophy of Agile but are just missing some guidance to actually transform your philosophy into practical project,
- If you could
break free from Scrum template, once mature with Agile,
As far as I am concerned, my career lead me though the following path:
- Get the Agile state of mind (yes, you should feel it ! it should enlighten and change/explain your way of thinking),
- Practice it in real cases (for instance 2 projects) and read a lot at the same time (Blogs, Books, articles...) and speak to as many agilist as you can (conferences, user groups, ...). Then, start to go deeper into agile,
- Start to realize that the more you know about Agile, the more you are convinced you just scratch the surface of it. This is a good sign! Now you have to improve and adapt all the time (for years, day in day out),
- Then get into Scrum and practice to help you. And read A LOT about Scrum and Agile to go beyond the marketing aspect (read Mike Cohn that quote hundreds of references and examples, and other authors that will make you think even more, with other references to other books and quotes and examples) !!
This should give you mature answers to your own questions and past mistakes (at least it did for me). Some advanced elements of Agile would have taken me a while to converge to a satisfying answer, if I had to rely only on my own "try and error and improve" approach.
- FINALLY adapt Scrum to have more freedom inside the Agile world, and don't forget to BLEND it with other methodologies and most importantly adapt it to your company / situation / team / constraints...
Here is the translated
post . Do not hesitate to give any feedbacks to the author or myself as needed.
Rumination From a Tortured Mind
Agile is dead
Under this title - that might seem provocative - can be found some rather bitter facts. It is even sadder given that fact that we could have predicted this situation many years ago. Agile has become mainstream, we talk regularly about it in newspapers for IT decision-makers (which is a proof of its spreads, isn’t it?), developers claim to practice it daily, so does project managers. So why being pessimistic? Because each month proves it, for instance, when someone stands in from of me saying:
“Agility is real crap!”
And that happens to me very often (but not necessarily that vulgar). It would take less than 2 minutes to determine that that person does not work within an Agile context at all. Last but not least, a good sign that Agile is dead is when you hear so-called experts saying non-sense on blogs, newspapers or mailing lists.
Oh, I see you saying, "but who are you to define what is and what is not Agile?". Excellent question! In fact, if defining the edges of agility is difficult (especially in 2011 when many practices or movements call themselves Agile), it is a lot easier to claim what is
not Agile, when it
totally contrasts to
the philosophy that Agile wants to embody. While the amount of practices has increased, the basics are still set in stone and clear. All those practices must be derived from the same core.
I like to compare agility to Free Software (I am into both Agile and Free Software fields for a while – 10 and 15 years respectively) since it mixes high-tech and human being. They both are a partial
representation of the world with relationships between people:
If I release a software as a Free Software, such as BSD, but I do not offer a bug-tracker or mailing list, or I refuse any external contribution, or I make my code obfuscated, or I ignore users’ requests, I am indeed writing a Free Software (and my license proves it). However, it is only a substitute (i.e. fake), as I do not respect the initial philosophy of Free Software. It is similar with agility.
As far as I am concerned, agility sums up in three points, which you could easily verify the presence.
Searching for a value
Often called inappropriately “a working software”, the goal is to provide the end users with a functional, usable and handy application. Unless you are developing the same application for a while again and again, it is usually a discovery land for both the customer and the development team. So it is an utopia to believe that we can define in advance the full specifications of the software. The primary aim is to produce a software nice and functional, not to release it quickly. The “waterfall method” is in many ways the most efficient approach to generate rapidly software:
- I listen to the needs
- I understand and validate the specifications.
- I am developing it.
- I test.
- I deliver.
There is no faster way of doing a software. If you are doing the same thing for 20 years, no worries. I only heard two (yes two, not three) companies that can deliver successfully within schedule 99% of the time, and they are based on “waterfall method”. And not surprisingly those two companies were coding in Cobol on a mature platform with highly similar needs, with:
- A constant Team.
- A well known technology and platform's architecture.
- Business strongly mastered.
- Similar products.
In a nutshell, an ideal environment. But it is unrealistic to expect from a client the ability to accurately define his needs. Not only he does not know what he wants, but often and afterwards he realizes that what he managed to explain was in fact irrelevant! Worst, his business or his needs have changed between the developments' start and the end. I do not even mention the ability of a development team to deliver a quality product in one go, especially if it is discovering the customer's business. In short, it is utopian. Let's consider that this is due to the immaturity of our job, the youth of our tools and a training too basic.
On the contrary, agility is intended as a quest for meaning:
- What should I get?
- What features are really useful?
- Is this functionality needed? (Note: cannot translate the original text “N'est elle pas le symptôme d'un problème non technique ?”)
- To the extreme, is this software useful?
It is a collective effort, starting from the developer up until the customer to understand, analyze and develop business value. Otherwise, you will have a cascading style: we agree on a functional scope, the cost and the timescale and let’s go!
Let's talk about the second point.
Human centric
What also emerges is this constant desire to put people on the first stage, and not the tools nor the processes. The latter are helping human, and not the other way round! The development primarily dealing with developers. You have
to trust people, respect them in their ability to develop, in their judgments. To me, this emphasis seems to be missing from previous approaches such as waterfall or RUP. These are rather process oriented, with dozens of procedures and huge documentation. The developer being just a single drop within the system.
CMMi is a good example of this vision: the official and lengthy documentation deals with organization and processes. And worse, you must be CMMi certified to read a CMMi documentation (where is the error?) so much it is unreadable and full of incomprehensible terms. In fact most of them are using “cascade” which indicates their belief in the processes.
It was not until 2010 when we seriously hear about CEI’s agility (added to the original text: see http://www.ceiamerica.com/outsourcing/methodologies.aspx), i.e. 11 years after the book of Ken Beck!
On the contrary, agility favors “the interaction over processes”, the result over documentation. This is possible by collocating physically all participants, by organizing short but regular meetings, and by listening to people.
Now, let's see the third point.
Development is a discipline
The developer is back at the center of the developments. In exchange we asked him to master his job: not only we want software that works, he must always keep questioning himself, learn to do better and to refine its development techniques.
The software industry likes to be seen as an artisan (each fields likes to describe themselves elegantly) just like drivers, bakers, cooks, musicians ... except that the software industry is not only very complex but also is just at its early days: 60 years. This is little.
Agility brings a lot of interesting solutions: for instance, the TDD, testing, peer review, continuous integration and refactoring. Of course a developer worked very well for a while without ever having read a single book on agility. After all Ken Beck and his acolytes have discovered these techniques, why not others? Yes, but ignoring agility would mean putting aside years of thinking on software development practices. That would be a shame.
So why saying that Agile is dead?
I am unfortunately not old enough to know what was happening in the 70th, 80th and 90th in the software industry, but I might not be wrong saying that agility is a decisive milestone. However, I am an old Geek who bought quite a few books on programming 20 years ago. Nevertheless I have no memories of books (well at least in France anyway!) that even have any slightest talks on agility. Instead, we learned by mimicking codes from masters (cracking software, listening to demo-makers or chatting on the BBS). Practices that were nearly unknown 10 years ago are considered essential practices nowadays (you did write a lot of Unit Tests in year 2000?).
Agility has
enlightened thousands of developers, including myself, and improved our job by building for the first time a stable ground. It is still the beginning, but every day we try to better understand this job and its dear difficulties.
But you know what?
Who cares?
Agility is a new fashionable technique
It soon becomes clear that the majority of organizations uses Agile because they have heard it works but they do not give a damn of what is inside. And for good reason, because this would mean for organizations to reconsider two fundamental visions:
- IT is a cost, not an investment.
- Employees can be replaced, not the bases of the company.
Not wanting to question these two assumptions, it can result in an abuse of the Agile movement. And that is what is going on. The Agile is therefore a fashion, just following the one on Object Oriented development, Design Patterns, C++, Java, frameworks, RUP and others. New ones will bloom in few years time, when the promises of Agile evangelists will have crashed against the wall of the businesses’ reality.
But what are “They” doing?
Some
iterative and incremental development. “They” cut their developments into smaller chunks, with regular checks. What is the common point with the Agile I described previously? Nothing! Trusting people? Let's be serious, “They” practice regularly
command & control, which is a technique of getting people working as puppets, and then accuse them of doing badly their job when something goes wrong. See development as a discipline? You talk about CFO's purchasing departments that crush down the developer’s daily rate? Concerning the seeking of business values, this would mean criticizing the current of the organization’s processes.
Do you start to understand me?
“They” are selling you Scrum, which consists of having chunks (called iterations) with regular demos and daily meetings, and a retrospective from time to time. And the trick is done, thus “They” are doing Agile!
Tell me if these few examples remind to you anything:
- The Project manager is called ScrumMaster, because he attended a two-day training.
- The relevance of business functionality is not evaluated.
- Under qualified or inexperienced developers are picked because they are cheaper.
- The pair-programming and code review are too expensive and unnecessary.
- The ScrumMaster assigns tasks during each daily meeting.
- The retrospective is done with the customer.
- A specification document is created before developing.
- Time is never spared to review the elements/processes that cause problems.
- Late hours are required to catch up or manage the new requests from the marketing.
- The project will hit the wall but no one does anything.
- People are micro-managed.
- The project is divided into delocalized teams thus never have any eye contacts.
- Team members are not given the ability to increase their knowledge.
I could add many other examples, but you get the idea. Where is the Agile philosophy? Absent, because organizations do not want to change their views on software development, and even less concerning the way they work.
Why are “They” doing it?
Because it sells, of course! Consulting firms went onto the market; associations were formed to develop this business. So it sells, and pretty well now.
But how to perform Agile:
- in a command & control environment?
- in a culture that blames and searches for the guilty, and where each manager opens their umbrella at the slightest trouble?
- When a specification document is handed without questioning what the business’ needs are?
By tweaking Agile so that it could fit into boxes.
An example? The great
hypocrisy of the Agile development on fixed price contracts. Let us have a closer look: the fixed price contract consists in defining a functional scope, a timebox and price for development. Does it remind you of something? That is the reason why "Agile for fixed price contracts" topics sneaked into every Agile conference for years. It is because every IT decision makers are wandering how doing it.
Agile died in 2001
More precisely in
February 2001, in Snowbird Utah, United States. It corresponds to the creation of the
Agile Manifesto and the term Agile. Generally speaking, it is the willingness to develop a
model / a framework. Staring from 2002, books with the agile term in the title begun to bloom.
This may seem surprising to say this (since it is also the beginning of the Agile movement) but the purpose of standardizing terms and principles, and freezing them was primarily done to selling it. It is curious to notice that out of the
17 signatories of the manifesto, 17 of them are consultants: all sell books and trainings. The Agile Alliance was formed in the row to promote it.
A sclerotic model that cannot evolve
What are the results in 2011? Despite some progresses, the official discourse is close to the Agile of 2001. We did not learn anything 10-years time? Of course there is: the development by iterations and taking into account of the organization in the development are just two fundamental examples. But still, the Agile model remains quite insensitive to those changes.
We have seen some new features but nothing too serious. Why? Because we are more interested in selling to thinking. Because before being able to think
one must do first! Writing books and doing consulting cannot help. XP is the result of many years of practice of software development. Taiichi Ono (founder of the Toyota Production System) spent several decades to perfect its organization. He probably did not ask his new organization to pass a TPS certification 5 years later!
There have been slight shifts from the developer to the organization. Although the Agile model opens to the outside world, it is limited: just look at the role of the PO (Product Owner), a proxy of the company. Where are the stakeholders? What about marketing? Techniques? What about searching for new markets? What about deployment? And the operational side? The user experience? Design? Basically, where is everything else?! The void, the brains of the Agile model are still strongly talking about TDD and planning poker, what a big deal!
Worse, this slight positive is balanced by the craftsmanship movement, (added to the original text : http://www.infoq.com/news/2008/08/manifesto-fifth-craftsmanship) which aims a return back to the origin, self-centered to the developer. The only interesting progress has just been sent to the void! If you want to know why, just look at the business of the founder's movement, Bob Martin, who sells books and training ... on how to code. Surely, the company-level is not useful to his business. It is also funny to see people swoon over this movement as if it was new. XP said roughly the same thing 13 years ago. Moreover, it is significant that it is mostly Scrumistes (in France at least) who promotes it, as they openly criticized XP.
Conclusion
I hope I have clarified my point on Twitter (140 characters is sometimes too short :-)). No, do not stop doing the testing, pair programming and daily meetings. No, do not underestimate the impact of agility on our job. It is quite the opposite! I encourage you to read books and blogs, and take what you need.
You only have to have a systemic vision of the movement
(comment added to the original text: i.e. ignore the causes, and try not to analyze it psychologically, and do no use models), understand where it comes from, why it was created and why some people sell Agile. This allows for example to understand the
Agile Manifesto, instead of stupidly repeating its content that is far from optimal in 2011. This also explains the model created in 2001 (and Scrum in 1996, and XP in 1999) and why it has been slow to spread, and does not bring any new elements for many years. If money was always the engine, the model is now warped
to fit into the matrix of consulting, far away from the original objectives. And neither the
official voices (Agile Alliance, Scrum Alliance), nor its
thinkers rose up against that. Worse, they were actively involved in this perversion (who said certification?).
I could sum up my opinion as follow:
Agility is an important step forward, but the Agile model is useless. This may be the fate of any model. In any case, it is time for each organization to invent, as Toyota did for its own vehicles' production. A model
adapted to the business, the customers, and the employees. A model that
takes into account all the new improvements that can be found in movements such as Devops, Lean, Lean Startup or Kanban. A model that is constantly
evolving along with its maturity and its ability to organize its production.
But having tried to do it constantly for the last 4 years, I can guarantee you that it is way more difficult and painful than having a 2-day training, or urging to apply what one has read in a book…
