Tonight I met with Cody Marx Bailey, Roby Fitzhenry, Stephanie Leary, Wendy Wolfington, Mike Abney, Allen Hurst et al to talk about the next BarCampBCS I originally thought. We did do that eventually, but along the way we talked about several issues near and dear to my heart, namely localism, continuous improvement, and community development.
I've always seen a link between one's ability to make a difference in one's own community and how well one does one's own job. The idea being: if I do a good job, others around me will be inspired by my example and desire to do a good job as well, and eventually that will have a lasting impact on the quality of life for us all. This idea came racing back to me tonight as we sat at Murphy's Law and discussed the proposed MiniBar for November 14th. In my experience, the people who are concerned about social responsibility are also the people who are concerned about how well they are doing at work. These are the same people who reflect on how they can improve their performance and the quality of service they offer: continuous improvement.
We also talked about using our work talents in a pro bono fashion to uplift the community by say redoing the web page of a non-profit in need or building applications to track volunteer hours and other things for non-profit groups.
Software developers are interested in continuous improvement mostly for the selfish reason of not wanting to produce junk. Many of us long to make inspired creations that are both useful and beautiful. We pour hours of our time into building applications not only to write the code, markup and styling that goes into these things but also to research the latest and greatest technology and methodologies.
I have known for quite some time that more peole than just software developers think this way, especially having been a web designer myself in the not too distant past. I am constantly talking process and method with Roby Fitzhenry, a local web designer and a design hero of mine. We really speak two different languages: him design communication, and me C#. Yet through this, we still identify strongly with one another and relate with one another. Obviously it can be demonstrated through the existence of books like The Toyota Way and How to Win Friend and Influence People that ideas of self-improvement and process improvement are not confined to a particular discipline.
I think at this point we are on a course of finding others and relating to them how we doing a better job can aid them doing a better job and vice versa. For instance, if I build a good product and I want Roby to help brand and market it for me, he is now just trying to get the right information into the hands of the right people to help them do a better job, and we aren't just trying to sell stuff anymore. The world is full of junk. Let's stop making junk. Let's make quality products instead. This makes me think of a video I just watched on "Accomplish More by Doing Less but Thinking More". This video (combined with a lot of talking I've been doing with Kyle Marshall at work) has got me thinking about how things could be better if we spent more time planning and less time doing. I think we as Americans have a real problem separating what is signal from what is noise.
Landing somewhere between "analysis paralysis" and a total lack of planning on a project has been the topic of several discussions among the members of AgileBCS. I am interested to see what the take of others outside the software development arena is on balancing too much planning against not enough planning, and how they strike that balance.
I haven't set out to define the thesis for our upcoming MiniBar, but hopefully have captured the ideas of others with fidelity and added some of my own.
Edit: There is a Continuous Improvement Open Space happening down in Austin on October 30-November 2nd (the Open Space itself is just the afternoon of 31st to the 2nd). I really hope some of the thought leaders that were present tonight (as well as some of the ones that weren't) can make it to this. Remember, you don't have to be a tech nerd to go to this. Management and leadership types are welcome as well. Remember the Open Space principle, "Whoever comes is the right people."
The Sins of Our Education System
As we all know, Agilists tend to frown on specialization. I am no exception. I tend to think that I take that sentiment a bit further though. I believe that designers should program and that programmers should draw wireframes. Before you dismiss me out of hand as a crackpot, hear me out.
Hopefully by now, most UX designers (and hopefully some developers) have read The Design of Everyday Things. Hopefully those same designers have accepted that their difficulty with mathematics subjects (if they have any) is a result of a flaw in the design of mathmatics courses rather than any failing of theirs. While they were staring out the window wondering what the world would look like if the grass were purple and we lived among androids, mathmatics education continued along on its deathmarch towards high school graduation. So some of the designers fell behind in mathmatics. Unfortunately, some of their parents or teachers told them (probably with a loving face) that mathmatics wasn't for them, and that was the end of the discussion.
If you tell a child that they can't do something, whether that communication was intentional or accidental the outcome is the same, the child will probably believe you. Several teachers told me that I was no good at math until one teacher, whose name I wish I could remember, actually sat down and figured out how to teach math to me. I got through high school algebra by osmosis. I never studied and I hardly ever turned in any homework. I got a 75 in the class. The teacher had a desicion (one that couldn't be repealed by the way) as to whether I'd go on to take Geometry or Informal Geometry. Geometry was supposed to set the stage for Algebra 2, Pre-Calculus, Calculus and mathmatics courses at university. Informal Geometry was social welfare's version of daycare for teenagers. It is my firm belief that because of the native ability and my in-class boredom that I demonstrated in Algebra 1 that I got placed in Informal Geometry; a decision which I believe I am still paying for. Yes I did some things wrong in that class, but the teacher was supposed to be the adult in the room and do what was best for me.
Fortunately, no one ever told be that I would be bad at programming.
My mom thought that since she and dad didn't have any artistic ability, by logical extension, neither would I. I am trying to undo the effects of that assumption by seeing as the artist sees hopefully with a little bit of help from Drawing on the Right Side of the Brain.
Design as Analysis, Programming as Innovation
Designers think about the association between symbols and businesses and the relationship between words and message to build brands and make intuitive interfaces. What is that if not analysis? Isn't analysis one of the central activities of programming? Programmers find new solutions to old problems. What is that if not innovation? Isn't innovation one of the primary goals of the designer?
Designers have within them the ability to be programmers, and programmers have within them the ability to be designers. I think we all know there is value in trying to place yourself in the shoes of the other person by learning about their discipline. I think this needs to go beyond designers and programmers both speaking the native languages of the web (namely HTML, CSS and JavaScript).
I believe it is better to have teams of people who do not limit themselves to a single discipline rather than to have multi-disciplinary teams.
How can one claim to be a good Systems Architect or a good developer if they don't know anything about usability? How can one claim to be a good user experience designer if they don't understand a thing about the program underlying their interface?
The following quotes are exerpted from Cargo Cult Methodology.
- "[M]anagement demanded that we estimate—and commit to—a schedule and budget"
- "[B]ut 'making a delivery' ... required additional effort. There was no scheduled time for that either"
- "[A]s the months went by, we learned more about the problem, and we had changes requested; that meant more use cases and more effort"
- "[T]here was a lot of whining in upper management about how we'd made commitments, so why couldn't we keep them"
- "[T]ime to market was critical"
- "[W]e hadn't really allocated any effort in the schedule to the actual build and continuous integration support"
- "After a traumatic experience, people are willing to try almost anything to make things better—except actually to change. "
- "A lot of the techniques we ended up applying, like end-to-end "committed" schedules, were things that let management pretend they were in control."
Unfortunately, I'd be lying if I didn't say that most of the projects I've worked on in my adult life didn't incorporate all or most of the previously listed points of senselessness. Theres' a quote from "Days of Thunder" I'd like to bring up here, "Control is an illusion..." Then Nicole Kidman goes on to tell of the foolishness of race car drivers.
The problem is, life enforces the illusion of control until something happens that irrevocably takes that illusion away from you forever. I know because I was in an auto accident when I was 21. An accident I probably shouldn't have walked away from. I now have what's called a retinal detachment in my left eye. I used to be a fairly rough and tumble young man (I used to off road bike and want to jump out of planes). But now I don't even play football at barbeques for fear that a head injury will leave me blind in one eye. The illusion of control is crap. Anyone who believes otherwise is just fooling themselves. There are just too many variables. All of us can intend to grow up to be Astronauts, but only a few of us will make it.
So to all you project managers out there who think you've got life pegged, please throw the expression "Control Chaos" out the window when you are talking about Agile.
Is it really that important?
I've seen too many applications meet their end because people got caught up in the tripe. I've personally lost development time to "Go back and use that font" or "Make it that color blue instead". In my personal experience, managers and customers (and it gets worse as you go higher up the food chain) defer to you on all the really important stuff but try to meddle in the details. Just say no! This happens for two reasons:
- People like forcing demonstrable change on the system.
- People don't like making decisions that could have repercussions (if you live in the U.S.A, thank a lawyer for this).
Since management and the customer are playing the "Look, I'm giving them direction. You, go change the color of that font." game, why not do something prevent yourself from getting the axe when they point the finger at you? Get it out there as raw, unadorned and fast as possible. The management and marketing types are immediately going to frown and look at you. Why? Both groups like hype, pizzazz, garbage that sparkles. Why? Because we as visual beings will buy a shiny turd and stare at it just long enough for the salesman to take our money and run.
The world is getting wise.
Most software development groups care more about making money in the short run than creating a meaningful application for the long haul. The old one-off then we're done mentality of producing desktop shrink-wrapped software is past its time. Most of the programs I use are web based, and I've been using them for years (most of them without paying a cent for them!). Gmail, Google Calendar, del.icio.us, StumbleUpon, Google, Todoist, iGoogle just to name a few. These are the tools that help me be really productive and enjoy my leisure time, and the best thing about them is that they are all still in development. I don't use the M$ stuff unless I am forced to. I still use desktop software, but most of that has been freely downloaded: w.bloggar, Digsby, Notepad++. I am not saying there isn't room for desktop ware, but there are better delivery mechanisms available out there than boxes. The purchase of a shrink wrapped box (or a one-time push to the web) shouldn't be the end of your relationship with your customer/user base.
What you can do as a developer
- Eliminate cruft. If its junk, leave it out. Most people would rather have 10 lean robust single-purpose programs than a piece of junk multi-tool
- Deliver less
- Deliver more often. If you deliver small changes more frequently you won't confuse your user, and you'll look like you are being responsive.
Yes, I'm rehashing old ideas, but bad habits take forever to die.
Incremental and iterative development were talked about before the word "agile" meant anything to do with software. Why do people still chose to ignore these ideas? Because they believe, "That won't work here." Most people saying that haven't bothered to stop and think, "How could we make that work here?" People that argue against changing their outdated ways usually do so out of a fear of getting sued. With that kind of attitude, its more a question of when you are going to get sued than if. The world is constantly changing, the users of software expect the producers of software to change with it. For further ideas on keeping it lean and delivering fast: Getting Real.
I've tried Use Cases and seen them not work. The main reason? They are really heavy handed and developers hate updating them. Customers don't even want to see them. A manager telling me to update the use cases or the functional spec is akin in my mind to someone I don't know telling me to take my medicine. I am one of those annoying developers who is going to ask, "Why am I doing this?" And bad news, if you don't have a good answer, I am going to look at you cross-eyed.
Developers in general (especially Agile Developers) try to remove the pain of really dull or repetitive tasks by stripping down the task to the bare minimum needed to complete the task or by automating it. Believe me, if developers could automate fishing for requirements, they would (an android that can ask those silly customers just what the heck they really need == geek love object).
There's a saying in Agile land, "Do the simplest thing that could possibly work". To me, in the context of getting requirements for a software project, that simplest thing that could possibly work is the User Story. There is a template for User Stories floating around out there that I believe is attributed to Mike Cohn that follows the form, "As a <type of user>, I want to <some action>, so that <motivation>." That's as simple as it gets. You've done some type of user role modeling hopefully to figure out what kind of interface to build (Web 2.0 shiny thing vs CLI). You know what they want to do with it, and more importantly, you know why they want to do it (whatever it is). Understanding this motivation for using the software allows the developer insight into the problem that actually needs solving. This is useful in the case where a story has been estimated and the estimate is not smiled upon. The developer can look at the motivation and suggest perhaps a simpler way of getting the same result.
User stories with estimation also force both the developer and the customer to think about decomposition. How can this be broken down into more manageable pieces? We've got this really pretty user story that took someone all day to write that we've estimated at three months, so what can I do to get the most valueable piece of this cake served first? Compound stories, stories that can be broken down into smaller stories, when given a high value by the customer can artificially inflate the value of the cruft parts of the story. Say for instance you have the following story, "As a job searcher, I want to be notified when a long running search errors out, so that I know to try again." Talking to the customer, they want to put up a toaster on the screen when a search errors out. They also want to make the windows start bar flash if the user has minimized the window. The also want to send an email,a tweet, and a text message just in case the searcher has left the computer. That's a pretty big request. We talk about breaking the different kinds of notification down into different stories. We find out that the toaster on the screen has a relatively high priority and all the other bits have a relatively low priority. So the story with all the bells and whistles notification (3 months to complete) gets broken down and we start work on the most important part first, the toaster (1 week to complete).
Like most other Agile best practices, User Stories need to be used in conjunction with something else, namely acceptance tests. You need a gauge to answer the question, "Is the customer going to like this or not?" without popping into their office every five or ten minutes and saying, "What about now?"
Now about those damn "The system shall..." statements. You hired a developer to do a job, and that job is to implement the application in the best way possible. If you really want that to happen, this kind of garbage shouldn't be anywhere in your documentation. If you are a manager and you really think you know what the best possible implementation for a specific problem is, you had better be bending code on the level of your developers at least half time, otherwise you don't have a leg to stand on. If those "The system shall..." statements are really that important to you, I want you to ask yourself the question, "Is it more important that I deliver business value to the customer, or is it more important that I complete an application exactly as it was planned on paper six or more months before any users got their hands on it."
Ironically enough, after writing that last bit, I read the section entitled "Too Many Details" that is in a catalog of story smells in User Stories Applied. It says, "Including too many details in a story is indicative of placing too much value on documentation and favoring it over conversation." I know that this is going to make managers uncomfortable, because functional specs and Use Cases are designed intentionally to be all-inclusive, to leave no stone unturned. You can leave no stone unturned without a record written of your stone turning in exhaustive detail. User Stories to me represent a kind of targeted documentation that is done after a converstation. A memory cue if you will. Customers don't care about how you implement security in your app, so why are you going to include that in artifacts you use to communicate with them. Bottom line is, if someone hacks the system you built for them and corrupts all their data, they are going to sue your butt no matter what was on a piece of paper you handed them. Developers and technical managers should be aware of non-functional requirements like security, memory management and disaster recovery and should work to achieve those goals, but they shouldn't consume the customer's valuable time talking about it. Those things are best saved for an in house conversation captured in some other place than where the functional requirements of the system are recorded.
I know some of you are asking the question, "But without specifying every aspect of the system, how do I keep the developers from going off on some crackpot coding crusade." My answer to that is the notion of never coding alone. As a developer, you insure the viability of your product my looking over everyone else's shoulder and actively encouraging others to look over your shoulder. I know it requires a thick skin. No one ever said going Agile was easy. It is a heck of a lot easier to stay Agile than it is to get there. This mutual code inspection can be done through peer programming, code review, both or etc. (maybe static code analysis if it is not misused). Now, a word of caution. "Criticize ideas, not people." I pulled that straight out of Practices of an Agile Developer. We are all sensitive, and none of us like having our mistakes shoved in our face. So if you want to keep your developers from burning you in effigy, make sure code review stays amicable. None of us like the blame game, it is counterproductive, so keep it out of the development shop. Let me go on to reassure you that code review and peer programming do eliminate those capricious mind wanderings of the artist-programmer, because I am one and my fellow developers keep my feet wired firmly to the floor. I have also had many occasions to reciprocate.
If you've ever been a programmer in a bureaucratic environment, you've surely thought of yourself as the spawn of the red-headed step child and the family mule.
Performing heroic acts in a bureacracy is patently a bad idea. Why? Because if you've jumped the Grand Canyon on a motorcylce once, surely you can do it again or anything else for that matter. The bureaucrats are only half the problem here folks. Our damnable need to please (or to not rock the boat) is the other half of the issue. You're a programmer right? That must mean you can do anything. Time to start disabusing some folks of some faulty notions. Expectation management is a must. Every boy or girl programmer out there wanted to be Superman or Wonder Woman growing up right (or some other ridiculously clad character with amazingly unrealistic physique)? Why, because we were/are geeks. We were/are social outcasts because we were smarter or more creative or something than everybody else and they loathed us for it. Time to grow up and put the cape away.
While we are at it, we might think about passing on some understanding about what it takes to do our job, because the higher ups haven't a clue, and its more because we over-respected the pecking order and never told them just how much it takes to do what we do than them being self-absorbed.
Secretaries don't get enough respect. They keep the world from being overrun by incompentent managers. They don't get appreciated enough, why should we? Why, because for the most part, secretaries are support personal. We are production assests. You can't speed up the auto line any more that it already is Mr. Ford, and it is already going too dang fast. Managers can see into the daily lifes of their secretarial staff and at least try not to push them too hard. As far as most of them are concerned, designers, IAs and developers might as well be performing black magic.
What is grossly needed here is some education about what it takes to design web pages, architect information and build web apps, and no Mr. Boss Man I can't, "Just build one of those CMS thingies from scratch." At least not for what you pay me. :)
Documents don't kill understanding. Documents in our American culture kill understanding.
Why do people who specialize in bending words forget to transfer meaning?
The problem with lengthy requirements documents are
- They never tell the whole story no matter how much you write
- The users of these documents (programmers) never ask any questions because its all right there in the spec
- The writer of said document never questions if his intent was understood because its all right there in the spec
Conversations leading to acceptance tests are better for specifying a project because:
- Conversations don't inspire us to use 25 cent words that even we are fishy on the meaning of
- You are more likely to ask a question of a person than you are of a piece of paper
- Understanding is best reached through a series of questions asked and answered than a document read over ten times
Dan say's its ok to use functional specs and use cases to organize your thoughts. I agree with him if these things are for your eyes only. I wasn't born in 1950, and I haven't watched "Tron" enough times to be able to think in terms of "the system shall..."
In Joel's perfect world, functional specs can be used to communicate design. Joel, I think you may be the only person on earth who can pull this off.
I like user stories and acceptance tests for communicating design because:
- They are light-weight enough not to kill conversation
- They allow you to focus on only what matters right now
Aren't there published studies to the fact that most human brains can only deal with 3-5 pieces of information at a time?
This does not mean that I am advocating throwing out design and design review. What is does mean is that I strongly advocate doing Just In Time Design.
In the Agile thought-space, Big Up Front Design (BFUD) is a four letter word. There is a reason for this.
Many times people who envision projects (usually the guy with the biggest wallet unfortunately) don't realize that they don't know everything. More to the point, they don't know how little they actually know about the end user. So they envision the initial requirements for the system, and they boil them down into finer and finer grained detail, until they have something that is implementable. The problem here is the "grand envisioner" never once left his office to go talk to an end user. He never once drew up a wireframe on a paper napkin from a McDonald's bag on the job site of the end user.
As a personal rant to designers and developers everywhere, get out of your head and get into the real world!
If you don't ever meet the user in their office, you are doing the developer equivalent of making a custom tailored suit from fuzzy photographs from a single vantage point. You need to get into the room with the user and size them up if you are going to make good software.
So alot of people adopting Agile see design as a dirty word. Why? Because their formerly waterfall way of doing things didn't incorporate the use of an HCI specialist or user interviews, or the design was too cumbersome. Waterfall, like anything else, can work well, but only if done correctly. The danger with waterfall is of course that the climate will change and what was agreed upon won't be what is needed when it is delivered. This can happen even if the waterfall organization has a HCI team on staff. Why? Because the full beast as it was envisioned may take two years to deliver. A lot can change in two years. Users needs can and will change while you are building software. Agile tries to embrace this. Designs that keep work from getting done because of their inertia are just bad in principle.
I've had a lot of personal experience with people having issues with Agile design (especially technical managers and system architects). Why? Because it is not the same as not-Agile design. Not-Agile design is a thought exercise that only the really cool people get to do (the guy with the big wallet always thinks he's cool-makes me wonder if Bill Gates has seen a picture of himself lately). Agile design is more of an exercise in communication that all parties involved can and must participate in even the lowliest developer.
Good software is organic. The Mythical Man Month says as much. So how do we know when to stop adding fertilizer and when to stop pouring the water? That's simple, when people stop being interested in new developments in the process, or when you start to experience diminishing ROI. Limiting scope is a bogus concept if you ask me and usually amounts to making an irreversible decision (because that scope limitation is usually expressed in a contract, and what's on paper might as well be set in stone in a corporate environment, that's why some people advocate ripping up story cards after the iteration, but I digress..).
Prioritization should limit scope, not a decree on some piece of paper. Once again we must remember that Agile is here to embrace change.
So what needs to be in place for Agile design to happen? Here's my answer:
- You must be able to communicate effectively and entertain ideas you don't like.
- You need to get the "envisioner" to stop trying to own the design after the initial idea has been hatched.
- Don't even get me started on why feelings of individual ownership are bad.
- You need at least one representative end user on your customer team
- You can substitute near continual feedback from beta testers or other representative users for this.
- You must deploy early and often
- It is better if this deployment is live, but a private beta should suffice in most cases.
- The old school designers need to let everybody else play
- I have personal philosophical issues with the term "System Architect", but if you have one they need to understand their new role is more of a commentator than a director now. A kind of tough sell if the architect is your boss.
Need some guidance? Go read User Stories Applied or a book on Agile Modeling then figure out what works for you. I personally like Joe's idea. A week for user acceptance testing in each release might not be ideal, but at least it lets the people doing the acceptance testing know when their presence is absolutely required.
A colleague of mine was planning on setting up a calendaring system for their department, and he was wondering if they took the trouble to set it up for their department if all the other departments would want to use it.
All the different departments have their own flavor of the month in terms of langauges and frameworks. Some like PHP and Zend. Some like ASP.NET. Some like Python and Django. The list goes on.
All of us have seen a department re-invent the wheel and do something another department has already done, but their are reasons that this happens.
I have been doing a lot of reading lately about code reuse lately. All the articles focus on the same thing pretty much:
- Code reuse in the small (UI frameworks and widgets and other industry wide things) is possible and most people do this.
- Code reuse in the large is largely an unsolved problem.
Another point these articles bring up is that code cannot be reused easily or effectively unless the code with the intent of being reused in mind. That is, the code has to be built to be reused or restructured and refactored to be reused. Business logic (domain model) is mostly un-reusable because it is designed with a specific application in mind and not designed for re-use.
The articles also go on to point out that writing a component to be reused takes significantly longer to write than a component for one time use (anybody who's tried this knows it to be true). They also say that you have to reuse code four to five times to get the payback on writing the code to be resusable.
Some of the articles go on to talk about the newb developer phenomenon. Who has come into a development shop, been tasked with maintaining an old system and written a greenfield project from scratch to do exactly the same thing? Everybody should have their hand raised at this point.
The reason for this is threefold:
- The old developer did a really crappy job expressing the intent of the old code within the code itself.
- The new developer did a really crappy job trying to understand the intent of the old code.
- New code is more fun to write than maintenance patches for old code.
There are also other possibilities that may not apply to all projects:
- The customer did a really crappy job specifying acceptance tests for the old code (or probably did not know they needed acceptance tests)
- The developer didn't hold work on the project hostage until they got some acceptance tests
I feel like I need to qualify the last point. If you are doing Story Driven Development, you don't need to have all the acceptance tests before you start coding, but you should have as many as the customer team can think of at the time that clarify the story and add business value.
Another colleague of mine has been doing some investigation into code review for our group and one of his findings was that the two biggest reasons for runaway projects (projects that never reach acceptance or are never delivered) are:
- No acceptance tests. If you don't know what the desired end state is, you don't know when to stop writing code.
- Bad estimation on the part of the development team.
The reuse problem is a double edged sword:
- Managers (especially those with no prior real world experience developing software) expect the code that their subordinates write to be infinitely reusable with no extra effort.
- Developers (especially the younger ones, I know because I was a young developer once too) write code for one-time use. This is usually because the customer wanted the thing yesterday, and because rapid development is fast, fun, and can give you a huge ego boost.
I think services might be the exception to this rule (one must keep in mind that services are designed for reuse almost by definition). Look at how many people use Google Maps.
Knowledge is the most reusable component of software application development. So get out there and learn something from each other. Go to a .NET or a PHP User's Group meeting in your area. If one doesn't exist, start one. We really need to start learning from the mistakes of others and pick up on their technology (if not protected by IP, which is why I think most toolkits and frameworks should be open source, but that's another story). We need to do these things so the defacto standard for web development doesn't stay at writting a shallow layer on top of a database forever.
About a year ago, I think I personally wrote off estimation as a dead waterfall practice and a pipe dream (not to mention a waste of time). To me, estimation stunk of something to keep the lawyers at bay. You lost me right there, but now I am back. Estimation is important to keep the customer happy, not the lawyers. My boss kept telling us to estimate stuff, but we kept on shirking his task. We had adequate enought time pressure to allow us to not think about how long the tasks at hand were going to complete. I think the problem there is that seasoned manager (and enginner) doesn't translate into young artist, but that is a story best told over a frosty beverage.
Giving a requested feature some thought and decomposing into estimatable chunks is an essential part of Scrum. I accepted this at face value when I read "Scrum and XP from the Trenches". Sadly though, I never really went on to understand why (or to really start doing decomp. and estimation). Recently we gave our customer team exactly what they had asked for, but at a price they weren't willing to pay. Wait a minute! Isn't that what Agile is suppose to prevent? We were close to being Agile but not quite there yet (not sure if we are yet either, but we are a heck of a lot closer). The development team and the customer team both learned something that day. The customer team learned that in order to get what they really want, they have to be more vocal. Written documents and emails alone aren't going to cut it. The customer team actually needs to sit down with the development team and use the app! The development team learned, you actually have to hold end of Sprint demos! The development team also learned that you have to decompose features down into what is really needed to deliver business value. That decomposition should turn into estimates that the customer team can use to adjust the scope of work (re-size the feature or break it up into pieces).
This really cemented in my head when I started reading User Stories Applied by Mike Cohn. Story Cards and their accoutremonts (estimates, priority and acceptance tests) are tools for the customer team to decide what to build when. You as developer are the facilitator of this process. Users don't know what they want. We all know this. That doesn't mean they don't know what they don't want (this is a fun dinner time ritual for the wife and I, I suggest eating establishments, she shoots them all down). The customer team should include a representative user or ten or at least a proxy for a representative end user. You facilitate the design process by starting the conversation. You all already know big picture what this thing is supposed to do at your first meeting. You need to decompose your epic story into smaller estimatable stories. If you have a large story that deals with creation (entering a description of a house perhaps) Mike Cohn suggests that breaking such a story down into logical groupings of fields that will fit on a single screen is acceptable (think tabbed form here people). You can get the ball rolling by doing Agile Modeling (I admit I am a beginner at this at best, and haven't read the book yet-although the book is in my satchel) by drawing a really watered down version of your main value object on a white board (a house perhaps) in a psuedo UMLish diagram. Once you start figuring out the properties of this main value object, just stand there at the whiteboard with dry-erase marker in hand and watch the magic happen (don't forget to keep diagraming though). This is called Brain Storming. You are trying to work out your ubiquitious language and the domain for your app. You just helped the customer team overcome a hurdle. You just started listening to their needs in their language. The hurdle was really a stereotype, and that stereotype is that all programmers hail from Vulcan and don't speak English.
Once you get past brain storming and are into release planning, you can keep Agile Modeling and turning the results of those discussions into User Stories. Once the User Stories have been sufficiently decomposed to estimate. You have all the developers come up with an estimate for that story. Then they all give their number. While they are haggling about the number, the customer team will realize the scope they had in mind is not what these developers are talking about at all. Developers usually want to make it ten feet tall and bullet proof. At this point, if you are a customer teamster, please don't haggle quality assurance with development, just reduce the scope of the story until it is what you actually need (better to get developers to give up on the ten feet tall thing than the bulletproof thing, for you, them, and the sake of your business). Or better yet, break the story up into parts if it is a complex or compound story and assign each new story a priority accordingly.
If the customer team has a good bead on what the end users want, this decomposition and estimation will help you deliver the highest value as soon as possible. Isn't that what we all want anyway?