
Poor Man’s Agile: Scrum in 5 Simple Steps - scottporad
http://www.scottporad.com/2013/03/19/poor-mans-agile-scrum-in-5-simple-steps/
======
jdlshore
There's more to Agile than Scrum. And there's more to Scrum than Scott's
saying.

Diana Larsen and I sat down last year and wrote down all the different ways we
saw people doing Agile, what worked, what didn't, and why so few teams were
getting the promised benefits of what the agile movement promised, lo, those
many years ago.

The nice version is here: <http://www.agilefluency.com>

The nasty (but much shorter) version is here: People care more about slapping
the "Agile" label on their door than they care about doing the hard work of
changing their organization's work habits. Change is hard. Doing Agile well
takes change. It's easier to get a certification and call it a day.

(Not bitter. Nooooo... not bitter at all. But so very tired of the bullshit.)

~~~
adrianhoward
_There's more to Agile than Scrum. And there's more to Scrum than Scott's
saying._

Ah good - somebody else go there first ;-)

To James' link I'd add reading the Agile Manifesto values
(<http://agilemanifesto.org/>) and principles
(<http://agilemanifesto.org/principles.html> \- everybody forgets the
principles).

If folk want to learn a bit more about Scrum the Scrum Guide is a nice summary
and not _that_ much longer than Scott's mild oversimplification
(<http://www.scrum.org/Scrum-Guides>).

(And since he's too polite to pimp it himself - James' book co-authored with
Shane Warden is one of the ones I recommend to folk wanting to learn about
agile <http://www.jamesshore.com/Agile-Book/> \- well worth a read if you're
interested).

------
samd
Don't read this article either. Instead read the actual Agile manifesto. It's
really short, but very insightful. After you've read it stop and think (we're
programmers, we're supposed to be good at that) about how your current
process, or a potential process matches the principles laid out.

<http://agilemanifesto.org/>

<http://agilemanifesto.org/principles.html>

~~~
brazzy
The problem is that the manifesto doesn't give you a concrete way of doing
things; Scrum does, and it can be really as simple as this article says.

Basically, the article is a backlash to things like <http://programming-
motherfucker.com/> , which is a backlash to people doing Scrum, XP, etc. so
wrong that it seems no better than the beaurocratic monstrosities that the
agile manifesto was a backlash to.

~~~
samd
Alright, read the manifesto first, understand it, then go read about Scrum.

------
minimax
The only thing I appreciate about my experience with Scrum was that I could
use the hours long "sprint planning" meetings to reflect on my long term goal
of never having to sit through another hours long "sprint planning" meeting
ever again.

~~~
vailripper
My experience has been that, while planning meetings are quite painful,
they're the most valuable part of Agile. Forcing yourself to sit down every
week and decide what really matters is extremely valuable and keeps teams
focused.

~~~
vbl
Short of actually making (good, working) stuff, informed and merciless
prioritization is the most important thing you can do in producing software.

~~~
thirdtruck
And for life in general.

------
mikestew
478 pages, huh? A book on Scrum of that size seems to reflect my observation
of some organizations that have implemented Scrum: little extras will be added
along the way until it's no longer "agile" and just as unwieldy as the process
it replaced.

For an organization, that can be fine. Maybe Scrum is too simplistic, maybe
it's missing a few pieces vital to your organization. Experiment, season to
taste. But I believe that there often isn't enough thought put into how badly
that seasoning is needed. Rather, someone along the chain says "but we don't
have that thing from the old way", whether that old thing is vital or was
nothing but a procedure weight around the neck of the team.

As for a 478 page book, someone must have worked really hard to come up with
enough fluff, diagrams, and humorous anecdotes to fill that many pages on
something that's supposed to be "agile".

~~~
brazzy
Someone was simply connecting the two dots:

1) Scrum has been getting buzzword traction, so there is demand for books
about it.

2) A book has to have a couple of hundred pages to justify the price tag.

