Do we need agile software development?
I have found this talk by Eric Meijer:
It seems he doesn’t like Agile.
What is your experience and opinion of Agile, Scrum, Kanban and so on?
Would you sign the Agile Manifesto or the Programming Motherf****r Manifesto?
This might be of interest (with a more familiar name) 
“Agile is Dead” by Prag Dave Thomas.
I do not like Agile much. it has some use cases granted , but agile tends to be shoehorned into everything nowadays.
I still haven`t really understood why a scrum master is needed to make my work harder than it needs to.
I can see the appeal of agile to enterprise management , there are courses to go to , signed papers that they can hang up on their wall.
I still say common sense, somethings will need in depth planning and somethings can be iterated upon. Having a golden rule to define it all makes no sense. especially in the hardware world where I hail from.
Having a agile zealot tell me why agile development is the best thing ever for a nuclear plant …
well I prefer to know that the most obvious hiccups are planned for and not something that we will look into in the next release.
Common sense wins every time.
Is there a good alternative to agile?
I mean, we aren’t going back to waterfall, right?
So what do you do when 99.999% of the software development population becomes disqualified from coding professionally for millions of dollars? Why not have the best of both worlds? down with agile, and introduce some type of professional sports engineering 
Going back to pure waterfall would not make sense in many cases , that would be as bad agile is in practice today.
Identifying the needs of the current project and adapt to that. In my strong personal opinion most people don`t need a course and a diploma to discern if this is something critical that needs a proper plan, or something that needs iteration as we go. most likely you are going to be doing both if you want to have some degree of success with your work.
I think the “alternative” is to be pragmatic? 
Agile software development, as per the manifesto (and the twelve principles), has great ideas, but it’s not like you have to have blind faith to all of it.
For example, this one:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
and this one:
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
and also this:
Simplicity–the art of maximizing the amount of work not done–is essential.
I think those are great ideas to have in your development team.
What I think is funny is that while one point of the manifesto said “Individuals and interactions over processes and tools,” most still emphasize precisely on the processes and tools (scrum, kanban, daily standup meetings, etc.).
TLDR; agile means adapting to the current situation, ever improving and searching for better ways to do things not getting stuck into a status quo and buzzwording on the train with lots of tool like lots of modern “agile implementations”
The problem is not “Agile” and its ideas but how it is applied and sold in many instances. A good friend of mine who was around for the early XP conferences blames it on Scrum being created by business people and sold to business people and engineered in a way that managers still have a comfortable spot. True agile software development doesn’t use all these fancy tools, it uses pen & paper…
True agile is about… well being agile - not following processes but doing what works best for your team. Try new stuff out, doesn’t work? Try something else. One of my favorite posts is Uncomfortable with Agile by Andy Hunt
A truly agile project team lives on the edge of chaos.
Not slipping back into a comfortable, somnambulant stupor, and not pitching forward over the edge and into the dark abyss of chaos. Do too little and you stagnate, too much and you crash.
Dave Thomas also formulated his “Agile is dead” thoughts in a blog post (haven’t watched the video though)
And I think one of the biggest problems is that everyone does “Agile” but most of try to do it by the book which is SUPER WRONG to my mind, some just pick and choose some parts of it and get totally diminished values. You gotta be agile to be cool, from Dave’s post:
Once the Manifesto became popular, the word agile became a magnet for anyone with points to espouse, hours to bill, or products to sell. It became a marketing term, coopted to improve sales in the same way that words such as eco and natural are. A word that is abused in this way becomes useless—it stops having meaning as it transitions into a brand.
In addition you can pay $$$ to become a certified scrum master within a weekend which is an enormous sad joke. Lots of “Scrum Masters” I met had no idea what they were doing, what they were doing was gardening JIRA and being gloomy when someone was late for standup but not really facilitating, unblocking people and improving the work flow as they ought to do.
In essence, I still believe in the ideas and values of Agile but I think most corporations don’t get them and think they do “Agile” thereby ruining it for the most part as they buy all the fancy tools to be “agile”.
About the values, Andrea Tomasini once gave a talk called “Why practices are not as important as principles” beautifully illustrating what happens with those agile practices if the company/people don’t understand and value the principles, which is what I feel happens at a lot of companies. I’m sure some of those feel familiar to some people here, little extract:
Sorry for ranty tone and lengthy post, but as you can probably tell how “Agile” is often implemented and executed is somewhat aggravating to me while I really like the core principles, values and practices while I still believe we might be able to come up with something better eventually.
“Common sense is not so common.”
* Voltaire, Dictionnaire Philosophique (1764)
.
By assuming your position is “common sense” and acting upon it, all you’re doing is insulting the people who disagree with you.
Your frustration is primarily with some of the more high-profile commercial exploitation of the Agile Manifesto, which has always been more about making money from the enterprise rather than upholding the Agile Principles.
It all depends on the context and just because something claims to be “Agile” doesn’t mean it upholds the spirit of the Agile Principles. Don’t blame the Agile Manifesto just because “The Enterprise” prefers to buy pre-packaged solutions from big vendors who don’t care whether their product actually solves their client’s problems.
The Agile Manifesto in itself was in large part a reaction to commercialized implementations of the Rational Unified Process of the period (2001).
Some issues were:
So the key idea behind Agile was to shorten feature delivery time in whatever way possible:
The problem is that many corporations are infatuated with the idea that with “just the right process” they’ll be able to go Henry Ford and start cranking out loads of product with an army of minimum wage drones - and they are willing to pay good money for pre-digested packages that give them the perception of moving them into that direction.
This is what leads to “Feature Farms” - which aren’t a notion that is supported by the Agile Principles.
To quote Mary Poppendieck:
we need to move from delivery teams to problem solving teams
That is the true spirit that I see behind the Agile Principles (with the caveat that it’s sometimes better “to do stuff” to figure out if you are on the right path rather than to overthink matters).
I agree! IMO, agile is about being flexible and adapting to ever changing circumstances. It’s also about being aware that upfront no one knows what precisely is needed, so we start lightly, iterate, and adapt as our knowledge improves. It’s a “do whatever works for you” approach, where we take small steps to gradually find out what in fact works for us.
With that in mind, prescriptive processes seem to be conflicting with agile. Therefore, I’m not really a fan of agile methodologies and processes. For the same reasons, I’m also not a fan of XP, which as far as I remember (disclaimer: it’s been more than 10 years since I’ve read about it) is also very prescriptive.
I’m all in for the pragmatic approach, you can find out what works in small iterations. I don’t like f.e. scrum at all and gathered a whole library of articles about it. 
Small part:
Anti Agile: Day 1: Why I hate Agile methodologies (a fun read to start)
http://okigiveup.net/not-big-fan-of-scrum (more about scrum)
Process kills developer passion - O'Reilly Radar (processes including f.e. TDD)
https://www.youtube.com/watch?v=nvks70PD0Rs (a fun movie)
https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/ (classical one)
https://www.linkedin.com/pulse/agile-dead-matthew-kern (a gathering of some interesting links, the writer I find arrogant)
Just some funny remarks
let’s talk about the famous 3 questions: “What did I do yesterday ? What will I do today ? Do I have any impediments ?”
Sounds like what my mum was asking me when I was 5 years old. “Well, yesterday at school, I learnt how to write my name.
And today, I’m going to do some painting… but it’s hard: can you help me mommy ?“.
I think model driven development is important to make a company agile. Get hard-coded rules, process flows etc. out of your code, put them in executable models and a business engineer gets ownership, transparancy and he can alter the models himself (no error-prone communication that travels over layers like productmanagers/owners and at last developers). Because the models are directly executable you don’t have to deliver new software (in a lot of cases at least, and of course the interpreter has to be delivered). There are OMG standards for these models: BPMN2.0 and DMN1.1. To give an idea I’ll show some screenprints of an application I’m building with elixir / phoenix:
These are examples of BPMN2.0 and DMN1.1 editors. Business rule task “Risicobepaling” (riscdetermination) is coupled to the DMN shown. These models are persisted in XML en directly executable (I built an interpreter).
This is the first usertask executing, below you can see the defintion of the task (slightly different BPMN than the first pic).
You can see the definitions working in the running application. The form definitions should be modeled separate from the BPMN, but that I have to implement yet.
This has been true for every interpretation Agile development I have encountered across companies from Europe and the US for the past 8-10 years.
Well if my entire team spends half a day to a full day during a week in meetings to satisfy the agile protocol I really do not mind if they are. When a scrum master decides that certain required by law safety features are out of scope and we cant implement them, I`m not gonna spend an hour in a meeting smiling and nodding.
No project is made equal and in my experience Agile ironically cannot deal with that. Just leads to more inefficient use of time. almost every time. and for some reason agile begins at scratch every time, there is rarely a way of thinking that would allow for some code reuse across projects within the same company.
I am not talking agile in its pure form, which might be good, but rather how most companies big and small implements it.
This looks interesting. so you can both document and create a “graph” visually ?
It gives more insight for at least not-dev’s than staring at the code. It’s BPMN2.0, not PMN2.0 btw.
I remain sceptical that any of these notations are universally effective when communicating with subject-matter experts (SME). UML initially made the same claim which turned out to be untrue and with Terry Halpin’s Object Role Modelling non-developers typically get off the bus right after Step 1: Transform familiar information examples into elementary facts, and apply quality checks of the Conceptual Schema Design Procedure (CSDP).
I’m not saying that these notations aren’t useful for the designer to visualize, represent and document the model that they are developing. And they can be useful when communicating with a very select audience. But I often find that these notations don’t convey a lot of meaning to non-developers.
So for the time being I’m still a bit cynical about BPMN - viewing it mostly as a basis for tool-vendors to dazzle their current would-be clientele to invest lots of money into the most recent versions of their tool suites - which most likely also act as code generators. Code generators have their place but by their nature tend to be dogmatic (narrow in focus) and will rarely complain to the designer about being inappropriately applied to a problem.
Don’t succumb to the false authority of a tool or model. There is no substitute for thinking.
Andy Hunt, Pragmatic Thinking & Learning (p.41 P1.0, 2008)
Often I find that it is necessary to “embed” oneself with the SME’s and possibly help them develop a more consistent (ubiquitous) language. Then after a clearly worded problem statement, valuable software solution features can usually be identified via narratives like for example Alistair Cockburn’s basic (text) use case template or user stories (or whatever else works - i.e. there is no “one size - fits all” solution).
sigh this. I hear you. Commercial interests have turned Agile (with a capital ‘A’) into a bad word. They’ve done it precisely by ignoring the core value system that “agile” represents. Yes, “agile” (with a small ‘a’) is a value system:
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
from http://agilemanifesto.org/ (that’s Dave Thomas of Programming Elixir on the far left in the picture by the way)
Does anyone dispute these value comparisons? I didn’t think so. I understand under certain conditions in which failure scenarios can involve loss of life, you need more accountability in your development process, but for the majority of business software, this fits.
Please, read the Agile Manifesto. Let that be what “agile” means to you, instead of letting commercial interests like “Certified Scrum Master (CSM)” be what “Agile” means to you.
Please, read the Agile Manifesto. Let that be what “agile” means to you, instead of letting commercial interests like “Certified Scrum Master (CSM)” be what “Agile” means to you.
+100
I remain sceptical that any of these notations are universally effective when communicating
with subject-matter experts (SME).
The goal is making the modeling tools so user-friendly that a subject-matter expert (I called it a business engineer) can model…
UML initially made the same claim which turned out to be untrue.
Maybe BPMN was developed after realizing that f.e. UML was not fit. Maybe DMN was developed with a need / foreseen value also.
I’m not saying that these notations aren’t useful for the designer to visualize, represent and document
the model that they are developing.
I was talking about executable models, not models to only document.
But I often find that these notations don't convey a lot of meaning to non-developers.
If you look carefully at f.e. only the DMN picture I sent, don’t you think it would be understandable for a
business expert? This is a “unique” rule, only one rule can evaluate to true. There are other rule types
editable btw. Easy to learn. https://camunda.org/dmn/tutorial/#feel
So for the time being I’m still a bit cynical about BPMN - viewing it mostly as a basis for tool-vendors
to dazzle their current would-be clientele to invest lots of money into the most recent versions of
their tool suites - which most likely also act as code generators. Code generators have their place
but by their nature tend to be dogmatic (narrow in focus) and will rarely complain to the designer
about being inappropriately applied to a problem.
That is very cynical indeed. It is a basis for others also. And again, I am not talking about documentation tools only or code-generators, it is about executable models. The point of executable models is well explained here, by such an awfull capitalist 
toolvendor: https://www.mendix.com/blog/the-power-of-mendix/
There are lots of honest and intelligent people working in this modeling business btw.
Don’t succumb to the false authority of a tool or model. There is no substitute for thinking.
Andy Hunt, Pragmatic Thinking & Learning (p.41 P1.0, 2008)
I don’t need the voice of an authority and I’m not succumbed. Stay critical, but do not cynically reject I would say. And modeling can’t be done without thinking.
I wonder if the biggest companies in the world uses agile. Like Boeing, Apple, Microsoft, etc etc
Why waterfall tool providers (UML things) are still in the business, like sparxsystems, no-magic, Visual Paradigm, etc.
Do startup-bubble in the last years contribute to agile-bubble as well. I mean, most startup use agile, right?
At google not really, if you mean strict adhering to f.e. scrum-rules. As far as I read. From my infinite libraries this one is a good read also (Yegge is from google):
http://steve-yegge.blogspot.nl/2006/09/good-agile-bad-agile_27.html. Small excerpts:
- there are managers, sort of, but most of them code at least half-time, making them more like
tech leads.
- developers can switch teams and/or projects any time they want, no questions asked; just say the
word and the movers will show up the next day to put you in your new office with your new team.
- Google has a philosophy of not ever telling developers what to work on,
and they take it pretty seriously.
- developers are strongly encouraged to spend 20% of their time (and I mean their M-F, 8-5 time,
not weekends or personal time) working on whatever they want, as long as it's not their main project.
- there aren't very many meetings. I'd say an average developer attends perhaps 3 meetings a week,
including their 1:1 with their lead.
- it's quiet. Engineers are quietly focused on their work, as individuals or sometimes in little groups
or 2 to 5.
- there aren't Gantt charts or date-task-owner spreadsheets or any other visible project-management
artifacts in evidence, not that I've ever seen.
- even during the relatively rare crunch periods, people still go get lunch and dinner, which are
(famously) always free and tasty, and they don't work insane hours unless they want to.
[..]
all you need is a work queue. That's it. You want hand-wavy math? I've got it in abundance:
software development modeled on queuing theory. Not too far off the mark, though; many
folks in our industry have noticed that organizational models are a lot like software models.
With nothing more than a work queue (a priority queue, of course), you immediately attain
most of the supposedly magical benefits of Agile Methodologies. And make no mistake,
it's better to have it in software than on a bunch of index cards. If you're not convinced then I will steal your index cards.
[..]
© Copyright Elixir Forum | Terms | Privacy & Cookies
