Nerval's Lobster writes:
Many development teams have embraced Agile as the ideal method for software development, relying on cross-functional teams and adaptive planning to see their product through to the finish line. Agile has its roots in the Agile Manifesto, the product of 17 software developers coming together in 2001 to talk over development methods. And now one of those developers, Andy Hunt, has taken to his blog to argue that Agile has some serious issues. Specifically, Hunt thinks a lot of developers out there simply aren't adaptable and curious enough to enact Agile in its ideal form. 'Agile methods ask practitioners to think, and frankly, that's a hard sell,' Hunt wrote. 'It is far more comfortable to simply follow what rules are given and claim you're 'doing it by the book.'' The blog posting offers a way to power out of the rut, however, and it centers on a method that Hunt refers to as GROWS, or Growing Real-World Oriented Working Systems. In broad strokes, GROWS sounds a lot like Agile in its most fundamental form; presumably Hunt's future postings, which promise to go into more detail, will show how it differs. If Hunt wants the new model to catch on, he may face something of an uphill battle, given Agile's popularity.
The problem is not methodology...
By erp_consultant
•
2015-May-14 13:27
• Score: 3
• Thread
it's management. When you get a good project manager its like a breath of fresh air. The best PM I ever worked for was a guy that used to be a developer and just didn't understand object based programming, after an honest assessment, so he decided to go into project management. He shielded us from all the corporate BS and just let us code.
Most of the other PM's I have worked for have no background in programming. Some of them claimed to and didn't, which is much worse than someone that just tells you they don't. They would insist on idiotic exchanges like the following:
PM: How long will it take to code this?
Me: I'm not sure until I get all of the requirements
PM: Can you give it a guess?
Me: Sure but what's the point? It won't be a very good guess.
PM: That's OK I just need something to put on the project plan
Me: *Bullshit radar is now on full alert* So you just want me to pull something out of my ass so that you can finish up your project plan? Is that it?
PM: Umm, well, no...it's not like that
Me: OK, fine. I'll give you numbers but they are going to be grossly inflated to account for the unknowns. It covers my ass. Kind of like what you are doing, no?
PM: *Grunts and walks away*
Most of these people look at project management as if we were building widgets on an assembly line. As if we know exactly how long each task is going to take. Well, software development is not not like that. Not in the least. The ones that understand that - the ones that are truly "Agile" as it were - are the successful ones. The successful ones understand that any number of things can go wrong and plan accordingly.
Agile is like ITIL
By ErichTheRed
•
2015-May-14 13:28
• Score: 3
• Thread
I do systems engineering work for a professional services/software company. Development is fully Agile with a capital A, whether or not it makes sense for a particular project. On the systems side of the house, we have another particular religion called ITIL which lots of companies have jumped into with both feet. The problem with both of these concepts is that they are adhered to, almost to a comical level, even if it's painfully obvious that parts of it don't fit.
Adhering to all of ITIL, for example, is a really good way to ensure your production systems almost never change. The number of people and sheer volume of paperwork, tickets and meetings to get anything even scheduled for a change in a "true ITIL" system is beyond insane. The same goes for incident management -- we have so many single-task focused "resolver groups" that I have no idea how anyone knows how any of our systems operate end-to-end. ITIL is great for mainframe systems, safety sensitive stuff, and networks which never change.
"True Agile" and "True Waterfall" are opposite ends of the spectrum. Agile gets you very fast development, at the expense of pinning down any sort of architecture in the beginning. Waterfall often results in software you have to throw away because the requirements change out from under you. However, there are some things that require at least some discipline, both in systems and development. No systems guy would ever advocate just logging in and making random changes on a production system to see what happens. No smart developer/architect charged with writing something that underpins tons and tons of other things would advocate swapping out the core components without at least some backward compatibility thrown in. The prpblem is that "gurus" make their money selling management on these methods. In the case of both Agile and ITIL, it's a manager's dream -- everyone becomes a replaceable unit and business requests can get promoted to production in one Sprint.
Agile was always a scam.
By engineerErrant
•
2015-May-14 13:34
• Score: 3
• Thread
Why would anyone take something seriously that was created and peddled by consulting outfits at $700-per-hour bill rates? I had the misfortune of being incarcerated at Pivotal Labs for a month by a misguided boss who thought their bizarre religion was the answer to all of life's ills. Boy, was that eye-opening.
As many people rightly point out, that doesn't mean we can't pick up some new ideas from it - my company now does short daily meetings and have a chart with everyone's daily tasking on it, and those have proven very effective. But the other 99% of what the Snowbird 17 vomited forth upon our industry is empty zealotry and jingoism. It was like Scientology right in our codebases, and worked about as well. And no, for god's sake, it wasn't because we just weren't doing it well enough.
We do have shockingly dramatic quality issues in the software industry, but they will never be addressed by the next dumb-ass management fad. We need to sit down and re-think the ways that we learn to code, get serious about "Software Engineering" degrees in our colleges, and let go of fetishized code patterns as the primary unit of engineering ability. In my own experience, we know plenty enough design patterns, but almost no one understands how to exercise coding judgment in the context of a team or long-term project.
It can't fail
By swamp boy
•
2015-May-14 13:49
• Score: 3
• Thread
It can't fail cause all of the critics are doing it wrong.
You can thank "process improvement" consultancies.
By javabandit
•
2015-May-14 14:03
• Score: 3
• Thread
At its inception, the Agile manifesto was simple. Four priority/value statements and then a list of simple principles. The goal? Merely to say that delivering value to the customer, collaborating with customers, frequent delivery and feedback, and team empowerment are the way to deliver software. Focus on delivering value. Don't focus on delivering things that aren't valuable. Very simple.
Once Agile values started to become embraced and a couple of new development processes came along (SCRUM, etc), you all of a sudden had a bunch of consulting companies and community meetups appear that all but destroyed the perception of Agile. For these companies and community groups, it's all about the process. They will teach you how to "do agile". They will provide you with bodies/contractors who can "do agile". They will sell you certifications which show you "do agile". They will sell you seminars and training on how to "do agile". They will sell you software which "does agile". Agile has went from a basic set of values to becoming a fundamentalist religion.
So my statement to "Agile Process Improvement" firms is this: You are all just scammers and profiteers. You are software development Pharisees. It is amazing that you focus on profiting from creating processes, enforcing processes, teaching processes, and writing process software... for a methodology where the first value statement is "Individuals and interactions over processes and tools". Why don't you guys teach REAL agile? Why don't you teach companies how to better define value and deliver it to customers instead of selling new processes, fundamentalism, and bodies?
For the rest of you, if you want to be "Agile". Read the Agile manifesto. Create your own process that suits your team and your business. Work continuously with your customers to understand what is valuable to them. Deliver good value to them often and get their feedback. Allow your team to learn and grow and understand the needs of the customer. THAT is Agile. THAT is all you need to do.