------
Kuytu
I have always considered scrum to be like a beginners workout routine. It's
never best for you, but it's better than doing what you feel like is good for
you. Because if you've been lying on the sofa for the last ten years, you
don't know what's good for you.

Chances are that you don't know what suites you, that's why you are looking
into scrum in the first place. First you do it strictly by the book and in
time you will learn what works for you and what doesn't. Then you can start
customizing become mature agile team/organization. OP has probably achieved
this, but I think it can be harmful to suggest "pro" techniques to someone
just starting out :)

~~~
samd
That's a great analogy. I think you need a high-functioning team that really
understands the Agile manifesto and its principles to roll-your-own solution.

If you are going to roll-your-own solution, start with retro and build from
there. Retro is the most important part of the process. There's a reason it's
the only explicit activity mentioned in the manifesto. As long as you keep
reflecting on past performance and continually try to improve you'll probably
end up with a good process.

~~~
taligent
Retro is one of the worst parts about agile IMHO.

It encourages everyone to ignore/bottle up issues until the magical retro day
where everyone can spend a couple of hours venting their frustration. At which
point nothing gets done and the process repeats. Project issues should be
resolved immediately, directly with the people responsible and with actionable
outcomes. Not during a glorified weekly/fortnightly 'meeting'.

~~~
adrianhoward
_It encourages everyone to ignore/bottle up issues until the magical retro day
where everyone can spend a couple of hours venting their frustration. At which
point nothing gets done and the process repeats. Project issues should be
resolved immediately, directly with the people responsible and with actionable
outcomes. Not during a glorified weekly/fortnightly 'meeting'._

If that's what happening then the retros are being terribly run. Especially if
you're not coming away with an actionable outcome.

If you can deal with it immediately - you deal with it immediately. Nothing in
any agile process says you should save it up for the retro. Many quite
forcefully say the opposite.

The retro is for helping you spot larger scale issues or systematic problems
that you miss / don't have the room to address in the day-to-day project.

(For example, we ran one last Friday where it was pointed that I'd been a
bottleneck on several different tasks. I'd not been bright enough to spot that
myself. Since the bottlenecks were with different folk nobody had spotted it
at the time. Bring everybody together and - boom - problem identified and some
options for solutions spotted. No angst or venting involved. There was cake
though ;-)

------
Glyptodon
I always get a kick out of it when I see job ads that make a big deal about
applicants having experience with 'Agile' or 'Scrum' like it's some sort of
hard-earned skill that's it'd be worth using to filter applicants.

I can just imagine some recruiter or HR person looking at resumes:

Applicant A - dozens of accepted to commits to the Linux Kernel, or leader of
some 'known' open source project.

Hmm.

Applicant B - Scrum

OMG! We have a winner!!!

~~~
skylan_q
I've considered making a resume where the first half of the first page is just
a paragraph filled with as many high-profile buzzwords as possible. I'm still
curios to see what would happen.

~~~
Zombieball
The real trick is to put this in the footer of the resume in size 1pt font.
When you print off or look @ your resume it is pretty much not visible. But,
you can kick resume scanning software in the face, hi-ya!

~~~
mappu
\+ Set the font colour to white!

~~~
Zombieball
So simple! How did I not think of this? Cheers mate!

------
submersible
This doesn't say anything about grooming your product backlog, which to me is
one of the major benefits of scrum:

6\. Once a week, everybody gets together for a few hours and roughly plans out
the features that the product is going to have. The features are compiled into
a list with the ones you're going to do first at the top, in the most detail.

Without having the feature set already groomed, those step 2 planning meetings
are going to be brutal.

------
happywolf
No techniques or technology will save a project if there is no mandate from
the management. In other words, if the requirements are vague, inconsistent,
or down right incorrect but management isn't doing anything about it. No
amount of scrum can save you. Yeah I am right into this kind of shit now. Ask
me about it.

