
We've invented waterfall - latch
http://epicenterconsulting.com/method
======
giberson
Here's what I would like to see from a consulting company for once. Don't
interview the stake holders of the company, they don't use the software like
their employees do. They have a high level overview based on feedback from
their employees. When you interview them, you're getting second hand
information that will likely be missing key points that they forgot to mention
or just simply think is obvious and doesn't require mentioning.

So here's what you should do. Over the shoulder review of a representative
employee of each department. HR, AP, AR etc. Actively watch and understand the
processes they go through. FOR AN ENTIRE 8 HOUR SHIFT.

No, seriously.

Now, you've got a good idea of how its done current.

Then do the stake holder interview to find out what they want to do
differently.

Then plan, develop and deploy your software.

I seriously don't get why despite there being a recognized need for
understanding the problem scope which everyone one will invest hours in
meetings and conference calls talking about, no one actually invests any
(significant) time doing, or reviewing the actual process. It's the fastest
most efficient way to understand the problem. It would totally diminish months
of back and forth "here's what you asked for" "no, that's not what I asked
for" development review process that almost _always_ occurs with consultant
projects.

/rant

~~~
roc
Let me tell you why you don't see this happening more often.

I did this on a project a few years back. I replaced a paper workflow process
that was taking up two people each in three departments with a web-based
workflow that increased visibility, dropped turn-around time from days to
minutes, increased accountability and accuracy and trimmed those 16 person
hours of processing down to 1-2 per department.

Everyone who directly interacted with the new system loved it. Numerous edge
cases that would have been lost in high-level review were caught and
integrated from day 1 due to my actually watching people do the job for a day
or two per department. The solution has been rock solid (minor maintenance
only) for five years.

And I almost lost the job.

The people who sign the checks were furious. The balance of political power
between departments were thrown for a loop. One head in particular treated the
thing as a near-existential threat. His entire concept of his job revolved
around being the authoritative interface for retrieving and maintaining pieces
of data that were no longer exclusively under his control. Another flipped out
because middle management saw the results as cause to reduce his headcount and
budget, and thus importance.

These two departments fought for months, refusing to contribute their shares
of budget that were pledged toward modernizing this system.

On a technical and practical level, it was the single best experience I've
ever had as a consultant. On a personal and economic level, is was one of the
worst. It was some of the hardest money I've ever tried to collect. It was
some of the most time and energy I've put into the political and 'sales' side
of a job (the part I treat as a necessary evil, but very much evil). The
corporation has made out like a bandit in the long run. But I paid the price.

It's simply too easy and financially rewarding to allow a client's political
nonsense to screw up every stage of a project. I have less stress, the people
who pay me are happier and I bill far more hours.

As with most software, internally developed software included, you don't see
better projects more often because the incentives are horribly perverted and
stacked against it.

~~~
namank
There is process called Contextual Design. Part of it talks about treating the
tacit knowledge of a workplace like a very necessary requirement for your
software. So that means including the _culture_ of the workplace in your reqs.

It sounds dumb at first but it makes perfect sense. What you did at that place
was to apply a bandaid to a fracture where it really should have been a cast.
But you didn't know it was a fracture because you didn't look past the
swelling to the root cause of the pain. This is nothing new, consultants have
been loathed for this very reason for a long time now.

That was me telling you how to do your job. If you wanna know more, google it.
If ya got offended, have a nice day!

~~~
jakejake
Interesting point until the twatty comment at the end.

~~~
Spearchucker
I just love how much sound advice we discard because of our feelings towards
someone/something.

Ever read Stuart Sutherland's Irrationality?

~~~
overgard
I agree with the sentiment, but how can you know to trust someone's advice if
they're acting in a way that's obviously very socially stupid? (I'm not huge
on excessive politeness, but I think it's quite stupid to be aggressive for no
reason. What purpose does that serve? Why should I trust the advice of a
person that acts that way?)

~~~
lhnz
I assume by treating their argument in a rational non-emotional way...

------
ctdonath
Few seem to realize that source code is but the most thorough "blueprint" of
the product. That compilation - to wit construction of the actual product from
the blueprint - is nigh unto instant and free means everyone overlooks it as
the actual construction process, akin to actually building a bridge from
detailed plans (except you get one shot at building a bridge, while you can
recompile every few minutes). Ergo, "analysis", at greatest detail, _is_
coding. That we iterate so much comes from the continued newness of the
technology and the relative complexity of the products; bridges are well-
understood and iterating the design of one is minimal.

