Kleber Sotte’s Post

1. You must know what to build next. 2. You must know how to build it. 3. Do it. 4. Learn from it. 5. Repeat. There's too much cruft related to software engineering, processes, and digital products development lying around. Many trolls feed from it, especially in larger corporations, where they can disguise their lack of competence and productivity better. Don't drink from the kool aid, and you should be fine. Be it waterfall, agile, or the next big thing (tm).

Agile was introduced to obtain control over developer's wages and to explain to someone what they're actually doing, as the domain is vastly intransparent to the Senior management (aka the MBA crew). In other words, a substantial amount of information asymmetry is present in terms of required efforts and their costs, like when visiting a doctor. The asymmetry is still there, just now rather determined through a so-called consensus, between developers. Of course, one can think of other reasons. Cheers!

One of my biggest pet peeves is the misunderstanding of the goals and the misaligned expectations of Agile. You have on one side the "zealots" who, often in an attempt to do good, oversell it (making Agile the end rather than the means) and on the other side the "naive" who assume that if we are "doing Agile" (which is generally being very poorly implemented) then all our problems will be solved. I very much appreciate those who understand that Agile is an excellent means by which we can accomplish things but there is no magic to be had no matter which end you are on! Thanks for sharing!

Both the PM and SE community are developing new tools to put in toolboxes that don’t address the deep issue.. We don’t slow down the process, and get the right people on board to make sure we understand ALL the necessary requirements. We select teams to work on projects with out examining if they understand the problem or are part of the problem. More tools in the box just makes a heavier box, which then requires a 2 person lift under current Human factors rules, doubling the team size.

Kleber Sotte „Agile“ is just the answer to the question „How can it be done“. Your list above describes only „What is to do“. From my point of view two different issues that can‘t be mixed without accident. Is there anybody out there, who does not know the difference between „How“ and „What“? Or did you have another reason for that post? And a serious, maybe livesaving device: If you face a Vampire next time, take a wooden peg. Silver bullets do only help against Werewulfs. ;)

Agile doesn't fix anything, it is a way of thinking

Kleber Sotte To put it in a different way: " Agile Software Development Methodologies are primarily about Software Engineering and these methodologies are there to destroy false-hope which leads people astray. This is done by solid fact-based, measurable engineering tightly coupled with reality-checks." Lack of engineering = lack of agile. Glorified excel spreadsheets are not "Agile". Simple as that.

Great points. But maybe Lean and Kanban (in the Agile family) can help improve process workflow?

I can't help thinking, you are confusing "agile" and "Scrum". Is it agile to see the need for change and fail to make that change? No it is not. On the other hand, Scrum explicitly says it brings the problems to the surface; it doesn't fix them.