------
tomelders
I can't take this Agile crap any longer. It's lunacy. It has all the hall
marks of a religion. A lot of literature, a lot of disciples, hoards of money
grabbing snake oil selling evangelists, and no evidence at all that it works.
In fact, as far as I can see, there's more evidence that it _doesn't_ work.

And the next person that says to me "derp derp derp, well it's better than
waterfall herp derp" can go fly a kite. If you think we live in a world where
there's only two ways to manage/build software, then you're a fool and have no
business being in this business. Either start applying critical thinking or go
sell crazy some place else.

Maybe there is a perfect project out there, somewhere, and they're doing Agile
_right_ , and it makes the product better, and everyone on the team is happier
and more productive. But I've never seen a project like that. In five Agile
projects I've had the misfortune of working on or alongside, All I've seen is
stakeholders making implementation decisions in ivory towers, developers being
told to not implement that "delete" function because it's out of scope (it's
out of scope because the designer and UX people forgot to put it in, but fuck
it, we'll pretend you're right and it's meant to be like that), and teams
pretending stuff works and everything is ok when in actual fact, it doesn't,
and it isn't and if people could just stop looking a Jira and start looking at
the code then maybe we could start to fix this hunking pile of crap and
actually start being proud of our work.

And before anyone weighs in with "Well those project clearly weren't doing
Agile right", please, save your breath. Every project has been infested with
people who have stacks of books on the subject. They love it, they suck it all
up, they obsess over the minutiae of how to implement scrum, retrospectives,
and sprints. They can talk of nothing else at work, at home, or in the pub. If
they can't do it right, who can?

And herein lies the point, there is no way to do agile right. What there is,
is good project managers and bad project managers. There are good devs and bad
devs. Good designers, bad designers. The good people will make good things in
spite of having Agile forced upon them. Then the agile non-thinkers will jump
on the bandwagon and lap up the good peoples success as if it were their own.
Then someone will write a blogpost about how Agile made it all possible and it
will all be lies piled on top of lies.

Do I sound angry? Good, because I am. Agile is a con. People like agile
because it absolves them of the responsibility to think and do their job. It
makes my job a misery and it sucks money out of a clients pockets and to my
mind is no better than theft.

If you think I'm wrong, prove it. And I mean PROVE AGILE WORKS, WITH EVIDENCE
or shut up. Extraordinary claims require extraordinary evidence. I didn't come
into your life and tell you how to suck eggs, but if you're going to come into
mine and do that, you'd better have data to back you up.

~~~
ryanbrunner
There's definitely lots of people who don't think critically about agile, and
just accept whatever agile dogma handed down to them without giving much
thought about how it applies to their team, and their business.

But I think you're _vastly_ underestimating how much of an effect a good
process, or a bad process can have on a development team. The good process
doesn't need to be textbook scrum (In fact, "textbook" scrum is usually not a
great idea), but it's a bit laughable that you're criticizing Agile advocates
for not having critical thinking, while in the same breath minimizing process
to "Well, there's good people and bad people, and the good people will get
things done better."

What do you think makes a good project manager a good product manager? Do they
just magically add +5 to development speed to a project? Of course not, they
build and adapt a process that makes sense for that team. That doesn't
necessarily need to be Scrum, or even Agile, but in my experience those
methodologies seem to work better. The only caveat is that they need to be
built and adapted for a companies particular needs.

In regards to proving Agile works, I can give plenty of anecdotes:

I could talk about when my startup had pressure from upper management to
commit to a fixed roadmap several months out, moving from our "Scrum-like"
agile process to something much more akin to Waterfall. I can talk about how
it led to overly defensive estimates, projects taking roughly double the time
they used to, and inevitable "death marches" at the end of the project, when
we were faced with the prospect of integrating huge projects into our main
codebase, with the QA nightmare that resulted from that.

I could talk about how, in the many tech companies I've worked for, there's an
almost perfect correlation between "agility" (which I'm defining as the
ability to re-evaluate project plans and iteratively develop software) and
quality, ease of deployment, developer productivity, and satisfaction with the
dev team.