To the site's point (or missing thereof), the notion of "don't start coding
until the analysis is complete" is a gross misunderstanding that coding IS
analysis.

The inanity of reinventing the waterfall model is obvious to HN readers.

~~~
goldmab
It sounds like you're saying something similar to this:
[http://www.developerdotstar.com/mag/articles/reeves_design.h...](http://www.developerdotstar.com/mag/articles/reeves_design.html)

------
tpatke
Meh. This is hardly the most ridiculous thing I have seen on the internet. I
am sure this methodology will work sometimes for some clients. Heck, I bet a
lot of startups here on HackerNews are using similar methodologies - but
without the early usability testing. If nothing else, at least this company
are differentiating themselves. Haven't seen a lot of other consultancies get
posted up here on HackerNews.

Every project is different. We should try and not be too dogmatic about these
things.

~~~
goldmab
This was posted on HN so that we can make fun of it, and I think we're right
to do so. You can be as wishy washy as you like about different situations
requiring different processes, but have you ever seen somebody successfully
isolate software engineering from coding and put them in sequence?

~~~
MortenK
Waterfall is actually considered the very best model for software development,
when the requirements are known up front in excruciating detail.

An _average_ project experience around 25% change in requirements. Hence
waterfall is highly unsuited for the majority of projects, since it does not
handle requirement changes well.

However, in a few areas such as aeroplane control software, space shuttle
software and similar, waterfall is indeed the optimal development process.

Different projects DO require different development processes. That's not
wishy washy, it's the reality of software engineering.

Mindlessly applying your favourite development process to all projects, be it
waterfall, scrum, evolutionary prototyping, spiral development or what have
you, will very likely result in failure, if the process does not fit the
project.

~~~
jameskilton
"Waterfall" was defined in a paper describing how NOT to do software
development. The problem was that very few people at the time had any process
at all with software so seeing this they gave it a try.

~~~
MortenK
The paper you and "gujk" are referring to, I believe must be Winston Royce's
paper.

It's wrong to say that the paper is a description of how _not_ to do software
development. Rather, it's suggestions for a set of improvements to the
process, while retaining the sequential nature. In the paper, Royce considers
waterfall to be a good process, but with flaws which result in high risks.
These flaws is what he addresses in his paper.

His suggested approach is derived from pure waterfall, and is very much
similar. It falls into the "modified waterfall" category of life cycle models,
together with a group of other similarly waterfall-derived models.

~~~
eli
He said, and I'm quoting, that the pure waterfall method is a good concept
"but is risky and invites failure." He described how it leads to massive cost
and schedule overruns. It was definitely a process that he did not think you
should use.

His proposed solutions that you call "modified waterfall" are modified _quite
a bit_. (As an aside, he never used the word "waterfall.")

The paper is here:
[http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/wate...](http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf)

~~~
MortenK
I have read the paper multiple times over the years.

The quote "is risky and invites failure" is correct. However, another quote,
even on the very same page:

"However, I believe the illustrated approach to be fundamentally sound. The
remainder of this discussion presents five additional features that must be
added to this basic approach to eliminate most of the development risks."

These suggestions are to 1) Add an additional (preliminary) design phase,
after requirement analysis. 2) Much greater documentation. 3) Perform the
entire sequential process twice (not x amount of iterations, just two times).
4) Additional activities and documentation during testing phase. 5) Involving
the customer.

His diagrams require close scrutiny, as on first inspection it seems the
process is markedly different, when it is really not. It is still an entirely
sequential waterfall process, just with an extra phase (preliminary design).

------
zedshaw
Actually, this is refreshingly honest compared to the "agile" methodologies.
Having worked with plenty of supposedly agile consultants I can tell you they
basically do waterfall it's just their cascading stupidity starts with code
and then wanders around writing unit tests until the client is tapped out. At
least this is doing some actual user interface design and usability testing.

Then again, I doubt these guys do this since it's all marketing.

~~~
jameskilton
Really? Claiming to have invented the most well know and also the worst
software development process is honest? It's a bold-faced lie written only to
get clients.

One can only imagine what actually happens in communication once they have a
client. If the marketing is a complete lie, then I can't imagine the company
itself can be trusted.

~~~
zedshaw
>Claiming to have invented the most well know and also the worst software
development process is honest?

They claim to have developed the best process, just like all the agile con
artists out there.

------
j45
Am I in the minority who uses both agile and waterfall methods?

