- 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 my frist comment to this article!
Admin
Never take a position just because you like the person interviewing you. Make sure you like the job as well.
Counter to that, think long and hard about quitting a job because you don't like your boss (or one of your colleagues) unless you really don't like the work.
Admin
I’ve taken more than one dream job, just in time to watch it be crushed by beaurocracy. It’s kind of like keeping ahead of the Nothing as is progressively destroys innovation.
Admin
@Prime Mover I would disagree on the second point - a terrible boss will ruin even the best job. (And a great boss will make dull crap bearable.)
Admin
Plus which, a terrible boss is quite likely to fire you for no other reason than that the two of you don't get along.
Not that this happened to me, of course.
I would definitely recommend looking for another job asap if you have a terrible boss and no way of moving sideways from under his (it's usually a male thing) control.
Admin
And that's why it's common to have people follow a boss when the boss quits: because reporting to a good boss is more important than reporting to a good company. (And hopefully, that good boss is good at avoiding bad companies.)
Admin
Completely agree.
Ive quit jobs because of a bad boss... some of the best decisions I ever made.
Admin
The point is, though, that people move on. It is often prudent to wait for the person you dislike to move on of their own accord.
Admin
A few things..
"Cyril's title was just "scrum master", and he technically had no management authority"
-- Scrum Manager does not EVER have management authority simply because they are in that role. The person many or may not have due to other roles. -- If you are doing Scrum, the Daily Scrum (NEVER referred to as a "daily standup") is a maximum of 15 minutes. At precisely 15 minutes it must end. Get up walk out, turn off power, lights... as Will Willis says "This round is OVER".
So many companies/teams claim do be "doing Scrum". 5 minutes usually reveals that they are in direct violation of the Scrum Guide (18 page PDF in 2019, down to 13 page for 2020). What they are doing may b better, or worse, or simply different, but (repeat this 1000 times) it is NOT Scrum.
Admin
That rarely happens. The bad boss gets in and ingratiates themselves into the company to the point where he doesn't need to move on - his needs are taken care of, usually at his (almost always his) subordinate's expense. Bad bosses don't move, they stay and often accumulate subordinates and power.
Better to leave and follow a good boss around - the bad boss doesn't leave.
Admin
Interviewed by one manager for a one-year contract position. Went to start the contract, had a completely different manager.
Hired at another place for one permanent position, showed up for the first day, I was put in a completely different position that I really wasn't qualified for.
Job #1 lasted 13 years. #2 lasted 11 months.
Admin
That sounds less like a process for more productive working and more like a cult.
Admin
I love it when people talk about agile methodologies religiously. What happened to "People before processes" in the agile manifesto>
Admin
@Darren - How much have you formally studied... The definition o Scrum is (As mentioned) a 13 page PDF. It is a framework for EMPIRICAL process control - it is not in any way a "process", it is simply some extensible guide rails that allows the teams to develop the process that works for them. For example there are 3 roles that are defined "Product Owner", "Scrum Master", "Member of Development Team".... Using these words with the meanings from the Scrum guide greatly facilitates understanding. Similar for the 5 defined Events and the 3 defined Artifacts. There is nothing that says the team can not add more events (most do), both the specifically defined events must be done to be in accordance.
Imagine you built a Car, it has every feature of a Chevy Corvette except 1 - Neglecting patents/copyrights/et.al. it would be 100% wrong to say your car IS A Corvette, simple on the one difference. (There are better analogies, but it is 5:30 AM, and my coffee has not yet kicked in.
Admin
Exactly what Darren said: it's a cult which you're only in if you've formally studied its holy writs and keep to them to the letter. Capital Letter Terms are important to the Holy Scrum; taking the extra five minutes to ensure you've understood one another completely and your customers will get a product which does what it's supposed to do, correctly and not by approximation, is not.
Admin
To be fair to both scrums and TheCPUWizard, thirteen pages of best practices is not really an awful lot to expect people to read before giving them a job title derived directly from those best practices.
I think we've got a conflict of cynicism here. You've obviously had bad experiences with management consultants who rely on goalpost-shifting and No True Scotsman to "prove" that their preferred framework is the best. I feel your pain.
My bugbear, by contrast, is managers who are allergic to actually doing the required reading and forming their own opinion, instead preferring to take an average of what their fellow managers think something means (which itself is an average of etc etc). It's the kind of attitude that leads to people getting very excited about blockchain and robotic process automation, when a modicum of technical investigation would make clear that these are not solutions to the problems most people have.
If the scrum terminology is well-defined - and it does seem to be (https://www.scrumguides.org/scrum-guide.html) - then people abusing the terminology to make their current ineptness sound sexier is like nails down a blackboard for me.
Admin
Certain conspiracy theories are well defined. And often they are outgrowths of earlier, failed, conspiracy theories.
The fact that they are well-defined is no reason to subscribe to them.
Similarly, however well-defined Scrum Methodology is (and quite frankly I don't care whether it takes thirteen pages, two paragraphs, a couple of Yoda epithets, or whatever), the well-definedness is no reason to subscribe to something that looks awfully like a degenerate cult, trying to shed the snake-skin of Extreme Programming and not really succeeding in that endeavour.
It's a matter of taste. Agile is distinctly cultish, and if you either love it or can put up with it, then Agile is the thing for you! Lots of jobs require it as part of your resume.
My taste leans more towards the "why not grow your process organically" side. But I'm not hiring, so I advise you to venture towards the software version of what I consider to be homeopathy.
My favourite Standup moment, btw, was when our Engineering QA fainted because the only room in which we could hold the standup had no ventilation and was at about 100F degrees. I can't remember whether that was before or after the THIS IS A RULE YOU MUST ONLY TAKE FIFTEEN MINUTES, but I do remember it as being an exemplary reason not to prioritise artificial unsubstantiated bull-shit ahead of, you know, people and what not.
Admin
Another interesting thing about Scrum. Yes, a Scrum Master has no managerial responsibilities. This is Well Defined.
But you'd be alarmed at how many organisations treat Scrum Masters as some sort of Manager. Quite often, a Manager without Responsibility. My wild guess is that this number is about 80% of all Agile organisations, simply because I trust the Pareto Principle more than I trust management consultants.
I don't really need to quote Stanley Baldwin, or more likely his cousin Rudyard Kipling here. But:
"Power without responsibility , the prerogative of harlot throughout the ages."
That pretty much sums up Scrum "methodology" for me.
Admin
"Best practices" and "extensible guide rails" I agree with. But Scrumm adherents then also say things like "in direct violation of the Scrum Guide" when it fails.
You're allowed to do things differently, but then when you do, you're wrong. It's why it doesn't work - it offers a base point that good teams can develop from to something that works for them, but offers bad teams the same freedom to meander off into terrible project management.
Admin
Agree, almost every place I've been at that bangs on about Scrum, Agile or whichever trendy implementation is flying around has simply cherry-picked it to suit the whims of management, to try and look like they are being responsive and goal-oriented, customer focussed etc, when really they are just short-circuiting process, hunting glory and get out of doing stuff that needs doing in favour of running up technical debt.
I don't think it matters what "methodology" you claim to use if you have good people who can organise themselves properly. If you haven't, all the buzzwords in the world won't save you.
Admin
I am pleased to report that last fall, "Scot" recommended "Harry" and me to a new gig that has been much more satisfactory. "Quinn" joined us last week, and I learned today that "Scot" himself will be joining us in a few weeks. So the dream team is reassembling! Here's hoping it works as well as we'd hoped.