+972 52-548-6969
Social Engineering in Software DevelopmentImitating Actions
The absolutely hardest thing in most projects is to (and I am going to be blunt), to get the customer to shut up and let the team start working. I have been in several projects where the actual move from blah blah talking to actual doing was a painful and drawn out process.
In one particular example, I was brought on as a team lead for a team that had 4 months to produce a system. I was stunned to discover that the last two years were spent in meetings on top of meetings on top of meetings. At some point I flat out abandoned the spec, forced got management approval to talk directly with the users and started supplying them what they wanted. I still consider this to be a horrible project, but at least we shipped.
I found several approach that can facilitate the move from talking to doing. The first one, and the one that I prefer, is to actually start building the software. Now, I don't refer to building the actual production software, but to building a spike of how things are supposed to work. Show it in the next meeting, and I can almost guarantee that the discussion is going to shift radically.
When you put something in front of people, especially since in spike mode you can get things done really fact (no code quality, no error handling, pure nasty coding). In several past projects, I have used this approach to leap over the "let us just get started" hurdle.
The main issue is that the business would like to really understand what they want to do, before asking the developers to do so. But since many things are fixed already, that is, the general concepts are already known, and the devil is in the details, we can start painting the outline of the system in broad strokes and fine tune it later.
The idea is to push the business into that mode. And spikes get us there quickly.
Another method that I have started to use lately (which is even easier than spikes) is the use of UI mock up. Using a tool like Balsamiq Mockups, this is ridiculously easy. It also serve as a great spur to actually starting to do things. Instead of getting mired in details, I can get a pretty good picture of a vertical slice of the application, and go away and actually implement that.
Here is a mock up for the landing page for the NHibernate Profiler web site:
You can see the real thing here. As you can see, it isn't the same at all, but I think that we can all agree that there are marked similarities between them.
This mock up took about 3 minutes to build, and we did that while on the phone and with screen sharing. But it meant that we talked about something concrete.
When you are starting to talk in concrete terms, you have already much closer to getting starting doing something real.
Those are just a few example of initiating actions, actions that can get you to move from the talk talk talk phase into the get things done phase. It is important to make this move as soon as possible, for several reasons. Not least of them is that we value working software over comprehensive documentation and lengthy discourse.
More posts in "Social Engineering in Software Development" series:
- (05 Feb 2009) If it doesn't hurt, it doesn't matter
- (10 Jan 2009) Imitating Actions
Comments
"The absolutely hardest thing in most projects is to (and I am going to be blunt), to get the customer to shut up and let the team start working."
LOL. You have a way with words - so eloquently put.
Hi Oren,
How do you get over the hurdle of : "What you have shown me is what I want, why do I have to pay for another 1/2/3 months worth of work? Just give me what you have shown me"
When you have a level of trust, its easier, but have found this p[roblem over and over when showing customers "proof of concelpt" stuff.
That is why I like mockups so much, it is very explicit that it is not the real thing.
For spikes, I make sure to mention that this is not real code several times, and I also make sure that the UI reflects it.
A big note saying: "this is not production ready" and some red borders around things do wonders for the feeling that this is not the real thing
I'll never understand why wire framing is not promoted more as probably the best way to communicate with clients when requirements gathering for UI applications.
Agile always talks about getting feedback quickly, if you are developing a UI application, then what quicker way to get feedback than create a wireframe that communicates better than any text and certainly better than any user story what the system.
I am talking about using a good wireframing tool. We use ( www.axure.com/tourOverview.aspx) which is certainly not free but really good. You can create a basic functioning clickable wireframe with drag and drop. It aint cheap but it works well.
I just don't get why this medium is not promoted more.
Wireframing is great, but we've had limited success using at our company. One of the major downsides to wireframing is what Heinrich mentions, and that is it's hard to convince people who are visually motivated what the difference is between a wireframe and a working model. The axure tool you linked has presentation level functionality, and I feel that's too much. They won't even understand the difference in time it takes to spend coding the real presentation layer using AJAX and the like to connect to the backend services, versus what you've just shown them.
A mockup tool like Oren posted would solve many of those problems without having to make explicit declarations about the intent of what you're presenting, and no explanations needed. It's a lot easier, and quicker than wireframing, and anytime you can avoid having to spend time (cost) explaining the difference between wireframes and production code to someone, you're going to notice a significant amount more focus from your client on the intent of the design specifications, and less time with them trying to understand conceptual differences.
Then again, I could just be dealing with very difficult clients ;)
Hello Oren,
thanks for this nice post actually the most hard part we all face, but sometimes wireframe is good with experienced customers and sometimes it's a terrible mistake.
as User interface designer i think making efforts and showing the client a Graphic user interface before starting the development cycle is much better than show him wireframes!
the thing is customers are not equal you have to know whom you are talking to and make him very comfortable in your meetings and convience him to start the work and getting things done.
Mohammed
Alternative GUI prototyping tool.. Open Source and free...
http://www.evolus.vn/Pencil/
Pencil Project.
Comment preview