When developing software using agile methodologies, one of the main goals is to keep the customer close. If the customer is fully engaged in the process, they can’t be surprised by results and they can’t complain about not knowing what was going on. Keeping the customer close gives you and them a lot of confidence in your releases.
I’ve tackled several projects this way so far, and a truism has distilled itself out of my experiences: as far as the customer is concerned, the screen IS the application. When the customer shows up in the team room on day three of an iteration, they won’t have a clue when you tell them that all the programmers have been working in the “persistence tier” or that you’ve spent all your cycles on “end-to-end security”. If there isn’t a screen to bang on, they don’t think you’ve been working.
Many development teams I have been involved with have put off working on the UI until one of the final tasks. They believe either:
a) UI development is easy, and can wait until the end, or
b) You have to nail down the backend before you know what the UI should do
In the face of agile development, these rationalizations are just plain wrong. The UI has to happen up front, and concurrent with everything else. The customer, to stay engaged with the team, has to have something experiential to latch on to. For them, code doesn’t cut it. The database schema is ephemeral. Design documents are worse than useless; they imply that you have spent time on something other than code.
So on my latest project, the team decided that on day 1 of the first iteration, we would generate something tangible. Even though that has led to the overall slowing down of the iteration, the customer has been really energized by seeing a UI so fast. For them, it is radically different than any other software development experience they have ever had. Success is entirely defined by being able to interact with the product.
Never let the UI take a back seat to what you feel is “more important”, because what’s important is making your customer happy, and better yet, excited. And the screen is both the app, and the way to their hearts.
NakedObjects
You might want to check out NakedObjects (http://www.nakedobjects.org). It's a Java framework that automatically creates a UI for your application.
The whole book is available online at
http://www.nakedobjects.org/content.html
Deliver smaller, but complete, end to end functionality in each iteration.
I'm a big fan of the Scrum approach of pushing, incrementally, bits of functionality that are end-to-end complete, even if it's only a small part of a larger application.The UI by itself is kind of disappointing to the customer if it doesn't do anything. Delivering only the UI or only the backend, while it may fit a layered set of developemnt teams, really fails to make the customer feel any better about what the software developers are actually doing. If you find that teams are waiting for one layer to be completed before beginning development on another layer, it may be time to look at reorginizing your development effort into more cross-functional teams that can deliver pieces of business logic along with corresponding user interfaces within a single iteration.
Wrong Wrong Wrong
The UI may be important but it is only window dressing to the backend. Any good programmer knows that. What's the point in making a snazzy UI when the backend sucks? The speration of interfaces from engines has been considered good coding for years. When did that change?
The backend should be prefected first. The interfaces can come later. Otherwise you'll spend time hacking the interface into an unusable form while the backend is being corrected.
You make my point perfectly
To *you* it is only window dressing. To your clients, it is all they ever interact with. What I am saying is that *if* you are pursuing an agile development plan, then you can no longer work this way.
If, however, you and your customers are comfortable with old-style waterfall development, then you can happily live and work this way all you like.
My customers would rather see something now, and have it change later. We develop the front and back ends simultaneously, and they get to see the results of the development process in real time instead of waiting 9 or 12 months to finally get to interact with the system. So far, it is working out.
And bear in mind, I'm not talking about making a super whizbang UI; I'm talking about giving them an interface to the backend code so they can see it in action. If you don't provide your customers something they can see and touch, then for them, you haven't actually done anything.
You make my point perfectly
If you create a GUI straight away, aren't you running the opposite risk that the customer thinks you are done when you've only got a stubbed persistence layer and no security? :-(
Yeah!!!
Finally someone outside of the Fusebox community has seen the light!
Justin, I'm with you 100%! For the last 2 years this is the only way my company builds applications. Clients can't make good decisions from UML diagrams or database tables. But they can make good decisions when they see a form for entering information or a tabular list of results etc. It doesn't help to have a rock solid backend if the overall software doesn't do what the client wants.
You may want to check out the Fusebox LifeCycle Process (FLiP). http://www.fusebox.org/index.cfm?fuseaction=methodology.steps
You make my point perfectly
This would only happen if you start working on a project without discussing your process with your client.
We have found it's a little more effective to do a few minor things before starting with the UI.
1) Define Personas/Goals. i.e. who will use the application and what are they trying to acheive.
2) Define a Wireframe version of the UI based on acheiving the Persona's goals. So describe each screen in plain English text. It's just a fast way to define the flow of the application.
3) Then build the UI for each of those screens in the wireframe. This is when the discussions really get going with our clients.
I'm telling you Chris this process works like a charm. Once you try it you're going to feel like you've been let in on a big secret.
Deliver smaller, but complete, end to end functionality in each iteration.
There is a much bigger reason for defining the UI first. Scope Creep. Think about this...
Scope creep is a natural process we can't avoid. So instead of trying to avoid it, we should encourage it when it's cheap to deal with. The less code that is modified because of a change request, the easier the change is.
For example, my company primarily builds web applications. If our clients asks for a change on a finished, working version, we have to change, HTML, Coldfusion, SQL and potentially the database design. Not unreasonable, impossible or even all that hard, although some changes at this stage are time consuming and cause unexpected errors.
We find that our clients ask for changes only after they've seen the interface. So when we show them the interface within the first week of development, they start asking for changes. We love changes this early because all we have to change is HTML.
Right Right Right!
Which is easier:
1) Architect the backend
2) Build the backend
3) Build the front end
4) Test it
5) Client asks for a change
6) Change the Architecture
7) Rebuild the backend
8) Rebuild the front end
9) Test it
10) Client asks for another change
11) Change the Architecture
12) Rebuild the backend
13) Rebuild the front end
14) Test it
15-1000) Rinse and Repeat until client says you're done or runs out of money
1001) You're done, yeah!
Or:
1) Build the front end
2) Client asks for a change
3) Change the front end
4) Client asks for another change
5) Change the front end
6-250) Rinse and Repeat until client says you're done or runs out of money
251) Architect the back based on the front end
252) Build it
253) Test it
254) You're done, yeah!!
1/4 the steps. I'm saying this from experience too. I've done this both ways and for the last 2 years I've done the UI first. It works.
Wonderful Article
I work in an environment best categorized as "extreme" - short development timeframes, drop-dead delivery dates and a full pipeline of work always creeping up from behind. Under these circumstances, major changes made near the end of a project can (and almost always will) domino into an unmanageable mess of scheduling conflicts and broken client expectations.
Agile development and, very specifically, early delivery of the UI has to a great extent solved this problem. Not only are clients able to identify critical changes to functionality sooner, but they are, as you have so eloquently said, more energized and excited about the work.
And of course, a terrific side benefit is that when the client is energized, the development team is energized.