Finally, I can talk about a recent example. We recently experimented with
moving to larger, pre-planned projects. One interesting thing about the way we
did the transition is that we packaged up stories that we had already broken
down into stories appropriate for Scrum, and moved them into a larger project.
We ran two projects using this approach. One project that was estimated (in
terms of story points) at about 1.5 weeks ended up taking 5 weeks to deploy.
One project that was estimated around 5 weeks took 12. I wish I could give you
more evidence, but this transition was such an abject failure that we moved
back to Scrum before we did any more damage.

~~~
tomelders
There it is again, that 'Agile is better than waterfall'. I can take any two
turds, draw up a criteria by which to measure their quality (consistency,
length, brownness) and arrive a valid conclusion that proves one turd is
measurably better than the other.

But they're still both turds, and you shouldn't eat them.

Agile does not have a monopoly on process. But Agile apologists repeatedly
offer up that concept. That somehow, a world without Agile is a world without
process. That's an absurd thing to think.

If you want process, tell me what you want to do first, and we'll work
together from there. Agile supporters tell you how you're going to do
something, then ask what you want to do, then tell you what you want to do is
wrong.

As for what makes someone 'good' or 'bad', you offer up a straw man argument
that tells me more about how you think than how I think.

And anecdotes aren't evidence. They're anecdotes. You may have had just as
much success with those projects if you'd made everyone wear cowboy hats on
Thursdays. You can't prove that you wouldn't, just as much as you can't prove
that Agile works.

And your final point is ludicrous, bordering on delusional. If I understand
you correctly, you estimated how long something would take to build using
Agile methodologies, then moved that stuff into an environment where Agile
wasn't implemented, and it took longer than you estimated.

All that tells me is:

    
    
        - You're terrible at estimating 
        - or unable "re-evaluate project plans" (your own words)    
        - or both.
    

I might say I can cook a chicken in half an hour with prayer. Then I put the
chicken in the oven where it takes 1 hour too cook, and then I claim that
prayer is a better way to cook a chicken "because, look! the oven took an
hour, and prayer would only have taken half an hour!"

~~~
ryanbrunner
I don't know how I can constructively with you. I'm aware that there are
things other than Agile and Waterfall. I'm also reasonably sure that you don't
think good project managers magically make teams more productive. But you've
done nothing other than trash Agile, dismiss Waterfall, and offer no
alternatives of your own. How do _you_ like to develop software?

I get what you're saying about "tell me what you want to do first, and we'll
work together from there". I mentioned a few times in my post that it's always
important to not blindly implement Scrum, but to see what works well from you.
But having Scrum defined is still useful for a lot of people, since:

\- It gives you a starting point to work from. Every project is different, but
there's certainly common elements to projects as well. It's a bit like design
patterns in software - applied blindly and religiously, they're impractical
and can lead to pitfalls, but that doesn't they can't serve a purpose.

\- It takes a lot of time to learn what works and what doesn't in regards to
project management. Telling new managers and developers to figure out what
works for them with no guideposts is just going to lead to a whole lot of
inefficiency as everyone stumbles towards a (mostly) shared goal.

In regards to projects taking longer under a waterfall approach vs. an agile
approach, there's a lot of different reasons for this sort of thing happening.

\- Working on small sprints (or whatever you want to call them) instead of
month-long projects saves you a tremendous amount of integration time. Show me
a project under active development that's existed outside the production
branch of a codebase for more than a month that isn't going to be a nightmare
to integrate.

\- Forcing yourself to make decisions up front, especially when you have a
strong product management component to your team, can result in drastically
more time working on requirements instead of starting with some unknowns and
letting them work themselves out.

\- I can probably point to several bits of these projects that we would have
avoided doing or would have done differently with Agile, but the requirements
said otherwise. It's amazing how much power requirements documents have, and
how much inertia they can add to a project.