The long and the short of it for me is this: There's two ways to solve
problems. Agile helps immensely when you are figuring out how the solution
would work. When you're solving a problem that might be solved in manual
processes largely, Waterfall can help a lot, but not alone.

For unknown solutions, agile gives you a lot of iterative benefits.

For known solutions, waterfall with some agile feedback loops gives you
incremental benefits.

What's the difference?

Sometimes, in a business, they have a great process already. It's in paper, or
multiple systems, but they have their way of doing things that works. I
believe it's called their competitive advantage.

Othertimes, a business is facing a problem for the first time, and wonder "how
do we solve this". In this case, doing a big upfront design is a waste of
time, starting small and staying flexible is most important.

For me, this mindset of doing both is critical, not one _or_ the other at all
times. You simply miss out on too much if you don't use agile, and you run
around too much if you ignore waterfall when a solution exists.

Waterfall works where it's a known process, like building a house. You can
have agile loops in there when building a house and improve it as you go.

When you're trying to build a new building that's never been built before, an
iterative, feedback-centric approach like Agile is a lot more beneficial.

If a company focuses on taking something like Waterfall and introducing
feedback loops (agile) like this epicenter thing, is it not a bit clearer than
the black-box voodoo out there? Maybe it's just me, but I applaud anyone
trying to make software easier. It just shouldn't be a dogmatic, or religious
dismissal.

0.02.

------
brd
Its really not quite as bad as it looks at first glance.

Step 2: "we design an interactive prototype" allows them to get the feedback
that really makes more agile methods work. You don't need to constantly
iterate during development if you iterate properly during prototyping. I
certainly wouldn't advocate this method but its not a vanilla waterfall
method.

~~~
absconditus
If one reads the paper most commonly cited as the source of the waterfall
methodology he or she will discover that the author of the paper recommends
doing something akin to prototyping before designing the real program. The
paper is actually a critique of the process now commonly referred to as
waterfall and the author does not recommend using the process as first
presented in the critique.

~~~
arctangent
Royce's paper can be found here:

[http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/wate...](http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf)

------
bruinseve
Sadly, I don't think this is a joke. Method as described: "Analysis We don't
write a line of code until we know your business as well as the people who
keep it running every day. " Method as implemented: "Analysis We never write
any code"

------
davidu
This doesn't look like a joke. Dangerous. Anyone who has done this methodology
runs screaming for an exit after a failed project or two.

~~~
tintin
Not so fast. This isn't something new or strange at all. We are doing this for
years with great success.

But maybe you know this method as these steps (which are the same): Concept ->
Functional design -> Graphic design -> Building -> Testing -> Deploy.

Nothing strange about that. Take a look at the IBM Rational Unified Process
<http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process>

I just think this is a hyped site trying to sell there book.

~~~
outworlder
Or better yet: don't ever look at anything from Rational (now IBM).

Unless you are a consulting company the size of IBM. With the same business
model.

------
Ronnie76er
Waterfall isn't bad in all circumstances. Lockheed Martin isn't iterating a
jet into the side of a mountain 100 times until they get it right.

~~~
arctangent
Perhaps not.

But they're probably running a computer model of the jet (and its systems)
under various simulated scenarios.

They're also probably building some full-scale mock-ups to test in wind
tunnels.

And they also have test pilots to fly things which sometimes never make it
into wide scale production.

So, I'd argue that there is some iteration going on there.

~~~
martininmelb
Which is also what the company is claiming to do. I.e. we will create a
prototype and walk you through it before we start coding.

------
shotgun
I sent their Chief Architect a linkedin message to make him aware of this
thread. Hopefully we'll hear from him.

------
tpimental
Maybe they aren't aware of Waterfall. Pete Campbell on Mad Men had a great
quote; "You know what? I have good ideas. In fact, I used to carry around a
notebook and a pen, just to keep track. Direct marketing? I thought of that.
It turned out it already existed, but I arrived at it independently."

~~~
joshsusser
If they are such experts, how would they not be aware of waterfall? Either
they are idiots who have no clue about software development methodology, or
they are just lying (either to their customers or themselves). It's not like
it's hard to find a reference to waterfall if you bother to look.

------
bernardes
"Unlike a traditional development process, ours establishes all the system's
requirements before a line of code is written."

This is freakin' unbelievable. _ROFL_

~~~
blueprint
Might explain why the "Code" part of their process seems so lacking in
substantial details!

