molly.com
Friday 20 May 2005
Problem Solving in Web Development Teams
ONE AREA OF WEB DEVELOPMENT that continues to cause frustration is how to solve problems in a team work environment. While great ideas have come to rise, particularly from AdaptivePath and from Kelly Goto, there seems to be some disconnect in terms of creating some kind of industry-wide convention upon which to focus team-building and problem solving techniques in the workflow and project management aspect of developing Web sites.
I propose that we are frustrated because we haven’t come up with anything but vague processes loosely based on print or graphic design workflow. At least in theory. But give people the opportunity, and they’ll naturally find a process to solve problems that naturally merge at least three areas of influence: print, programming, and administrative/management.
The other night, Aaron Gustafson and I came up with four real-world development scenarios (corporate merger; educational institution being sued for accessibility issues; ad agency; and government intranet with mass document management concerns) for our Joliet workshop attendees.
We then set up individual team roles according to each scenario and a specific challenge for each team to solve within a certain timeframe.
The workshop attendees broke up into their teams and set up a strategy for accomplishing the goals. After the hour, the teams presented their results, describing any roadblocks along the way, and what they were able to accomplish.
What emerged in each case was a combination of techniques from at least each of these three areas, and quite possibly a few others I haven’t yet defined.
Despite the differences with each group situation, with the type of team members, and with each challenge, the natural emerging methods were ultimately similar and in fact not as disparate as one might imagine.
Programmers and developers suggested ways of managing code and server issues early in the game. Content and design folks offered insight into how to solve the ever-existing issues in organizing and receiving content. Managers and adminstrators looked at overarching goals and workflow, and how to manage team members as well as stakeholders.
What’s clear is that there is a need for us to look to multiple methods in order to come up with some kind of convention that we can all look to as a means for problem solving team challenges.
How do you work to solve problems within team environments? What pitfalls seem to continually occur? What strategies, and from which skill areas, do you employ to improve workflow and manage projects effectively?
Filed under: web design and development
Posted by: Molly | 08:58 | Comments (13)
Molly,
I read an excellent article by Martin Bauer on SitePoint earlier this week which talks about some different methods that one team tried. It is worth a read.
http://www.sitepoint.com/article/successful-development
Best Regards
Mike
There are some days where cultural differences can influence the development process.
I can specificially remember an instance of how we should develop a typical ’sort order’ function which filtered through College Athletic Department Coaches. One guy figured “ah, we don’t need a sort order, we’ll just sort them according to their database ID or Last Name.”
On the flip side, there was something lost in the american appreciation for hiarchy. We wouldn’t want “Adam Adell – The Ball Boy” to be placed at the top of the list, and “Zachary Zulu the Head Coach” to be placed at the bottom.
When working with other designers, some have felt that “I messed up their designs” upon putting it into html format…when it was usually something like changing the typography. I had to tell him, you never use anything but arial, I was just changing it up.
Development ‘teams’ in general are interesting though.
As for a good outlook, I like the feedback you could receive. You’ll never lack a second opinion. (which, of course, could have its downfalls as well).
At ad agencies, many of the project managers were originally in print, so they have a hard time grasping how and when to implement IA and QA into their timelines. They realize that software and Web projects have a much longer development cycle than print and are frustrated by not knowing how long to estimate for projects. A good solution is to host a series of internal seminars to explain what it is each department does and how they fit together. Evevntually the hand-off process between departments will be smoother and that the PMs will finally “get it”. [crosses fingers]
Dave’s comment above seems typical of many situations where there has been a communication breakdown. Design and code teams complain bitterly because the PMs don’t get it, and the PMs complain because the teams won’t communicate well or treat them like they don’t get it.
These need to be solved by education and by team-building in itself. If your team works well together they are going to be more likely to attempt to sort out problems as they arise and then the project isn’t in danger of slowly breaking apart. Once you have a team who understand each other’s roles then you can look at creating an industry-wide convention with workflows if you want to, but the core issue isn’t something you can flowchart I don’t think.
The Zen of CSS Design by Dave Shea and Molly Holzschlag
It isn’t often you can call a technical book lovely, but this one is. The Zen of CSS Design is one of those rare books in which every element seems to come together in perfect balance and harmony. Kind of Zen, actually.
I have been playing soccer for most of my life, and on the field, it’s easy to see teamwork in practice. It’s also easy to see what every position does, and how they relate.
Sure, communication is key for any team, whether sports or Web development. One strange aspect of teamwork within Web development, however, is working as a team in isolation. Our Web team meets on Monday mornings. But for most of the week, we don’t see too much of each other. We work toward a common goal, but we do it individually on our own computers in our own offices.
Unlike my soccer team example, it’s hard for the team to see and understand what the others are doing. It’s also easy for communication to break down.
I believe establishing a solid process or methodology will help team members understand how the parts make the whole somewhat. But I also think an important component is creating an environment where the team is in closer contact, where the parts more clearly make up the whole.
The problem I’ve faced with working in group is that none of the people actually wants to do it.
These are creative, often intelligent, people, and yet socially capeable – yes, we do have them – they want to perform on their own. This is my problem too (less sociable, tho). I want to have complete control over whatever creation it is that I’m assigned to do.
Doing different parts of the same project can also be a drag, e.g if one part is more into one thing (flash) while the other is totally into another thing (xhtml)..
..and then there’s the CEOs who tend to learn new buzzwords every month and want all of them included at the end-o-the-month progress report:p
Fairly new to this, but in the last six months I have and still am working in a team of four. A copywriter, a PERL programmer, a PHP programmer and I am responsible for graphics. We all work from home and meet once a week.
As it is our own company, we don’t have directors and CEO’s. We are those. which helps a lot.
The reason why a lot of things do work is the technical setup. We have a CVS -Concurrent Version Server- set up to avoid conflicts in code. We run the site on Localhosts first to see what we are personally doing, than check it into the CVS to a test site, so we can all see what happens and comment on it and then it goes to the site.
The whole process is very informal and it demands from each individual to keep up to speed with the others. If the programmers go fast it will demand that the CSS is wriiten to keep up and the copy to be written to see the actual content. And it is immediatelly clear when people are lacking behind. The CVS mails everywhen on new checkins, which keeps the job transparent (and yes I start to read PERL now -PHP has no Zen to it-)
In addition a bugtracker server keeps everyone informed on eachother comments and urgent issues are solved thru ICQ.
Works for us.
But the very loose and rather unstructered constellation of this puts responsibility on everyone and I personaaly feel that this is our strength.
When business (sales and management) and IT (programmers, coders) workers are not aligned and communicating, business workers accuse IT of being ‘cowboys’ and ‘unresponsive’, and IT find the business decisions ‘very questionable’. Without adequate information exchange between business interests and IT , projects become failed value propositions before they even begin. Yes, small groups can get away with casual alignment but not forever. The root cause of failure is changing business needs and IT misunderstanding the business issues and business leaders not understanding the IT processes.
Misunderstanding and communication problems are almost assured without well-defined and proactive communication processes. There will never be visibility into the business and IT decision-making process without the parties having a clear desire to create it. Some disagreements are rooted in power-grab or political ambitions but most are just each of us limiting our perspectives and giving priority to challenges that effect our own components and not the overall project. It takes experienced leaders to cut through the maze of personal goals and weave a cohesive plan.
The really good news is that the market has never been in a better position to integrate comprehensive IT management methods that encourage and enforce holistic business processes. Communication and collaboration tools exist to give visibility and voice to all of the stakeholders. Audit trails can open the decision-making process to peers, executives, stakeholders, and programmers. Lifecycle tools can integrate the demand management processes and finally the supply and demand can be measured, prioritized and optimized.
The conflict between business advocates and IT leaders has existed since significant spending on technology became the norm. If business and IT workers have the will to resolve conflict, the communication tools exist to facilitate disciplined, repeatable, documented, and auditable communication methods. The question is: are you ready?
Despite the differences with each group situation, with the type of team members, and with each challenge, the natural emerging methods were ultimately similar and in fact not as disparate as one might imagine.
I think it’s equally difficult to break the silos in development. I have just joined a hospital to lead a team of developers who have been stuck in silo development and have been resistant to any change which I guess is common with any organization. My questions is how do we break out of this silo development and start working as a team to solve problems. Nobody seems to know how each person is developing, their are no standards no processes. Just each person gets assigned works and produces deliverables. Any suggestions or advice to give from past experiences that will help?
Love your beatiful
http://www.evideoizle.com
broccoli isn’t so bad as long as you know how to cook it.
thanks for your sharing