Slashdot Asks: Is Scrum Still Relevant? (opensource.com) 371
An anonymous reader writes: In an article titled "Scrum is dead: breaking down the new open development method," Ahmad Nassri writes: "Among the most 'oversold as a cure' methodologies introduced to business development teams today is Scrum, which is one of several agile approaches to software development and introduced as a way to streamline the process. Scrum has become something of an intractable method, complete with its own holy text, the Manifesto for Agile Software Development , and daily devotions (a.k.a., Scrum meetings). Although Scrum may have made more sense when it was being developed in the early '90s, much has changed over the years. Startups and businesses have work forces spread over many countries and time zones, making sharing offices more difficult for employees. As our workforce world evolves, our software development methods should evolve, too." What do you think? Is Scrum still a viable approach to software development, or is it time to make way for a different process?
In my office... (Score:5, Funny)
... we develop software the old-fashioned way: incremental improvements to an ancient codebase with fundamental flaws in its core that nobody's brave enough to tackle, with irregularly-scheduled releases set into the production server without automated unit testing.
At home I develop in a more refined fashion: diving right in without much prep or research, working on it for weeks to months, then finding that the project is 100 times more complex than I expected and someone else has already done it.
Re: (Score:2)
Scrum will neither fix nor cause the problems of an aging, poorly-maintained, ill-documented code base. It makes no statements about what you do when you're handed something like that. Only you (and your budgets) can decide whether to wipe it out and start again, or have a program of continuous cleanup, or decide to patch problems as they arrive and build onion-like layers of code to hide the inner ikkiness. But, once you've consciously chosen a path, scrum can help you predict and measure progress - whe
Re:In my office... (Score:5, Insightful)
This is the main reason people hate scrum - the awful boredom and lack of humor in it's promoters. You take a great joke, let it woosh over your head, suck the life out of it and think you''ve added to the debate. Here's a hint - you haven't.
Re: (Score:2)
At home I develop in a more refined fashion: diving right in without much prep or research, working on it for weeks to months, then finding that the project is 100 times more complex than I expected and someone else has already done it.
Lol, I'm gonna print that out and frame it. :)
Re: (Score:2)
This reminds me of an old advertisement from the 70's, from an investment house named Smith Barney: the aristocratic actor John Houseman announced:
"At Smith Barney, we make money the old fashioned way . . . we earn it!"
In these Halcyon days of Internet bubbles and fortunes, it seems even more poignant.
Re: (Score:2)
and here I thought they did it by having a very extensive and expensive schedule of fees.
Re: (Score:2)
Shh... Don't run the illusion of the "good old days", where bankers were supposedly honest and not motivated screwing over their customers for profit.
Re: (Score:2)
OMG, I think you're in the cubicle next to me!
Silicon Valley Did It Best (Score:5, Interesting)
https://www.youtube.com/watch?v=oyVksFviJVE [youtube.com]
Watched this with my wife, who, while also in tech, never worked at a workplace that used Scrum. She cracked up and thought it was the funniest thing she'd ever seen. I sat next to her, stone-cold silent. She asked why I wasn't laughing, and I said, "Dude, that's MY LIFE." All that's needed to parody Scrum is... an accurate description of Scrum.
Of course, in that episode was that Scrum actually worked for them (it probably helped that all the devs worked in the same office)
Scrum? (Score:2)
First thought: what the hell does a Lucas Arts interpreter have to do with s/w development methods?
Recent Scrum project failed (Score:3)
Obligatory Betteridge's Law reference (Score:5, Insightful)
Scrum works best when you break it and make it yours. As with ANY methodology, do not allow process to interfere with progress.
Re: (Score:2)
Thirty people is way too large for a scrum team. You'd be better off with five six-person teams and therefore five six-minute meetings. Or maybe six five-minute meetings for six five-person teams. No team of thirty people is going to grab tasks off the board without contention and be as focused as a smaller team.
Re: (Score:2)
We used a cork-board and index cards. We ran scrum for 8 years with an initial start-up cost of $20. We didn't ditch that until we switched to TFS.
yes (Score:4, Interesting)
When done properly it is fantastic (Score:4, Insightful)
When done right, scrum is fantastic methodology. I know this from my own experience. However, I have not see many teams master it. They usually cut corners, or "adapt" it to their own preconceptions that end up breaking the process. They often don't do the retrospective meeting, or do it improperly so they are not able to get better at it, and get stuck carrying over user stories iteration after iteration.
I don't think scrum and open development have a lot of overlap. They are each suitable for different types of projects. Open development works great for open source projects that a lot of people would have interest on. Scrum works great in small teams developing for particular verticals within a company that would have limited application outside.
Things can always be improved of course, I would not say scrum is the ultimate methodology, but it is a pretty darn good one, and we are yet to see better ones.
Re:When done properly it is fantastic (Score:5, Informative)
I'm still a fan of scrum. I love that it gives the engineer the final word on schedule. No more "You have three weeks to do X."...now it's "How long will it take?"...and the truly awesome part is that it gives lazy team members no place to hide - and gives the team the incentive to meet the deadlines they imposed upon themselves - or have a damned good reason why they didn't.
I agree - in the last couple of jobs I've had that did scrum well - it really helped. I think it can be adapted to fit individual team's needs - but the huge mistake most people make is to start off by adapting it. My advice - jump in with both feet, use the standard scrum methodology - and after you've been doing it for several sprints, decide where you want to dial it back, amp it up or modify as needed. For example, in my previous job, planning poker worked really well - it was a way for the team to look at stories and say "I think you've missed a shortcut that would save you some time"....or...."I think you're missing a potential problem *here*.". But in my current job, the team is full of specialists in different fields - and that cross-pollination doesn't happen - so planning poker just doesn't work.
The point here is - try the whole thing - THEN customize as needed.
Re: (Score:2)
What magical place do you work at? I've worked for three companies that claim to do SCRUM and developers have less say than anywhere else I've worked. These companies still back into their schedule and shoe-horn it all into two week increments.
If you are doing scrum properly, the team of _developers_ decide via poker planning how hard a particular feature (user story) will be to develop. They should size all the user stories.
The product owner gets to decide which ones are more important and should be developed first (with input from development team), leaving the least important user stories last, in case there is no time to get to them.
Under scrum, the product owner can say: I want to deploy in 3 months, that is fine and the team should s
Prone to promise too much (Score:5, Interesting)
While scrum could be effective to prioritize a lot of small tasks that can be complete in a few hours, we found it useless in situation where a long task must be developed. In the later case the peoples try to say the minimum because there are afraid of hitting unexpected difficulties that will slow there work, and scrum is not a place to change the design, so there feel like in a trap.
Re: (Score:3)
Re: (Score:2)
I agree. The reality is that not all tasks can be easily break down into smaller task before starting the development. An example is porting and integrating a existing code on a new platform. The only way to get the relevant information is to start working on it.
Re: Prone to promise too much (Score:2)
So you have a planning task to get in there and figure out what tasks need to be done. That's exactly what I'm doing right now in s major upgrade project. The rest of the sprint my time me is filled with research and planning tasks and the outcome will be a huge suite of epics and user stories mapping out dependencies that will fill several sprints for my team.
The request was "upgrade the platform to version X" and my planning task means we now have several months of work mapped out that can be rebalanced a
Re: (Score:2)
Our 'planning task' took a dozen programmers 4 months staring at and experimenting with the codebase before we even knew enough to start splitting the work into tasks. Even then we had things that obviously couldn't be guesstimated with any sort of accuracy or split into small parallel workflows with any hope of measuring progress.
Some projects are just so fscked the only method that works is hitting them with the sharpest sticks you can find till they give up.
Re:Prone to promise too much (Score:4, Funny)
Scrum has no long tasks. The very first and most fundamental step in Scum, or any agile process really, is to break down long tasks into smaller tasks.
"Okay, you type the first 5 letters, Bob, then Steve will finish the name of the function call. Jack and Nick will add the parentheses and semi-colons. Mary will press the RETURN key when it's time for a new line. Okay team, GO!!"
Re: (Score:2)
That's not a failing of scrum, that's a failing of the team. If those are mission critical steps, the very first thing that should have been done is write a spike card or cards to find ways to break that down to digestible components.
If you find yourself in that spot again, start asking around for help outside of the company. Writing spikes and then figuring out how to spawn stories off of that isn't always intuitive. But a lot of times just getting an outside set of eyes on the problem does a lot to hel
Scrum tells me what jobs to stay away from (Score:2, Funny)
If i wanted a devotion meeting I'd join alcohoolics anonymous thank you.
Horses for courses (Score:4, Insightful)
Imho, the biggest "flaw" with agile development, is that it is - if not selling itself, seen as by many as - being everything to everyone. You can take a bit of this or leave a bit of that, but this is the right way of doing things. And it all gets wrapped up in terminology (agile, velocity, etc.), that suggest that the process will be faster and better.
But different processes have different strengths and weaknesses. Sometimes it's more important to put in design effort upfront. Sometimes it's most important to make the most efficient use of resources (e.g. not wasting time doing things based on a narrow requirement knowing that you'll need to change it later), sometimes it's important to be able to adapt to changes, and knowingly change requirements based on feedback. Agile methodologies only really address the last one.
The best results will come from understanding what the project needs, and choosing the methodology that best addresses that, not from always trying to fit one methodology to every project.
Re: (Score:2)
Agile's biggest problem is that it is bloated. It tried (tokenly) to be this lean development methodology but it keeps getting burdened with more and more cruft. Same problem every time: some company nobody has ever heard of announces that by forcing all developers to speak only in haikus during scrums, they increased productivity by 12.86%. Now every company feels the need to adopt that. A year and several increasingly-bullshit announcements later, we all have to have scrums from 9:18-9:33am Eastern Martia
Re: (Score:2)
Hmm. Forced haiku. I like it. I like it a lot - brb, off to change a meeting invite..
Re: (Score:3)
I hate to pull "No True Agile", but a methodology that puts process above people and working code doesn't live up to the Agile Manifesto. (Hmmm. Agile Manifesto is six syllables, and therefore has to go in the middle line of the haiku. This will be tricky.)
- Black Davidbeard
Advanced /. Writing (Score:2)
We know you don't read TFA anyway. So really, why bother linking to it at all?
(For those of you who "are new here" and actually want to read it, the article is available here on OpenSource.com [opensource.com]
All engineering is iterative (Score:2)
All engineering is iterative in nature. If Scrum is dead (read as iterative, incremental development), then software engineering is a myth.
What do you think? (Score:2)
"What do you think? Is Scrum still a viable approach to software development, or is it time to make way for a different process?"
NO.
It's definitely time to come up with a new, trendy name that hides the fact that most programming is, in fact, a solitary sport, even if done by teams of coders all stuffed into a common room.
I propose "SUCK", "BALLDROP", "HOPELESS", and "VOID" because none of them stand for anything and they all sound cool when uttered in between slurps of brogrammer's favorite energy drinks.
The hype is over. Scrum remains. It works. (Score:3)
We're using Scrum. One of the many variants of it.
A simplified version of scrum suitable for agency work.
Simply getting around a board, away from the keyboard, standing, talking (timeboxed) writing cards and moving them around makes things better and enhances team communication and interaction.
That the overblown hype and overengineering and the holy wars about how scrum is to be done is over is a very good thing.
Hype ends, Scrum remains.
I think it's a very good think that this was a big fasionable thing and that Agile (sometimes contradictory to Scrum btw.) brought back the focus on results and regular customer interaction.
Re: (Score:2)
We're using Scrum. One of the many variants of it. A simplified version of scrum suitable for agency work. Simply getting around a board, away from the keyboard, standing, talking (timeboxed) writing cards and moving them around makes things better and enhances team communication and interaction.
That the overblown hype and overengineering and the holy wars about how scrum is to be done is over is a very good thing. Hype ends, Scrum remains. I think it's a very good think that this was a big fasionable thing and that Agile (sometimes contradictory to Scrum btw.) brought back the focus on results and regular customer interaction.
I've never actually worked with a team that has done scrum properly. It's usually poorly managed and a waste of time.
Re: (Score:2)
According to Sturgeon, 90% of all software teams are crap whether or not they use any particular methodology.
Scrum is fine in theory (Score:5, Interesting)
The core principles are fine:
1) Frequent communication means nobody drifts too far out of scope
2) Breaking a large problem into small problems is something you should have learned before you even started university
3) Gives nervous business stakeholders an insight into the development process
But it doesn't work in most settings for these reasons:
A) The broader business doesn't engage (becomes sprints within waterfall)
B) The engineering organisation doesn't engage (usually because they don't feel they own it)
C) It's too complicated - it's the core principles that matter, not rote adherence or form filling
Too many moving parts; too many new concepts; too many new ways of doing things; for too many people; who aren't necessarily interested and/or sufficiently trained and informed.
You CAN make Scrum work - if and only if - everybody gets on board and you take a large hit up front while everybody adjusts to the transition.
Most businesses can't and won't do this.
Re: (Score:2)
Definitely A.
If your testers, upper management, and customers arn't on board, you end up with exactly what you said.
Personally I think scrum works if you arn't religious about it. Take the bits that work, introduce it slowly, don't get hung up on the "proper" way of doing something. As you said, the core principles are sound, and I'll add that a lot of the management tools built around scrum are pretty decent. Building often makes sense, testing incrementally makes sense, letting the customer see things ear
ATTD (Score:4, Informative)
The developers here changed from Scrum to ATDD (Acceptance Test-Driven Development). Throughput it up, quality is up, morale is up...
They also ran a couple of tests, with one group solving problems using Scrum and another using ATDD. ATDD won every time (although in some cases just barely).
Just sayin'
Re: (Score:2)
No sprints.
Are we playing rugby (Score:2)
Union or League?
Scrum is for Management, too (Score:2)
I've been at two companies in the last six years that are trying to implement Scrum. The first failed miserably, due to massive management interference. The second is in progress now, and seems destined to fail (although I certainly hope not!). This company promotes hyper-active micro-managers, who operate in a mode that is the antithesis of Scrum.
In both these cases, I see the biggest benefit of scrum is that it would prevent the micro-managers from interfering with development that is in-progress, and
Misleading title is misleading? (Score:2)
Re: (Score:2)
It's a question. Not an answer.
My rule... (Score:2)
Once anything as trivial as a type of meeting or process gets hyped to the point of being capitalized as a proper noun, it's screwed.
No matter how well intended and thought out the underlying principle, once it gets 'adopted' it will bear no resemblance to the vision that it was created with.
If something is more concrete, specific, and is in no way able to be 'interpreted', it has a chance, but words like Scrum, Agile, Epics, et al are screwed.
Of course its still relevant (Score:2)
It's still better than nothing. (Score:2)
Read my title. Says it all.
You want process in software development, you start with industry standard, and that's still Scrum. Unless your project only has 10x programmers (who will get a sprint's worth of features done in a day no matter what). For those types, the better process will always be no process at all. That's the magic behind the genius: nobody understands it, it Just Works. And so does Scrum for the rest of the world.
The problem with agile is the name (Score:2)
can't resist (Score:5, Funny)
Can't resist pointing out that, despite its stated objective,Scrum usually makes things take longer, not shorter. That means working Overtime, known as "OT" . Thus:
ScrOTum
Re:Scrum Was Never Alive (Score:5, Informative)
I can see where it might be useful in certain situations. However, when it gets used with other Agile fluff to simply produce a dirty snowball of design layers with no overall architecture produced, then it becomes a headless snake. It also tends to get misused by management who see it as a way to micro-manage developers thereby pissing off the very developers upon whom they are depending.
Re: (Score:3, Interesting)
This really sums up my experience with scrum meetings..
Re:Scrum Was Never Alive (Score:4, Insightful)
Re: (Score:3, Insightful)
I always enjoyed the conversations
Manager: "honestly, how long will this take"
Dev: "I imagine 2-3 days"
Manager: "WHAT NO WAY, if I could program I could do it in a few hours"
Dev: "Yes, but there are some unknowns I need to research, I said "I imagine", it could be less it could be more"
Manager: ARE YOU FUCKING WITH ME, this scrum thing was meant to get you to work quicker and harder with less bugs, now you are telling me you need 2-3 days for this little feature
Dev: Honest yes, remember you have me doing su
Re: (Score:2, Insightful)
Pretty much sounds like my boss. "We can't sit around waiting for it to get to 100% right, get it to 80% and push it and move on to the next thing"
Seems like I never pick the right 80% to do.
Re: (Score:2)
Miscommunication. You should have told him you can make a working prototype in a day, but it will require a *lot* of trade-offs, will be of low quality, and will need following-up to shape it into something actually reasonable. If he needs a crutch to lean on for 4 or 5 days while you deliver a viable product, you can get him that; but you can't get a finished product in one day.
Communication is the responsibility of the sender.
Re: Scrum Was Never Alive (Score:3)
I could not say it better myself.... being able to correctly express yourself (and timeframes) is the true gist of all these agile develoment models. I often say that there are a thousand ways to say the same thing, and how you say it (notice it is not what you say, since you are delivering the same information) is greatly dependant upon the listener. This is no different. Unfortunately, interpersonal communication is so nuanced that it is so much more than a language barrier, and unfortunately, so many
Re:Scrum Was Never Alive (Score:5, Insightful)
That's called a Project Manager, and a decent one is worth having.
You can't beat face to face communication, especially between developers and subject matter experts. The productivity gains and risk reduction far outweigh the cheap-warm-bodies offshore. Design is never efficiently replaced by brute force.
Re: (Score:3, Insightful)
Hmmmm - Project Manager is a very broad and loaded term. Many professional project managers wouldn't consider themselves Scrum masters and vice versa. In particular, the role of a project manager is specifically to push timelines, but in Scrum the role of the Scrum master is to guide the process - timelines are owned by the product owner. The distinction is subtle but important enough that it matters.
Cheap warm bodies off-shore are a reality of business these days. You just cant produce the volume of conten
Re: (Score:2)
The official role of a project manager is specifically to guide the process of completing a project. The project manager's job is called "integration", and it involves integrating scope management, time management, budget management, quality assurance, human resources management, communications management, risk management, and stakeholder management into a complete process to ensure the measurable success of a project.
CAPM license #1870244 held in good standing.
Re: (Score:2)
Re:Scrum Was Never Alive (Score:4, Interesting)
Functional (run by department heads), matrix (weak matrix, balanced matrix, strong matrix), and projectized.
In weak-matrix organizations, the project manager is often a facilitator. Balanced-matrix departments start defining the project manager's level of authority, giving him the explicit right to requisition resources under the sponsor's authority: your VP of Engineering gives you the authority to requisition 4 engineers for 16 hours per week from the Engineering departments under him, to communicate with other departments to gather requirements and interface with stakeholders, and to spend money within a given budget, all tied to the scope of the project.
The project manager's job still remains the same in all cases: find the most efficient way to plan and execute the project. If he has no power, he has to take it back to department heads and VPs--to the sponsor--to lay out recommendations for action. That includes who to hire, what to buy, how to schedule, and so forth. The decisions are ultimately made by whoever has the vested authority to make them, which may not be the PM.
This should be obvious, considering "push deadlines" is a meaningless phrase essentially expressing "I don't know what I'm talking about".
Re:Scrum Was Never Alive (Score:5, Interesting)
I personally found Scrum and Kanban annoying in this respect:
1: The meeting to tell your "stories" is a time-waster when done more than once a week. Daily, it is pointless.
2: The "what you did" scenario. It becomes listing everything, relevant, or non, so your manager doesn't think you are slacking, and pits you against other developers or IT people.
3: The "what you are going to do today" crap. SSDD is the proper answer for that.
4: The "what is blocking". This translates to "point the finger." As a dev, I learned the hard way that "blocking" means a game of "hot potato" where if you or your code can, in -any- way be used as an excuse for others to not do their work, expect to be training a H-1B fresh off the boat to take your job soon. The "blocking" phase turns into a "The Apprentice" boardroom meeting right before someone gets tossed.
As for code quality, look at the garbage coming out on average. People thought waterfall coding was bad... but code quality when that was the main method was, in general, far better than the Scrum based systems, just because Scrum mainly is used to pit devs against each other, as opposed to actually creating something.
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
I don't mind "daily meetings" with people on my own team (2-4 people). We do them, but we don't call them meetings. It's just us sitting and talking.
If the group is larger than that, then there is likely a high noise to signal ratio on them saying anything I would ever need, and it would be more useful to not sit and listen to it because if I ever need the answer, I would likely go to them and ask directly. So overall stuff, like bi-weekly meetings may be useful but anything more common than that is use
Re: (Score:3)
Re: (Score:2)
Scrum can work if the team actually works together. A 'blocker' can be nothing but a statement of fact - this can't get done until that is in place. It sounds like you've got an organization that worries more about politics and individual success than actually shipping.
Literally anything can work if the team actually works together. The question here is more "does scrum lend itself to fingerpointing and politics in an imperfect team more than comparable methodologies".
Re:Scrum Was Never Alive (Score:4, Insightful)
The biggest problem is that many larger corporations have trouble implementing true agile development. It isn't because IT doesn't want to do it.....it's business partners or management or accounting or what have you. So in those instances, agile turns into some hybrid of waterfall and SCRUM that isn't as effective as it could be
Re: Scrum Was Never Alive (Score:5, Insightful)
It's sad how quickly the No True Agile fallacy rears its head in any /. thread that points out how fragile and limited the methodology is.
Re: (Score:2)
I never said there was No True Agile. I said in larger companies (subset of the whole) and I said many, not all (another subset). I've seen plenty of examples of Agile working really well. But that's always been in smaller shops where the organization doesn't have the monolithic ingrained culture that makes it hard to do Agile.
In larger companies, I've seen:
Business partners who don't think owning the backlog is their job.
Marketing who continue to over-promise on features and/or delivery dates in spite o
Re: Scrum Was Never Alive (Score:5, Insightful)
It is fragile, and it is limited. That doesn't mean it can't be successfully used to add value.
The issue is people doing it badly then blaming the methodology, not their shite implementation of it. Any fucking methodology is going to collapse when faced with the average programmer - see also: IT project success rates
Re: (Score:2)
Re:Scrum Was Never Alive (Score:5, Interesting)
Scrum is fine, but let's not pretend it's some kind of miracle.
Re: (Score:2)
Scrum is really tremendous for small teams that never had a methodology before.
Re: (Score:2)
Re: (Score:2, Interesting)
a dirty snowball of design layers with no overall architecture produced
That is absolutely required by Agile. Agile demands that if something takes more than one Sprint that you must not do it. Any big architecture problem that takes more than one Sprint cannot be done with Agile. I was fired from my last job for taking sixteen days to finish a JIRA issue. I almost got it done and out of QA in time. In our Sprint planning meeting, we scored it as a forty and used twenty as the basis for a Sprint. Even though the issue had to be completed in order to deliver to a customer,
Re:Scrum Was Never Alive (Score:4, Informative)
That is absolutely required by Agile. Agile demands that if something takes more than one Sprint that you must not do it. Any big architecture problem that takes more than one Sprint cannot be done with Agile.
I am by no means an agile expert or advocate but I'm pretty sure agile doesn't say "No work item that would take longer than one sprint can be worked on", rather I think the idea is that any work item that would take longer than one sprint should be broken down into several smaller and more manageable work items.
Re: (Score:2)
"Flexible" and "agile" used to mean very similar things. I think in the real world they still may.
Re: (Score:3)
For people that do strict Agile that means nothing can be worked on unless you can verify it in the UI.
Now there's some utter bullshit. I've successfully used an agile methodology to deliver a server application that had no UI beyond basic log files and working downstream systems.
For us, it means we can't work on problems that cause bad data that isn't exposed in the UI.
Of course you can. You're inventing weird difficulties without trying to resolve them. Sounds like work avoidance to me.
Re: (Score:3)
Waterfall actually works for tasks that are completely defined and which will not have changing requirements. The farther you get from that, the more problems you'll have. Agile does better on changing requirements, but, to be honest, if the requirements change too fast or too much the project's doomed anyway.
Re: (Score:3)
Any big architecture problem that takes more than one Sprint cannot be done with Agile. ...
Agile cannot produce good software since by definition you can't do anything that takes longer than a Sprint.
This is untrue. You create epics, which capture your big architectural issues, which lead to a series of stories for implementation over many sprints.
(My caveat about all SW methodologies - any devotion to a doctrine is a heresy. Methodologies are but tools to help organize work, and must be customized to match the environment in which is used. Organizations vary with size, requirements dynamism, team skill level, quality of management support, etc., etc. and no list of manifesto decrees can properly addres
Re: (Score:2)
Agile is not a process. Agile is not a methodology. Agile does not dictate to you. Agile does not prevent your software project from being completed.
And if it can't be broken down into something that can be completed by development, tested by QA, and verified by stakeholders in a single sprint?
Then get a new job with a new career because programming clearly isn't your thing. This is a pretty basic problem solving challenge and if you can't solve this one, you're totally fucked when it comes to meaningful programming challenges.
Re:Scrum Was Never Alive (Score:5, Interesting)
I can see where it might be useful in certain situations. However, when it gets used with other Agile fluff to simply produce a dirty snowball of design layers with no overall architecture produced, then it becomes a headless snake. It also tends to get misused by management who see it as a way to micro-manage developers thereby pissing off the very developers upon whom they are depending.
Well I've worked on a lot of successful scrum-based projects (full disclosure: I'm a certified scrum master). Done right it's a very effective and enjoyable way to work. But there are some pre-reqs if you are going to succeed.
If you do it right, then you can be very productive and have fun doing it. Unfortunately, there are a lot people who have made half-assed attempts at "agile" and then rubbished it when their projects failed.
Re: (Score:2)
I think that is absolutely key.
The prerequisites as it were.
Scrum is a very optimal process once you have all those key things you mention.
If there's one thing about Agile that is key: People BEOFRE Process.
If you look at all your prerequisites, so many of them rely on people.
People need to buy into it. Including customers. That's not very applicable for many industries.
You need a general architecture in place. That needs a good architect and time to build it out.
You need a team of skilled self-starting dev
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
FTFY.
Re: (Score:2)
All project management has its uses. I work in a shop where I see the perfect place for waterfall, for iterative and incremental, and for scrum management techniques. I've seen projects which should have been broken into phases managed by each of these various techniques, or a combination thereof. I'm always looking at projects and whittling away the tools from some, or piling them on for others: you really do not want to use every last project management process on every project all the time.
I work w
Re: (Score:2, Insightful)
Scrum was very useful. It was one of my imbecile tests for a long time. If an American said "scrum" instead of huddle, they were either just parroting what some idiot boss had read in a book or they themselves were the idiot. Americans have no idea what a scrum is unless they were one of the few who played rugby at some point.
The other imbecile test is the use of the word "A3" to describe a summary printed on tabloid-sized paper. Again, we do not have A3 paper in the US, so this was always a good indication
Re: (Score:2)
Re: (Score:2)
One bad thing: you cannot learn this methodology in a $15k course. That would go against its very nature.
That's terrible, you should change that to: You can learn this methodology in my exclusive $15k per seat course!
Re: (Score:2)
Re: (Score:2)
I've noticed a disturbing trend from one of those "three letter" IT providers: their folks have titles in their email trailers, declaring themselves as "Certified Scrum Masters". For me, this is a warning sign that the person has no actual experience or knowledge of software development. I'm guessing that the company involved has some kind of policy that gives them points for getting "Certifications".
When I recruit folks for projects, I don't care about any certifications . . . for me it is more importa
Re: (Score:2)
"Certified" is used in some titles. You get "Project Management Professional" (which is a certification requiring actual experience), but also "CISCO Certified Network Engineer" or "Certified SCRUM Master" or "Microsoft Certified Professional". It's a credential thing.
When I ask them what they could have done better in hindsight after a project, you get a cornucopia of ideas. That person is hired!
Project Managers are supposed to constantly collect and file Lessons Learned as part of historical information for a project. This is continuous: work performance information, risks, project document updates, and lessons learned constant
Re: (Score:2)
Hi, just this comment, as a pre-Christmas gift! In a project that I worked with, oh, yes, it was for a company the also produced mainframes, if anyone here knows what that means . . . a quality assurance manger monitored the the defects and the lines of code changed with each defect fixed. This meant that the developer had to appear in a manager meeting, and explain why this defect needed to be fixed.
The developers soon determined that the quality assurance manager's script was just looking for semi-colo
Re: (Score:2)
Very few ever cared about Scrum. Scrum was never a "thing", so you can't really call it dead as it was never alive.
BS. There's a bunch of (frequently large) companies still using Scrum; I've had several try to interview me. It's not just some tiny niche thing, unless everyone's dumped it in the last 6 months or so.
Re: (Score:2)
I used it very successfully. But I've been in this business in the 80's, and the same thing has been through of every development methodology and philosophy that's come down the pike: some people use it and report great success, but that success never translates to *everybody* who uses it -- much less just to those who merely pay lip service to it.
That's because you have to be realistic about what a methodology can achieve. It can put useful tools in the hands of fundamentally competent organizations, but
Re:The Scrum Master is a big con (Score:4, Interesting)
In my last job, scrum-master was a task that was rotated through the team. Each sprint, a different team member takes on the responsibility. This gave everyone a better insight on what the job entails. After doing that for six months, it became clear who the right people were for the job - and it rotated around maybe three or four members of the team rather than all of us. New team members usually got handed the job for one sprint after they'd been with us for a couple of sprints.
Paying someone to be scrum-master is only worth-while when that person masters multiple scrums - and goes to scrum-of-scrums...and so forth. For most small teams, you don' t need that as a full-time role.
As for the scrum master "barking orders"...whoever thought that was what you do didn't read the scrum guide! The scrum master is a clerk - a book-keeper - and a keeper-of-rules - a servant of the team - not some kind of manager. If you give the scrum-master managerial power over the team - then you're not doing scrum anymore.
If you don't do scrum by-the-book, don't complain when it doesn't work. You're perfectly entitled to modify the system - but be aware that when you do so, you're not "doing scrum" anymore - you're doing some kind of pseudo-scrum - and when your pseudo-scrum breaks down like this, you have only yourselves to blame.
Re: (Score:2)
A sole developer usually doesn't need team meetings so rules on how to conduct those meetings would be kind of pointless.
Re: (Score:2)