- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
This is not the frist time I have seen this
Admin
It's not worth having ideas unless you can convince the management it was their idea.
Admin
Takes a lot of agility to dance wearing concrete overshoes.
Admin
I worked for a place that wanted to do the Agile thing. They implemented a 16 step process involving meetings, documents, and approvals galore. The last step in the process was "then develop software".
Admin
Always funny seeing people completely misunderstand Agile. I mean it's already a bunch of garbage peddled by consultants, but has at least some good ideas. Too many people just slavishly follow it because "Agile book say this good" without understanding, and more still want to play Agile as no requirements and releases every 3 weeks but not have anything else that actually enables Agile to work.
Admin
The worst implementations are always those companies that have heard of agile, that want to be agile, but they pick and choose only the bits they like the sound of and then shoehorn them into their existing structure. Agile supposedly only works if it's all-or-nothing. Thus far, I have worked for 3 companies that claim to be "agile", and when hearing about it in interview, I still have the same response: "I know about agile methodologies, but I have yet to see it implemetned successfully..."
Admin
Been there, done that. I once worked for a mega-corp that did this exact same thing - one day they just up and declared Thou Shalt Be Agile. But Agile by itself wasn't nearly enterprisey enough, no we had to be SAFE (Scaled Agile Framework), some kind of bizarre scrum on top of scrum thing where your individual team sprints were rolled up into a longer overall department sprint that ran on the schedule of the Release Train. And when that train left the station, your stories had better be on it or you'd get run over. Seeing as how I was on the customer support team at the time, when hair-on-fire tickets would frequently preempt whatever the established sprint priorities were, my team was in constant conflict with the scrum overlords.
Between that and some other changes, it wasn't long until what was once a high-quality team started rapidly eroding away.
Admin
This kind of 'to be agile you must slavishly follow this defined process' is too common, I think. Management seems to think it has a right to get deeply involved in engineering, even though it doesn't understand it, and it's a tricky balance once you're big enough to need project management and people to manage external stakeholders as well as engineering teams - if you're not careful the customer talks to the non-technical BA and he then talks to the engineers, and things get lost in translation, but the engineers don't have time or aren't allowed to talk to the stakeholders directly so no-one actually gets what they want, and all the flexibility of agile is lost because the BA doesn't want to have to continually re-evaluate requirements based on feedback.
My company does have a little bit of this problem.
Admin
#iminthispictureandidontlikeit So I passed the link for this article to pals in my company. If I'm never heard from again you'll know why.
Admin
My rule is always "Have you done it before?"
Agile: Delivery in two weeks no matter what, get the one most important feature done first.
Why management exists? Compliance: simplify trade between two very different nations which may be hostile Security: the job is really for the military or police! Competition: the world is not your friend and wants you to fail Politics: the job got someone in power or ended conflict Social: one person may often fail. The millennia old institution which provided the college degree never fails. They will get their money back one way or another.
Admin
"... and then estimate those User Stories as taking a certain number of hours."
And I'm sure it will always be 100% accurate.
Admin
I once worked for a small company that decided to adopt an Agile Process (TM). The product managers would gather requirements from customers (whom the developers would never talk to). Then the product manager would write user stories and allocate them to two-week sprints (in which the developers had no input.). The role of the developers was to dutifully code the user stories every two weeks.
In my first project under the new process, I was the only developer. I was writing a web application for the customer to enter data into our digestion system. The first sprint was to create a user management system that allowed the customer to create users and set their level of access (read, write, admin). I wrote what the story dictated. I heard back from our QA folk (who were allowed to talk to the customer) that the customer was mystified. There would only ever be one user of the system, and the user management piece was a complete waste of two weeks.
I found another job two weeks later. I assume someone else finished the project.
Admin
The original Agile (the hilariously bad Xtreme Programming) was explicitly corporate. But people liked the general idea (because waterfall is hell), so then various versions which sucked less and were less corporate were formulated from procedures that actually worked for good teams. Then the consultants got it and industrialized it. And this is now what people think of as Agile, usually scrum. So when Big Stupid Corporations look longingly at 'Agile', think it will fix all their problems, and then implement it terribly so they keep all their problems ( 'the problems were us all along!' ) it's kind of just coming home.
Admin
To be fair, much of this isn't specific to Agile; ANY time "you must slavishly follow this defined process" is going to be trouble, whether it's a flavour of waterfall, agile, or any other methodology that's handed down from above. (Hint: the word 'methodology' is a bad sign...)
On the other hand, most of those have SOME good ideas, and if a team is allowed to select and adapt the techniques and tools which work for them, they can usually do well whatever 'process' might be in fashion. The important thing is simply to have good people who care both about their product and about their users, and can get on with it without too much interference.
Admin
Not in my bitter experience. Being part of a team that delivers the right solution quickly and without the need to add two people to the helpdesk to keep up with all the new calls is pretty much the best way for a development gang to paint a target on their back.
You can only do it by streamlining the "processes" and avoiding those pointless long meetings with armies of project managers, BAs and department heads who have little or no knowledge of your project but will absolutely bloat and pervert it to uselessness to prove a political point.
Proving they are not needed (in fact, proving they don't add value) is a threat to their existence. While you lot are merrily enjoying the next project and bathing in whatever nice memo and treats got showered on you, that lot will devote their energies to cooking up some sort of "restructuring" to stamp out the mavericks.
Admin
My story is very similar to this one, except after 13 years of successfully delivering the highest-value digital program in the mega corporation, and doing it from outside of the IT department, the head of IT eventually couldn't take it any more. They commissioned a false report from a third party company (a tiny company who mostly writes excel programs) to 'review' my enterprise codebase (having more lines of code than the Win95 OS) without being given any information about the scope of the software, the age of it, or anything else, yet somehow wrote a 8-page slander about how horrible our code is. Statements like 'there are too many projects' (oh? how many is the right number?), 'milestones are constantly missed' (how does one determine that from code??? oh, and which milestones were missed? no details were provided of course), and many more inflammatory and false accusations that were not backed up by any data because, of course, they couldn't be. It was the most amazing thing I have seen, and even more amazing, the heads of the business units believed it. Why? because they didn't read past the first line which essentially said that the code was so bad, it is unmanageable and would cost so much to manage that it would be cheaper to replace. That's all they needed to hear. Within the next 6 months, I was forced to transfer my high-performing team to the IT department where we lost all of our processes and integrated devOps systems all in the name of 'compliance'. Not surprisingly developers started leaving the team, even though they all loved their work and had been with me for over 10 years. Oh, and to top it all off, now I get to lead the project that is supposed to replace my previous system.
Admin
I and every other person in IT was sent by the company for Scrum training at great expense, leading to hundreds of newly-minted scrum managers and a complete agile SDLC backed *even mandated) by the CIO. It cost them a fortune.
What actually happened was the middle management would decide what was going to be done next, and how long it would take, and this was then dumped onto the nearest team, who then had to complete the work in the indicated time-box, while also holding daily scrum meetings and updating the burn-down diagrams so that steady progress was indicated.
Every aspect of Scrum or Agile that might have made the slightest positive change was rejected and pretty much the only thing kept was two or four week sprints, which were now all the time we would be given to complete whatever changes or features we we told to do.