agile

I wrote in a normal post that I took a break to learn something new and to think about why Agile (with capital A) is such a pain. Like one week after that I was questioned about what do I think about "Agile" given that I am so old and therefore I must hate it. Amusing, right ? I have not found yet why Agile as it is advertised by companies giving certifications is such a pain but here are the places I started from.

There it is Agile Manifesto. Lately the same people who signed the manifesto are saying "no, this is not what we meant by Agile" or "let's talk about agility, not Agile" etc. Come on, you did not write tests, did you ? What do you expect ? Did you expect that everybody will understand exactly what you meant by "Business people and developers must work together daily throughout the project." or by "Simplicity--the art of maximizing the amount of work not done--is essential."? All the 12 principles sound like "Do unto others as you would have them do unto you.": very nice, but what if the reader is a masochist ?

Then there is the original Waterfall article, which was written in 1970 when the "coding" phase wasn't much different from what the Enigma operators were doing in the 1940s, which means the "woe to the waterfall" cries are pretty much a hard case of strawman, because in 1970 you could not do things much differently because you had to reserve time even to type the program, and then you had to reserve time to run it for the first time after everything was already typed. Even more, the article does not advertise the 'waterfall model', but explains why it cannot really work in the format advertised.

There is Bimodal IT, and there are people who have decided Bimodal IT is not well thought out, such as Martin Fowler, and the companies selling "Agile" certifications which decided Bimodal IT is completely bogus.

Then there are the Lean software development people who have at least a few good points.

I don't have an answer yet.

I suspect a workable agile approach is made of very short and cheap waterfall cycles which all end with the final customers using the code produced in one cycle and giving feedback, directly or indirectly.

I think the scrum meetings are useful if the team is smaller than 12 people. I suspect scrum cycles of two weeks are mostly useless except for marking time unless there is a production release at the end.

I have some thoughts on lean and all the metaphors borrowed from the Toyota process, but I'll let them simmer for a while.

That is it so far, that is on 2016-07-31. I'll update this when I get more.