------
bmccormack
The site looks nice. Whether or not their methods are the best, I've worked
for quite a few folks who would find their presentation very appealing.
Because they've been burned by companies who wrote code for them that didn't
meet their expectations, they're excited about a company that will actually
listen to their expectations thoroughly before the process begins.

------
fypomg
We've invented the mobile un-friendly site! We are industry pioneers!

How are we missing the -

Paperback + Consultation for $250 Complete 45 page book (45 pages?) Ships
within 2 days 1 hour 1-on-1 consultation Expert implementation advice

They sound like experts to me. 37signals book Rework only has 288 pages $11.
Page count doesn't mean everything, but clearly 37sig is stuffed with fluff.
All you need is 45 to change to the game up.

I'm a non-profit and small business owner, I'm sold!

------
buff-a
In an ideal world, Waterfall will lead to a worse product than an iterative
one. We don't live in the real world, and I expect these guys deal with
clients who regularly fall into the -from-hell[1] category. I would bet that
many people posting here aren't running consultancies and don't have
experience with such clients (or any clients).

In such a situation, it is in fact entirely rational to develop a lightweight,
low cost UI that a non-technical person can commit to, i.e. sign a contract.
The developer can then go off and implement it with a very clear legal case if
the client then chooses not to pay because "its not what we wanted".

Its not what I do, and I know that many here take a more involved approach to
their clients, but its undeniable that it is a successful business model, and
in some cases I believe it can produce _some_ result where otherwise there
might be none. Equally I'm sure it produces results that are ultimately not
used, but where the company still gets paid.

[1] <http://clientsfromhell.net/>

------
MattRogish
If you read the book's PDF
([http://epicenterconsulting.com/book_source/Obsessively-
Thoro...](http://epicenterconsulting.com/book_source/Obsessively-Thorough-
Software-Design-Preview.pdf)) you'll also note that:

"Hal was the first to introduce the concept of building an interactive demo as
a key part of the software development process"

Really? I can't imagine that's true

~~~
winterwaterfall
Check out Hal's website with JavaScript disabled:

<http://www.halhelms.com/>

What's going on there? Hal Helms home helplessly hacked? Or just poor page
design?

------
fijal
Did you notice how men in suits are left and right but not in the middle?

~~~
tryke
I wondered who the man with the clipboard was, micro-managing every step of
the process.

------
manuscreationis
Doesn't look as terrible as "true" waterfall, but I think this is just
marketing fluff to win people over by telling them about your rock-solid
practices.

If they have an arrow that looped from Beta Testing back into Interface
Design/Usability/Engineering/Coding, you'd probably end up with what most
shops do anyways, speaking in broad strokes.

------
peteforde
My founding business partner Ryan McMinn spoke at an open source conference in
Toronto a few years ago. In the talk he explained how and why we built Unspace
the way that we did.

<http://www.youtube.com/watch?v=lIQIZ0NIkxk>

He talks extensively about the need to work directly with the end users of the
system, instead of the management. The realization that specifications are
usually nothing more than mutually assured destruction.

Pretty much the only thing that's changed in five years is that the scale of
our company has grown, and now we do indeed have contracts with our clients to
protect us from bad things.

Anyhow, I highly recommend the video if you're looking for an in-the-trenches
perspective.

------
willurd
I actually know Clark Valberg, the founder of Epicenter Consulting, and did
some work with him a few years back; he's a great guy. You guys can criticize
him all you want, but he actually cares.

We should direct our efforts towards the bloodsuckers, not the people giving
blood.

~~~
rickmb
We you say "he cares" I presume you mean "cares about slick marketing to
clueless clients". Because Epicenter obviously doesn't give a damn about
either the truth or software engineering.

I'm sorry, but the people who claim the one true method is keeping the
programmers locked in the basement without real world input or feedback _are_
the bloodsuckers.

~~~
willurd
No, I mean that he cares about giving his clients a great product. He's not
just in it to soak money out of people; he actually cares about the outcome,
much like an artist cares about their paintings.

And look, I'm not Clark. I don't speak for Clark. This is just the experience
I had working with him and getting to know him for a year and a half.

~~~
raymondcamden
I can ditto this. I've known Clark for years. He is an honorable person, as is
his coworker Ben Nadel. Fault them if you will for 'inventing' something that
already existed, but this was - at worst - an innocent mistake. How many
people here have reached out to them to try to help correct their mistake?

------
eweise
I love how each coder has a giant clock right in front of their face.

------
jrockway
How do you do usability testing without the real software having been written?

I never realized just how insane waterfall is until I saw this diagram. Wow.