\- Stuff generally gets done close to the due date on a project. This is as
close to a universal truth as I've ever seen in project management. By keeping
everything in tight iterations, you can control the flow somewhat by putting
pressure to complete releasable software every week, rather than one massive
due date that everyone scrambles for at the end of a project.

\- Being able to "re-evaluate project plans" is a hallmark of Agile, not
Waterfall. I agree, being able to re-evaluate and iteratively arrive at a
solution outside of rigourously documenting things up front would make things
a lot more efficient. That, far more than planning meetings and
retrospectives, is what Agile is all about, so I'm not sure why you're so
intent on trashing it.

I'm not sure why my example is ludicrous. If the process used doesn't have any
effect on how long it takes to develop a project, what's the point of any
process in the first place? Of course using different methodologies will have
different results - even if you aren't an Agile fan, that's completely
obvious.

~~~
tomelders
You're not trying to be constructive. You're blindly trying to force your
points through without shouldering your responsibility to provide proof for
your claims.

The only credible evidence I can find about Agile's supposed benefits is the
Voke report, which warns against using agile. With only 28% of participant
reporting success with an Agile approach. That's bad. Plain old fashioned bad.

It's like I'm debating a creationist. Your logic is circular. You want me to
believe the Agile works, and you're more than happy to tell _me_ how wrong _I
am_ , but you shoulder none of the responsibility to prove your claims. At
best, you're suffering from confirmation bias, but I think that's being too
generous.

And stop talking about waterfall. It's a false dichotomy. You're the only one
making that comparison.

Your argument, as far as I can tell is two fold.

 _Some process is better than no process_ : Well I think every sane person
would agree with you there.

 _Agile is process, everything else is no process_ : Wait... what? How do you
keep on arriving at that conclusion over and over again? And don't even think
about saying "waterfall" because I swear to god, I'll punch my computer so
hard it'll knock Google off the internet.

Find me evidence as compelling and credible as the Voke report, supporting
agile, and we'll talk sensibly. But I'll go out on a limb and say you can't,
and you won't. Because if I were to draw on my anecdotes and present them as
evidence, Agile is universally bad and dooms everything it touches to failure
or 'third-rateness'. That's all the experience I have to draw on.

And I suppose that's my biggest bug bear about Agile. Teams always finish
things wether some fool is ramming agile down their throats or not. There's no
other alternative. But Agile takes great ideas, shatters them into a million
pieces and churns third rate approximations of that good idea out the other
end. Without Agile, I've seen projects that were horribly mis-managed but the
output was still great and once all the screaming was over, I was proud of my
work. There's something about Agile that makes for crap products, and I feel
so ashamed of the output that I wont even put my name to it.

~~~
derefr
> Agile is process, everything else is no process: Wait... what? How do you
> keep on arriving at that conclusion over and over again? And don't even
> think about saying "waterfall" because I swear to god, I'll punch my
> computer so hard it'll knock Google off the internet.

As far as I've been able to ascertain, in practice, "Agile" _means_ "not
waterfall". Fullstop. As in, any process that isn't waterfall, is called "an
Agile process."

You _can_ be "agile" by just goofing around with no big plan; if the work gets
done, you can look back at the points where you made little plans, and say
"well, see, we were doing Agile." Any [successful] process _other than
waterfall_ , when post-hoc analysis is applied to it, will look like the
classic definiton of an "agile" process, no matter whether you were trying to
execute capital-A-Agile at the time!

And I'm not saying that in the "the Agile people are right" sense. I'm saying
it in the _vacuous_ sense: that the term "Agile" is _meaningless_ other than
in that it means "not waterfall." Waterfall is doing design once, at the start
of the process. If you ever do design again at any point, ever break your
design up into pieces and postpone some of them, or design this feature at a
separate point than that feature--then you're not doing waterfall. And so, the
Agile people will say, you're "doing Agile." That's it. That's all they mean.
You've designed more than once.

And your response should be "...so what?"

