Working effectively as a team of one: Five tips for front-end developers on Agile teams

Brian Dillard, Monday, August 11, 2008 @ 5:33 pm

Most UI engineers - a.k.a. front-end folks - have worked in environments where they're a shared resource of one person. I often did so early in my career, when I played "webmaster" to a team of writers, editors and visual designers at various online publications.

Now that I'm the Ajax lead at a small, Agile software development firm, I'm no longer the only technical person in the room. But I'm still just as specialized. It's not that my JavaScript, CSS and JSP skills are any more important than somebody else's SQL, Java or Swing skills. It's just that I'm a team of one, so utilizing me effectively takes a little more planning. Everybody at Pathfinder wears multiple hats, but I was hired specifically to wear the same hat all the time.

Many projects at Pathfinder seek my input, but my attention can only be parceled up into so many chunks. I can't serve as an actual development resource on every project. Over time, I've realized that the following strategies help me deliver the value I need for my company:

1. Teach them how to fish

   This one's a gimme, but it takes discipline to stick with it. It's so easy to say "yes" when you're asked to do something you've done 100 times before and know how to do quickly. You'll make project managers and clients happy, but you're really shooting the organization in the foot. If you're a shared resource of one, you should do almost no solo development work. Every "yes" should be a "yes" to pair programming only.

2. Get involved in the process

   If web applications were cakes, Ajax wouldn't be the frosting, it would be the baking powder. You can't just layer it on at the end. In an Agile environment where few projects necessitate a dedicated front-end resource, it's easy to forget about UI concerns until late in the process. By then, prior decisions can make Ajax components far more difficult and time-consuming to implement. One-person UI teams should try to keep tabs on every project in the pipeline. Demand to be included in initial requirements-gathering sessions and check in during as many subsequent iteration kickoffs as possible. By making recommendations early and frequently, you'll save lots of time and money later.

3. Don't start coding without some sort of road map

   Iterative development is great, but it's harder on the front end. The user interface is the layer most likely to change dramatically based on client feedback. But UI code is also expensive to produce. Prototypes, wireframes and proper business analysis should all come before a single line of JavaScript gets written. Comps and interaction plans are easy to throw away. A thousand lines of Prototype classes and jQuery plugins, not so much.

4. Start simple, stupid

   Progressive enhancement can actually help with #3 above. On early iterations, build simple HTML controls rather than complex Ajax components. Make sure the application is well factored into individual screens and features before you enhance your first-pass markup into complicated widgets. If you're following the principles of progressive enhancement, your initial "dumb" markup will continue to serve users with screen readers, low-tech mobile browsers or draconian IT-department JavaScript restrictions. Nothing will get thrown away

5. Learn the entire stack

   User interface development has finally earned recognition as a discrete discipline of its own. Don't let that dissuade you from learning new technologies, especially ones far removed from the UI. Write a Rails app from scratch in your free time. Learn some hardcore PHP plumbing instead of just futzing with WordPress tags. Rewrite one of your custom JSP tags in pure Java instead of JSTL. Install MySQL and have a field day. In short, learn to be a more flexible, less specialized resource. The more places you can be plugged into a project team, the more likely your company will eventually hire additional front-end resources. Then you'll no longer be a shared resource of one.

How about you, front-end readers? How do you make sure you're getting used effectively in Agile environments? Let us know in the comments.

agile ajax

Comments: 1 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. 

   You pretty much hit the nail on the head. I’ve been a ‘team-of-one’ for every development job I’ve had up to this one.

   We’ve still yet to put our developers, both back-end and front-end (I’m both really), into the process early, but with constant determination the project managers are learning to bring us in earlier and earlier.

   As you stated and which can not be stressed enough, learning the entire stack is the single most important thing. There is no doubt that should you ever need to move to another company or position that this will help you along.

   The only addition I would add is, though this ties into #1, is to have great people skills. Because you’re the ‘go-to’ person for a lot of things, you need to learn how to not only manage yourself and your projects, but people too. Keeping the Project Managers of Doom happy while keeping yourself less stressed is the only thing that has saved my sanity through the years.

   Comment by Andrew Herron, Tuesday, August 12, 2008 @ 9:19 am

Leave a comment