------
alabut
I've got a bone to pick with people that have a bone to pick with waterfall,
especially when they don't realize that whatever competing newer workflow they
swear by is actually waterfall in disguise.

Let's just ignore for a second that a waterfall process sent men to the moon
and continues to build skyscrapers, with each project having _a set of
stakeholders the size of a small city_ and all while adjusting to a shifting
landscape of nearly infinite variables. Especially the first few moon
missions, when no one had done it before. It's why all of the original
astronauts were test pilots - not just because of their bravado but also their
experience in co-designing unfinished machines along with the engineers to
bring it to a workable finished state. The roots of the modern HCI and human
factors industries comes from analyzing and optimizing the usability of
cockpits. The astronauts even had their own usability jokes about a model of
training jet that was so user-unfriendly that the emergency instructions for
ejection were printed on the side of the canopy, which is nuts because step
one was to blow the canopy (along with the rest of the instructions) up off
into the sky.

These weren't dumb monkeys strapped to a giant tin can and blown into space,
and neither were the engineers that sent them there. With waterfall.

So you use agile/xp/scrum/whatever and swear software is _way_ different than
building bridges. I've worked on and with several of those teams, with varying
levels of strictness, and guess what? It's still basically waterfall. But
instead of PMs owning the process and spec'ing things out in advance,
engineers own the process and the spec is written and re-written during
development on a bunch of index cards with sharpies like a grade school art
project (or the digital equivalent), designers get barely a week ahead of each
sprint or run around like caffeinated janitors cleaning up after each sprint,
and documentation gets written last or not at all.

And before anyone does ad hominem attacks on whether my teams were doing agile
correctly, this is the same dynamic I witnessed at the most famous agile and
rails development shop you can think of. You probably only need one guess to
figure out who it is.

What matters then, if it's not process? It's called _expertise_ \- a broad
collection of various techniques and the context-specific awareness of when to
use each one. Instead of blindly following a process and trying to hammer it
into every situation, take a tools-instead-of-rules approach to using whatever
techniques are appropriate for each project.

For anyone interested in this kind of flexible thinking instead of linear GTD
productivity tools that leave you stuck in robot mode, there's an excellent
book called Pragmatic Thinking And Learning that goes into a lot more detail
and pulls inspiration from how the nursing industry overhauled their education
system in the 70's.

[http://pragprog.com/book/ahptl/pragmatic-thinking-and-
learni...](http://pragprog.com/book/ahptl/pragmatic-thinking-and-learning)

I know, from the book publisher that sells the pickaxe Rails book _and_ stuff
on agile. Oh the irony!

~~~
wpietri
I'm totally not getting why you're saying agile approaches are waterfall in
disguise.

The essential difference to me is in length of feedback loops. Microsoft
releases a new OS every few years; some place like Etsy releases new code many
times a day. A developer or product manager at Etsy can know within a few
hours whether some change is really a good idea; Microsoft not so much.

You seem to be saying that because there are the same sorts of people
involved, and because one has a giant spec document while another has a stack
of index cards that might be called a spec, then they're the same. Which isn't
making any sense to me.

~~~
alabut
Nope, it has nothing to do with the commonalities in people or roles, sorry I
wasn't clear. Let me try again.

It's a knock on all rigid processes and dogma, not agile in particular. I
trimmed the rant down by taking out the sections that rip into UX firms, with
their Big Upfront Design and cocky rockstar designer personas, but it could
just as easily been about them. I only cut it because I thought the parallels
were obvious with the diagram on the Epic Consulting website.

What I'm saying is that if waterfall means people are grouped together by
specialty - programmers with programmers, designers with designers - each
group is run by one dominant process suited to only one of the
specializations, and each group tends to work in different stages, then both
traditional UX design and agile development are run as de facto waterfall
teams, whether by explicit hierarchies or simple stakeholder buy-in.

Consider this - what's the difference between:

1) a PM spec'ing things out in advance and basically telling everybody what to
do and in which order.

2) an agile shop coding things up on the fly and telling the designers to run
after them to clean up the visuals without making major changes, so they might
as well be building to a spec.

3) a UX firm mapping out how the product works before handing off to peon
engineers that can't make major changes and might as well be building to a
spec.