(But it should also be, in a more diplomatic sense, "well, then we're _all_
doing Agile already _anyway_ , aren't we? You've long won this Quixotic
crusade against the Waterfall windmill; we all agree that 'Agile' (to this
vacuous definition) is the right thing to do. Now let's all go out for a
pint.")

------
Proleps
Lots of people use this thread to spill their hate about Agile. But I actually
think this is a good article. A lot of small companies have no process
whatsoever. Most don't even have a list of requirements or bugs.

I think this article gives you a good start with creating a decent development
process for your company.

------
cpeterso
If Scrum is so agile, why do projects using Scrum spend so much time talking
_about_ Scrum?

~~~
taligent
One reason is to shift blame. I've seen countless developers use the "if only
we were truly agile the project would be fine" excuse. Another reason is
ego/power. Developers can use the "we know agile better than the project
managers" mantra to drive change within a project that they couldn't before.

At the end of the day successful projects happen because of good
communication, clear requirements and hard work. No amounts of tricks can save
you if you don't have all three.

~~~
CodeMage
Funny, what you call out here is quite similar to what I've witnessed, too,
only I have a different point of view.

For example, "we know agile better than the project managers" often comes from
people who find themselves in yet another cargo-cult agile environment with a
Scrum master who not only doesn't have a clue about Scrum, but is also pretty
much convinced that it's a wrong idea and therefore doesn't give a shit about
what he's doing and whether the latest process-related brainwave coming from
above is one step forward or -- more likely -- two step backwards. In such
circumstances, you really do know more about agile than managers when you 1)
say that it defeats the purpose of Scrum to have people filling out how many
hours they've spent working on an item alongside how many they have left, 2)
point out the inefficiency and banality of hour-long discussions on whether we
move the user story from one sprint into the next one or create a copy of it,
3) complain about having 1-2 hours of sprint planning, a 1-hour mid-sprint
review meeting and 1-2 hours of sprint review on top of 30-minute daily
meetings in a 2-week sprint and 4) wonder why nobody seems to have read the
bloody agile manifesto itself.

So when you hear "if only we were truly agile" coming from a dev, maybe it's
not an incompetent egomaniac on a power trip looking to shift the blame for
the things that don't work. Maybe it's someone like me who is sick to the core
of managers who can't hear you because their head is up their ass -- yet
somehow there's always enough place in their for yet another "Agile"
consultant's shaft to get cozy with.

Yes, I'm bitter. That doesn't make me wrong.

------
mcgwiz
This misses the point. Scrum is not merely a prescription of sequential high-
level actions.

Fundamentally, scrum is a recognition of certain risk-bearing concerns in
projects, and the assignment of those separate concerns to specific roles. The
division of concerns sets up a structural tension that drives attention to
risks and which are necessarily resolved through open negotiation. To truly
reap the benefits of Scrum is to appreciate the value of this tension.

All the steps listed fall from this basic understanding.

------
alexkus
Trying to implement Scrum in a $VBC is even more fun, especially when senior
management are so entrenched with waterfall based processes where there is
much more information (almost) set in stone upfront/earlier.

"What are you going to commit to delivering in this project?"

" _points_ This stuff is pretty much guaranteed, unless you change your minds
on the priorities."

"But that's only about 40% of the dev time we've got until our planned release
date[1]."

"Yes, that's all we can commit to definitely doing. They'll be more, don't
worry, but what depends on what the priorities become at a later date and
where we get led with customer feedback[2]."

"But I can't go to my management team with this, they won't understand why
we're not committing to much!"

"They should understand, they told us to do Agile in the first place[3]"

Project starts...

"Can I get copies of the detailed design docs?"

"We don't have any detailed design docs, you can have a look at the design
docs we've got but just remember that they're 'Barely Good Enough'."

"But I can't go to...[4]"

1\. Ok, we can handle an upfront release date.

2\. Ha, like we'll be able to get any of that.

