|
Haha: no, it's not quite as whimsical as this thread!
|
|
|
|
|
Because - and I may have said this before - "Agile" is a team management process, not a software development process. When it is explicitly used as a software development process it doesn't work...but nor should it, because that is not what it is for.
Then, of course, we have airline magazine articles from the weavers of the fog like:
"Agile for distributed development teams"
"Agile for the enterprise"
etc. that just compound the madness.
|
|
|
|
|
Duncan Edwards Jones wrote: "Agile" is a team management process, not a software development process. Thank you.
It amazes me how otherwise reasonably intelligent persons think you can somehow slap on an agile process to a dev team and magically solve its woes. If your company doesn't operate in an agile manner, don't waste your time trying this.
/ravi
|
|
|
|
|
Ravi Bhavnani wrote: If your company doesn't operate in an agile manner, don't waste your time trying this. BINGO! DING! DING! DING! DING! ...
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
TheGreatAndPowerfulOz wrote: BINGO! DING! DING! DING! DING! ... Heh.
In my previous and current lives, it was the CEO who decided that we (the company as a whole) would operate in an agile fashion. We had to take the time to educate the entire workforce before this happened. I working in small early-stage companies where a large percentage of management is technically competent. As a developer, I rarely have to explain or dumb down things to management. Or beg for better hardware or tools.
/ravi
|
|
|
|
|
So, you've got waterfall development, which was intended to be a joke. You've got agile development, which, as Duncan points out, is not about development but about team management.
And this is the best, after some 60+ years of software development, that we have to offer as a methodology for software development?
Wow, that just is pathetic.
Time to write an article.
Marc
|
|
|
|
|
Why not join my "holistic synergy application development" methodology symposium and come up with the next big thing?
Like a system that works...
|
|
|
|
|
I prefer the caveman coding method, where everyone sits around a fire and codes naked, and every time someone reaches a milestone or solves a particularly nasty coding problem, he (or she) stands up and proceeds to dance around said fire singing songs of their success, while everyone else sits and drinks themselves into a stupor.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
If you let go of the nakedness and the fire (in some cases), that's exactly how certain workplaces handle software development.
|
|
|
|
|
I think that, in my experience, the best system is the solo developer or very small group - the question is how to scale that up to corporate ambition. Low impedance methodologies like "micro service architectures" help.
|
|
|
|
|
Because it's too darn slooowww!!!
|
|
|
|
|
When you have nothing, Agile does works, though so does most anything. Unfortunately, it doesn't take long for management to realize that Agile makes for lots of bureaucracy and then it turns to hell.
|
|
|
|
|
In my experience, for a large percentage of business and web development, the core tenets of the Agile Manifesto tend to work well: have end users in the loop from the beginning, and develop iteratively.
In practice, though, I've seen teams become obsessed the artifacts of Agile Methodologies®™. A lot of emphasis is often placed on doing things like writing all use cases as user stories, doing daily interrogations standups, doing one-week sprints, etc. etc. None of those are bad things per se, but for some reason dev teams and PMs become slaves to a specific process and forget about the core philisophy: start small, develop iteratively, and show your work to users frequently to make sure you're actually doing the right thing.
To pick on a specific Agile Methodology®™, I think that Scrum uses some infantile language that makes dev teams seem unprofessional and reduces their status within an organization. From experience, I know that when I worked in accounting, we often followed "Agile" principles: breaking big tasks down into smaller tasks, having acceptance criteria for tasks, having occasional 'retrospective' meetings to discuss process improvements, showing in-process work to the 'customer' (i.e. accounting manager or CFO), etc. But you'd never catch anyone in accounting sitting around talking about stories, story points, epics, sprints, or anything similar...because we'd probably be laughed at. I think dev teams only hurt themselves when using new names to describe things that already have good terms to describe them.
|
|
|
|
|
Ryan Peden wrote: I think that Scrum uses some infantile language
Something of a general pattern in many open source projects.
Marc
|
|
|
|
|
Because we HATE exercise. Show me any person that can actually sprint for 2 weeks at a time!
Hogan
|
|
|
|
|
I wonder whether really so many programmers hate agile methods. The hypes might get on everybody's nerves, including the scrum hype.
However, few people complain about discussing problems or defining requirements and acceptance criteria once in two weeks or another fixed period of time. And this is what agile methods are all about.
By the way, who says that end users are always included in the process? They might not even understand the requirements and tasks.
modified 27-Jul-16 10:07am.
|
|
|
|
|
I think it's better to just ignore it, rather than hate it. Pretend your doing it, instead of actually doing it. Nobody will know the difference as long as you hand in your work on time.
|
|
|
|
|
ed welch wrote: as long as you hand in your work on time.
With agile, you never really know when "on time" is.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Let’s Encrypt is happy to announce full support for IPv6. It would be nice if everyone else would
I am so looking forward to telling people the IPv6 address for the gateway
|
|
|
|
|
Research firm finds businesses led by lower-paid CEOs earn greater shareholder return This is my shocked face
|
|
|
|
|
Remember hearing about how Tektronix, once the top manufacturer of instrumentation, was loosing market share to HP, and the company decided the way to solve this was to pay the board more. Well how many people remember this company. Guess that did not work
|
|
|
|
|
There is something strange about that comparison graph - it shows almost exact correlation between the two lines but with an almost constant rate of expansion of the gap. I can't see what they've done wrong but there should be more noise in that chart (IMO) ?
|
|
|
|
|
Strange that the gap in their graph starts just after the Lehmann Brothers crisis of 2008...
|
|
|
|
|
Our tools will also include a cross-platform, open-source F# 4.1 compiler toolchain for .NET Framework and .NET Core, suitable for use on Linux, macOS/OS X, and Windows. The F-ing language ain't dead yet!
|
|
|
|
|
Microsoft is continuing its 'Bingification' of Office with new Bing Knowledge Graph-powered Researcher and Editor features for Word 2016, along with a new visual-cue feature for PowerPoint. It looks like you're trying to write in passive voice, would you like help with that?
That would have been funnier (or even a bit funny?) if that blurb had been written in passive voice, wouldn't it?
|
|
|
|