The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
I don't know why Agile fails, because for over 20 years I've been doing it and it has worked great. Not perfectly, but great. But it has never failed me.
I really, really like Agile. I use it in my own development. However, the point of what Martin is saying is that many company and corporate environments have far too rigid rules for it to work there. That is very unfortunate. Have you read the book, Scrum: The Art of Doing Twice the Work in Half the Time[^]
It is one of the two original implementers of Agile and it is a great book. It details the _heart_ of Agile and I like the actual working process (no matter what you call that).
> value safety, consistency, command-and-control, and plan execution
is specifically to counter the chaos of:
> risk-taking, rapid-feedback, intense, high-bandwidth communication between people that ignores barriers and command structures.
Granted, middle-management structures are not the solution but tend to become necessary as the product develops from a two person garage shop (or dorm room) implementation into a company that employs thousands of people, many of which have nothing directly to do with software development (legal team, help desk, sales and marketing, etc) but are very necessary. And it is those groups that start driving the requirements that get fed to the actual developers, not the other way around.
IMHO, the problem with Agile (well, one of many) is that it's a concept intended to maintain the illusion that the developers are in control of the product, when in reality they are not.
Those are all very good points.
It also reminds me of the
Two Distinct Parts of Business
Its also the two distinct types of workers
1. builders (Wozniak)
2. sellers (Jobs)
You can't have one with the other.
Agile tends to be focused on The Builders.
It's a great method for getting Builders to drive the thing.
The Sellers really should drive the product to where it is supposed to be and _SHOULD_ own the product.
Marc Clifton wrote:
the problem with Agile (well, one of many) is that it's a concept intended to maintain the illusion that the developers are in control of the product, when in reality they are not.
This should be the part of the Product Owner. The Product Owner simply "contracts" devs to get the shtuff done. The developers shouldn't own the product. The Product Owner should be a person who is as motivated as Jobs to "Get it right!!!" and "Don't build crap!"
But the Seller must also KNOW EXACTLY what the product MUST be.
But, have you ever seen that in a company? Very rare!
So, the devs end up making the lion's share of final decisions.
They are way down the pipe and only seeing one part of the elephant and thinking it is one thing or the other: no overall vision.
...and just what have I done to p1ss you off this time?
"I controlled my laughter and simple said "No,I am very busy,so I can't write any code for you". The moment they heard this all the smiling face turned into a sad looking face and one of them farted. So I had to leave the place as soon as possible." - Mr.Prakash One Fine Saturday. 24/04/2004
That must be a very solid company that is running well.
Yes, it is (IMHO).
We started as a 25 person shop ten years ago and IPO'd last year on both the NYSE and TSX (we were the largest tech IPO in Canadian history). Although we now have 400 devs, we still think and execute (in many respects) like an early-stage company. I believe we are who we are because of our company culture. Almost all our dev managers and several C-level folk started out as devs and have an innate understanding of what it takes to build a software product. Our CEO values the people who make up the company and it shows. I'm grateful to work with bright people, and learn from them every single day.
You are definitively an exception (and I am officially jealous)
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
Aside from corporate values, structure and culture, I think Agile works better in some types of projects more than others and in some phases of a product than other. For example, a project with a lot of customer engagement is easier to acquire valuable feedback. A project with a single client is much easier to direct than a commercial product with many unknown users.
As for phases, the early phases of development involve a lot of infrastructure and architecture that benefits from planning for a longer view than just looking at the immediate requirements. Later phases involving mainly adding new features fit more naturally with an Agile process.
Web products, with their ability to immediately deploy, are better candidates for Agile than client applications or embedded systems that must be installed by its users.
I experienced this exact thing decribed by Robert C. Martin in one of my last companies (1000+ employees). The SCRUM masters always had to defend SCRUM's integrity against the managers and their traditional hierarchical superstructure. The SCRUM masters did a good job fighting this war, yet they had to make a couple of concessions, which were so essential that SCRUM turned into something not-actually-SCRUM-any-more. These concessions were:
- effort estimations in hours/Euros instead of Poker points
- SCRUM team members have to stay disposable for their non-SCRUM legacy projects
Yeah, it's too bad that Agile gets interrupted like this.
If it could go the way it is supposed to, it can be a very good process (probably the best possible) --- if it can go the way it is supposed to.
Last Visit: 24-Jan-20 11:13 Last Update: 24-Jan-20 11:13