3\. With little or no actual understanding of how it works. But it's a nice
buzzword to spray around with customers...

4\. etc, etc, etc

------
pikewood
There is one very important step that the author missed: ensure you have
customer buy-in. This is also the hardest step to do, but I feel like a lot of
scrum-talk glosses over this.

A medium bug appears in your production environment. Will your customer really
wait till the next sprint to get it prioritized, then fixed?

Or, your customers expect functionality, time, and dollar estimates in a
proposal before they start a project. Sure, some teams think they can do scrum
under the covers, and give them what they really want, but in the end do you
have the right language in your contract to address changes made during the
project? Will the customer really care that feature X didn't make it because
it wasn't prioritized high enough at the last grooming?

Until you get this buy-in from the people paying you, there is a huge conflict
about how you want to do things vs. what the customer expects. And generally,
they'll win until you convince them. But why should they change? They're happy
with how things are going the way it is.

------
lucisferre
I'm confused that this post received so much attention and this
(<https://news.ycombinator.com/item?id=5390897>) received almost none.

Wade's lightweight process didn't add the bullshit layers of Scrum's painful
"retrospectives" and standups. Scott's approach may be "Scrum lite" but it
still isn't helpful or productive. Standups are painful and often about as
effective as asking your kids how their day at school went. Retrospectives are
practically like water-boarding your entire team once a week.

Didn't get everything you planned done this week? Welcome to the real world,
get used to it and figure out how to get the most important things _delivered_
instead. Teams need ownership and accountability not babysitting and
handholding.

------
darkxanthos
Seeing comments where Agile is called out as a process comparable to Scrum and
Waterfall is frustrating. Agile is a set of principles and as such, it doesn't
preclude a Waterfall process or any process for that matter.

In that way, Agile is purposely vague and ambiguous and it's hard to really
say Agile doesn't work for you. What you can say is those aren't your values.
There's nothing needed to be proven that way, it's just a disagreement based
on what you value.

------
ksh
tomelders, i can agree with you but the main reason for scrum (waterFAIL or
whatever metodology you take) will fail is the inital bullshit in software
development, instead of hiring competent and motivated people you rather pay
less and hire larger crew of idiots or even worse, out of mgmt own, complete
incompetency, hire headcount.

The agile methodologies imho are comming from someone that had luck and
instead of winning 7 on national lottery hired competent and motivated people
by sheer luck and due to his own self centered line of thought (egocentrism,
etc), he thought his "inovative" way, brought in the success and started to
market it.

The mgmt is still far too stupid to realize that you cant streamline software
development, you cant get revolutionary ideas on requirement and you cant
JUSTIFY THEIR POSITIONS!

(oh and btw, my cv consist of 18+ years of c/c++ software developent from
world largest IT companies to startups and i think i have seen all the crap
the white collars can offer, they just cant comprehend that the creativitye
cant be streamlined and are always searching for a silver bullet to pay less
and get the breakthrough technology for peanuts)

------
Rabei
THe issue of agile is people do not understand how to properly apply it.

If you do a Product you want fixed budget, fixed releases and flexible scope,
scrum/agile is the best fit.

If you do Projects you want fixed release and fixed scope and flexible budget.
Use waterfall and don't close the budget until the end of the design phase.

------
chenster
He didn't explain why it is call Scrum!!

~~~
mrmincent
because in the game of rugby (where the term scrum comes from), the part where
the game is won or lost is called the breakdown, which is a terrible name for
a methodology you're trying to sell. So they call it the scrum, which although
is useful and looks pretty cool, isn't really as important as other parts of
the game.

~~~
gee_totes
I always thought it was called Scrum because when doing Agile development,
typically everyone has a 5 min stand up meeting some time during the day.
Normally when people are standing around, then tend to arrange in a circle,
and since you have a group of people in a circle moving a project (ball)
towards it's goal (down the field), it resembles a scrum in rugby.

Of course, this definition was imbued on me many many moons ago before the
consultants hijacked the language.