To end on a positive note, there is one other solution to expertise, by the
way. It's grouping teams by product, not role, and figuring out an
interdisciplinary way to work together, rather than running the entire team by
the methodology of one specialty. That way you're picking good ideas from
across different processes and adapting to the company culture to boot. For
example, TypeKit does daily stand ups at 10:05am every day and that's an
aspect of agile that they've liked enough to use for the whole company, but
I'd be surprised if their designers were checking their art assets into
Pivotal Tracker or the programmers were writing up UX journey maps of each
user persona.

Steve Jobs always liked to describe Apple as the biggest startup he knew and a
more accurate description would be that it's a collection of startups, with
each one focused on a single product. Seems to work pretty well for them.

EDIT: fixed a few formatting errors.

~~~
wpietri
Yep! I get it now. Thanks for clarifying.

I agree that "agile" teams that group people by specialty are clueless. Done
right, the teams are, as you suggest, cross-functional. That was the original
intent for the people who coined the term Agile, but much of that has fallen
by the wayside as larger organizations decided Agile was fashionable and
consultants rushed in to sell them 3% dilutions of XP or Scrum.

I've written more about how that happened here, and a lot of the early Agile
types I've talked to agree: [http://agilefocus.com/2011/02/21/agiles-second-
chasm-and-how...](http://agilefocus.com/2011/02/21/agiles-second-chasm-and-
how-we-fell-in/)

~~~
alabut
That's a great writeup! I know exactly how you feel except my disappointment
was doubled, because I was a hybrid developer/designer for years before
completing the switch from developer to designer and I lost the faith in both
agile and UX at about the same time.

I wish I had the courage to write up my disappointment like you did, but I'm
happy that I've moved on to a meta-process of borrowing from different
techniques as needed.

------
ap22213
Hilarious.

But all jokes aside, have you ever tried to explain to a self-described
'technical-enough-to-be-dangerous' corporate middle manager what an iterative
and incremental process is?

------
bascule
I thought the most bothersome thing on the entire page was the claim they put
"business over code". Without working software you don't have a business.

------
stfu
The sad part is, that most of their clients are probably buying into this and
think what an excellent and innovative company they hired.

------
dicroce
Ok, I just invented a new methodology, I dub thee: "Agilefall"

First we meet and discuss the goals for the sprint. Then I design (usually
some class diagrams on a sheet of paper or board), then I code and test it
(unit tests of course) and finally check it in. Each 4 to 6 week sprint is
internally structured as a waterfall. :)

------
mrspandex
Is this a joke?

~~~
karmajunkie
I honestly thought it was, but crawling the rest of the site it doesn't have
an ounce of parody about it. I think these guys really think this is a new
methodology...

~~~
karmajunkie
For example, link to their "Chief Software Architect" linkedin profile:
<http://www.linkedin.com/profile/view?id=1613224>

~~~
mrcharles
Dude has a six year gap in his resume where he goes from being a web designer
to chief architect? That might explain why he thinks waterfall is new.

~~~
bigohms
Can we see a link to your LinkedIn profile?

~~~
mrcharles
Too lazy to figure out how to get a shareable link from LinkedIn, but feel
free to look up Charles Randall who is currently at Ubisoft Toronto.

Not that I know what this proves, other than Linked In's shitty use of URLs.

------
Amadeus2011
Some of these comments are missing the point. Their methodology isn't about
how to build but on what to build. It's a problem many industries face. When
the client is a non-technical person (the norm in making web apps) building
the UI first makes good sense.

~~~
johnx123-up
I agree. Most of the comments are overlooked. I suspect that the OP is
competitor to the said company?

------
reledi
Epicenter is sending out some annoyed tweets while defending the AgileUX
movement. They claim their process is nothing like waterfall as it focuses on
iterative UX prototyping.

<https://twitter.com/epicenternyc>

------
Morendil
What I love best is this testimonial praising the book:

> Helms and Valberg lay out an innovative methodology that finally delivers on
> the promise of Agile Development.

------
jhrobert
The problem with both waterfall and agile is that we are missing the
definition of "the Humble process" to develop software.

Unfortunately humility does not sell so well.

------
msluyter
I love the fact that the software engineers basically deliver UML diagrams to
the coders. I'd shoot myself if that were all there was to my job.

------
nickfrost
Thank you @JoshSusser for finding this diamond in the rough. What would we do
without waterfall development!?

------
feedus
I've invented "rock".

I don't talk to anyone.

I look at the crap you're using and make something new.

I give you the URL.

Figure it out on your own.

Invoice due on receipt.

------
shareme
Would this help design a process to Balance the US gov budget?

------
cridal
"We've invented cigarettes", come buy a pack... everything that doesn't kill
you makes you stronger...

