Agile Zone is brought to you in partnership with:

Mike is a certified PMP project manager and a certified ScrumMaster. Mike was involved with the creation of the DSDM Agile Project Leader certification, holds this certification at the Foundation, Practitioner, and Examiner levels. Mike was named an honorary member of the DSDM consortium and served on the board of APLN and the Lean Software and Systems Consortium. He currently co-leads the PMI Agile Community of Practice. Mike is a DZone MVB and is not an employee of DZone and has posted 130 posts at DZone. You can read more from them at their website. View Full User Profile

Agile and UI design

09.16.2008
| 3814 views |
  • submit to reddit

A few days ago, one of my Twitter buddies asked me to explain how the UI designers fit in on an agile team. I have some experience working with dedicated design teams and user experience folks so I thought I'd take a stab at his question and share my perspective. Once I finished my note it seemed like it might make a good blog post. I'd be interested to hear what you guys think about my answer.

Here goes...

Just to set a little context... my friend asked me to explain the role of the UI designer on an agile team. He explained that they were creating user stories but were not sure how to incorporate the UI designers into the process.

The unfortunate thing about explaining agile is that there is no one right way of doing things. There are principles that I like to see teams apply. Agile is all about creating situationally specific strategies. You just take the principles of agile and apply them the best you can given your constraints.

That said.. my friend seemed to be on the right track. They were creating stories with using a typical agile patterns... "As a user, I want to be able to create a new account, so that I can do X". The principle that I encouraged him to apply is that the story is small enough to be done in a single sprint, all disciplines are involved in implementing the feature (including the UI guys) and at the end of the sprint, it is potentially shippable... in other words, done.

What would that ideal look like in real life? During the sprint planning meeting, the team would collaborate around a whiteboard on what it means to be able to create a new account. The developer might talk about what methods might need to be created. The QA engineer would discuss how it would be tested. The UI designer would be involved helping the team understand what the screen would look like. The product owner would weigh in on the business value and keep the implementation discussions in check.

At the end of the discussion everyone is on the same page about how the feature will be built. Since everyone is on the same page, the UI person can go off and start iteratively working on a mockup (if necessary), the developer goes off and does code, maybe the QA person goes off and starts test planning. If the team is pushing new code up every day, continuous integration in other words, everyone gets to see the evolving product and respond to it.

Just like the code evolves, the doc evolves, the plan evolves, the product evolves.

The typical response from dedicated designers and QA people is that they want to be able to do the work once and for all. Operating in this way feels like waste. I encouraged my friend to keep in mind agile principles like barely sufficient documentation, simplicity of design, deferring decisions to the last responsible moment, and constant refactoring... The key is to keep the focus on working product and off comprehensive documentation.

Just like the dev team will refactor often, the supporting team members may have to refactor as well.

But what if everyone is not in the same room, on the same team, maybe not even in the same company (external customer)? You apply the same principles and adapt them to your environment. I have seen teams do just enough UI design in the previous sprint to keep the dev team moving in the subsequent sprint.... This makes things more complicated and creates more dependencies than an pure agile approach.

When teams take this approach, I liken it to the product owner grooming the backlog and specifying requirements in advance. The UI mockup becomes like a requirement to the dev team.

As a team you just have to decide how much time and energy you want to invest in up front design. You can do agile practices with an up front design, it just causes you to do even more rework if you want to change anything. It really depends on the uncertainty of your market. If things are prone to change, invest less up front. If things are stable, you can invest more.

Originally posted on Leading Agile

Published at DZone with permission of Mike Cottmeyer, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Frank Silbermann replied on Wed, 2008/09/17 - 9:53am

Agile development processes are based on constant refactoring, and refactoring is very difficult if you are not using an object oriented programming language.  That's why the first agile process, XP, was invented by Smalltalk users.  Agile processes simply would not have worked with COBOL, Fortran, PL1 or classical Pascal -- hence, the coarse-grain waterfall method.

Refactoring user interfaces is very difficult if you build your interface using a WYSWIG tool that generates unreadable (i.e. unfactorable) code.  Refactoring is even more difficult if your GUI code is built in a notation that is not object oriented -- e.g. HTML, CSS, JSTL, XML, etc.

If you want your interface developers to be part of the agile process, then you need interface developers who write code by hand using an object-oriented programming language.  For a desktop application they could do that using Swing.  For a web application they could do that using Wicket, GWT, Echo, or (maybe) Tapestry.

Or, you could just bully them into redoing most of their work almost from scratch, iteration after iteration.  Tell them that it doesn't have to be pretty yet, just functional.  Expect them to be unhappy.

 

Mike Cottmeyer replied on Thu, 2008/10/02 - 7:23am

Thanks for the comment Frank. 

 Just a couple of quick thoughts.  I agree that it is easier to do agile wiith OO languages but I have used agile tecniques with Cobol programmers.  Without going into a lengthy explanation it really comes down to how you have architected your system.

 Regarding the main point of this post... I dong consider myself an expert on the topic and was just sharing some ideas that have worked for me.  I would defer to Jeff Patton on the subject at the following URL:  http://agileproductdesign.com/blog/   

john green green replied on Sun, 2009/12/06 - 11:36am

The QA engineer would discuss how it would be tested. The UI designer would be involved helping the team understand what the screen would look like. The product owner would weigh in on the business value and keep the implementation discussions in check.
nike china shoes

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.