Posted on 04/18/2017 5:19:37 AM PDT by Mechanicos
Agility is a good thing, no doubt, and the Agile Manifesto isn’t unreasonable. Compared to a straw-man practice called “Waterfall”, Agile is notably superior. Yet, so much of Agile as-practiced is deeply harmful, and I don’t really think that the Agile/Waterfall dichotomy is useful in the first place.
There’s a variety of Agile, called Scrum, that I’ve seen actually kill a company. By “kill”, I don’t mean “the culture wasn’t as good afterward”. Rather, I mean that its stock dropped by almost 90 percent in less than two years.
(Excerpt) Read more at michaelochurch.wordpress.com ...
This is not me. It was shown to me and I found it interesting from a management perspective.
But don’t you love it when they call a ‘bug report’ a ‘user story’?
It sounds so cute! We’re telling a story...
(pet peave of mine- I hate that name)
Every 7 years of so someone comes up with a blinding flash of the obvious and ‘invents’ a whole new way of doing exactly what I’ve been doing in software development for 25 years.
I believe this stuff is snake oil. I’ve known A LOT of consultants who swear by these things. There is money to be made by showing PowerPoint slide decks of theory and vocabulary and process. Actually doing real work? That’s someone else’s problem.
That being said, IT management is always a challenge. With the right people, in the right environment, all kinds of approaches can work. Agile and Scrum undoubtedly have some success stories. But as a “one size fits all” solution, I think they fail. Most enterprises will not succeed with these methodologies.
But the consultants will make money. And that’s really all that matters.
Agile is no different than any other methodology. It’s very effective if done well. It’s a bloody disaster if done poorly.
1. There are no magic bullets, but
2. That doesn't stop IT management from trying them out anyway.
You have to apply the fundamentals across the board and work with sound requirements. There is no getting around that. The mantra "Cheap. Fast. Good. Choose two." holds to this day.
This is a highly softened version of his original article.
Tagging this for a later read... Verizon has been all in on Agile for a few years. I’m in a technical app/infrastructure production support role and don’t have enough hours in the week to complete all the items on my plate, so frankly most of detailed info from the classes they put us all through has vaporized from memory :). Of course that’s not the case for the managers and PM’s.
Great article for those of us in IT, thanks.
Technologies change so fast that the average IT manager is, within a few years, completely unfamiliar with the tools his programmers are using and has no real idea what his employees actually do. From that point until the end of his career, he is just winging it. He waves his hands around, points at slides, and repeats things he read in a trade magazine.
I disagree. I had a small software company for 17 years and, while I didn't call it that, I used this technique very well. Because I had less than a dozen programmers, they were divided into 2 or 3 person teams. Each team was given a project, usually with a two or three week time horizon.
Fridays were code walk-throughs, where everyone met to review the team's project. If the team passed the code review, the company bought pizza for lunch and everyone got the rest of the day off.
I found several benefits from this:
1. Everyone in the company had some idea of what was going on in terms of development. That made it easier for someone to jump in if another worker was on vacation, was ill, or needed personal leave.
2. It fostered a camaraderie that "we're all in this together". I can't tell you how many times I was in the office at 8PM Thursday night only to find most of the other programmers helping the team that had the code review the next day. I think the company came out far ahead because of the esprit d'corps that resulted from this.
While this approach probably reaches a critical mass and can't work in large companies, the author's blanket statement that short timelines don't work is simply wrong.
A blast from the past - https://en.wikipedia.org/wiki/The_Mythical_Man-Month
It’s one thing to use Agile in the development phase, but if the requirements gathering and project scoping phases are still waterfall, it doesn’t make much difference.
It goes even deeper than that. For example, too many companies (mine included) keep attempting outsourcing despite past failures at attempting such. I have a mantra - mistakes are expensive - learn from them. But a new executive comes on board and believes he/she is smarter than the last one, and the last attempt failed due to poor execution, rather than being a bad idea in the first place.
Bookmark.
Oh, I thought this was a rugby thread...........................
When an article starts off with lingo that us ordinary commoners can’t make sense if, I choose not to go further
Agile, Scrum, and other methodologies can work well if they are done honestly and managed at the optimal level. Why they ever fail is because of many reasons such as this:
1. Dishonesty - ignoring technical debt, pretending that non-functional requirements don’t need to be considered, ignoring needs of employees (i.e. PTO, training, career development, etc), ignoring scope creep, failure to accept that you can’t have all 3 (i.e. faster, cheaper, better), etc.
2. Ignoring the big picture - 2 week Sprints only make good sense if you are effectively communicating that these are just steps in the big picture of months, quarters, and years. If you aren’t communicating a good 2 + year vision map that your development/product teams are working on then you will pay dearly.
3. Micromanaging - let the process work itself out and the teams will flesh themselves out where most will become highly productive. The process already has built-in a means to interject urgent high priorities into Sprints without hindering team velocity/productivity.
4. Not enough ROI - Doing some up front high level math on expected return on investment is crucial in the software industry. If a corporation sees an opportunity to create tremendous enterprise value by expanding/improving their software products then they should do some basic high level ROI analysis on whatever they plan to spend. I’d suggest that a 5x target is needed where they start off saying “what are the A, B, C, D, E, and F values/benefits that we hope to accomplish by maintaining & expanding our software/products the next 2 years” and then put a realistic total dollar number on the projected difference in total value. Then set an annual budget of approx 10% of this for your product/software maintenance/development budget. These estimates of value vs. cost will need to be regularly revisited/analyzed by the project managers and business analysts to keep the teams focused on the highest value propositions and change according to the changing industry/economy landscape. But as long as the need is very well demonstrated then the profits will be there and the quality/morale will follow suit. If the value isn’t there then yes it’ll come crashing down.
5. The devil is always in the details. Ignore the details at your own peril.
Open concept office, Agile crap and massive influx of Indian and Chinese engineers with limited English proficiency. I had to deal with all this crap at my last job. The company really went downhill after they started this.
Curious, how good were the requirements? Not just quantity but quality. By quality, I mean the success rate of being clearly understood (how they’re communicated).
This, in my opinion, is the number one reason of failure - poorly defined and poorly communicated requirements. I’ve done Agile and Waterfall, each having success - but ONLY when we all knew what the result was supposed to be.
...that said, I do find daily stand-ups to be mostly pointless. Weekly is more appropriate.
Bfl
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.