Getting Real is a smaller, faster, better way to build software.
Getting Real is about skipping all the stuff that represents real (charts, graphs, boxes, arrows, schematics, wireframes, etc.) and actually building the real thing.
Getting real is less. Less mass, less software, less features, less paperwork, less of everything that's not essential (and most of what you think is essential actually isn't).
Getting Real is staying small and being agile.
Getting Real starts with the interface, the real screens that people are going to use. It begins with what the customer actually experiences and builds backwards from there. This lets you get the interface right before you get the software wrong.
Getting Real is about iterations and lowering the cost of change. Getting Real is all about launching, tweaking, and constantly improving which makes it a perfect approach for web-based software.
Getting Real delivers just what customers need and eliminates anything they don't.
We do some of this with some of our web apps today. I agree mocking the interface up is a nice place to start. The only place that I begin to feel a little uneasy is when you get down to iterations, which sounds a bit like the project that will never end. I need to find time to read through the whole thing and see how that is handled in Getting Real.
Of course, this all sounds a bit more unstructured than the SDLC (Software Development LifeCycle) guidelines they are trying to instill at work. I am just not 100% sure how well that structure fits with today's world of I want instant gratification. I guess we'll find out.