Who You Calling A Jesse?

What is the ideal structure for a web application development team that is using Agile methodologies? What is the process that results in the most bug free development possible? Over the past few weeks I have been documenting and tweaking team roles and process for our front-end development. It has been a lot harder than I thought it would be, especially when you throw co-op students in the mix.

In the past year roles on our team have evolved as we have had to figure out the limitations of our technology, backgrounds, and our skills but I think after about 12 months of a team functioning in a development mode things are pretty much set. What I have found is that you have to adjust certain roles to match people’s strengths and find their comfort level—especially if they are co-op students or recent grads. Once comfortable in their role people start to really shine.

The Web Development team

Every team is a bit different but this is what the Special Projects Group looks like at the moment:

• Design/UX Lead: Manages the front-end design work, participates in development, has responsibility for what is displayed on the screen and how it is displayed – satisfying the requirements set forth by the Client and Project Leads. Interacts with the Project Lead to determine what is ultimately on the screen and how the users interact with the system.
• UI Tester Lead: Design, manage, and execute testing. Collects and consolidates data for the Lead Design/UX.
• UI Designer/testers: Works on designs, incorporates feedback. They also do what would pass as unit testing on the application using a web browser.
• Client Lead: Provides input and has shared authority with Project Lead on screens.
• Project Lead: The person responsible for the project wrt development and satisfying project requirements. Interacts with the Client Lead to determine functionality, business logic, and general interface requirements. Interacts with the Lead Design/UX and Client Lead to develop the front-end requirements.
• Developers: Code the screens.

Like with any web app project and team, there is a creative process group that must meet up with a coding/logical process group. Ideally you throw some usability testing/feedback, client feedback, and a project lead that has sold a particular level of functionality to the client and you get into some fun. The above roles try and address this but they need an integrated process that all roles can work with.

Problems that had to be managed largely had to do with timing

A problem we have had is that coders can’t code a screen until a UI designer/tester has run the screen past a number of people within the client group. That has been cut down to one client lead who has his own process to run it past a larger client stakeholder group. There was another problem with the feedback loop from the client and project leads and when was the best time for them to provide it. This problem is still not fully addressed but hopefully the current process will solve it.

Embracing the issue tracker (or how I love bug reports)

Bug tracking, even the concept of what a bug is, along with having a reliable/useful system was our final problem to overcome. We started with Team Foundation Server then we switched over to Bugzilla and adopted a very religious approach to using it as an issue tracker. This worked out extremely well in providing focus and a task list for coders to pick up. The new problem it has caused is that if you are tracking issues in the system how or why would you use the sticky notes on the wall? Honestly, we are still working on it.

Our process, incorporating bug tracking with sprint planning

The above work flow works really well. What we have done is broken the project into milestones that fit a two week sprint planning process (or a series of planning sessions). The screens are developed quickly with paper, they are discussed, modified, and bounced back and forth in less than 48 hours. From there coding can begin.

We make an effort to switch modes on a screen so that our bug system isn’t overwhelmed. Our team members roles funnel decisions up to a contact point and then allow certain ‘bugs’ or issues to be incorporated in two weeks or less.

Translate agile to your team

Agile doesn’t mean you are infinitely changing things and incorporating feedback. You need to have a cycle that allows you to reach a milestone, provide time to iterate, and move on. You need to be able to classify the feedback and make decisions against the larger vision of what you are building. Where Agile works for us is that it provides an opportunity to catch major problems before too much time to it. Where it fails is when our process doesn’t incorporate the tools at our disposal effectively.

The goal of this process is to avoid being ‘too agile’ where the people in higher positions can cloud the process with mixed expectations and contact points. Using a big wall with sticky notes full of stories and tasks works great but as soon as you introduce bug tracking software it starts to slide a bit. The balance is hard to find but when you do it is worth the short term pain.

With the Facebook data drama getting mainstream media attention and people dropping their Facebook accounts out of protest it got me thinking… people don’t understand the web do they? If you have ever had a conversation with a person insisting you change the results in a Google search as it points to an old page or out of date content in the summary you know how hard it seems to be for people to get what happens to things once they are posted on the web.

The data is crawled, it is stored, it is copied and pasted, etc. It might get locked away in archive.org or on someone’s screen shot. Whatever happens to it you only have control over the source but once you drop those keystrokes onto something accessible by a web browser or by someone else on the network you don’t have control over what happens to it. Facebook might have tried to simply write it is as it is but people don’t seem ready to understand it.

Worry about accessing your data not where it may be copied.

The real battle over your data in my mind is whether you can access it if Facebook decides you can’t. If you can’t export it or access your content (like say with Twitter past whatever number of tweets they let you get at) then we have a problem.

There has been a bit of a discussion in the uwebd list about when is the right time to launch a higher ed web site. Thinking that launch is for new sites and re-launch is for re-branding and something you do with care, my first reaction was “why would you launch a new higher web site?” There is still a tendency in higher education to launch new designs on the campus community from time to time and I think, in modern web time, that is nuts.

Think of the people that use your web site, how they use it, how long they have been using, and who the redesign is for? Are they the same people? Flipping the switch on large changes (navigation, content, etc) is, at an informed guess level, expensive. Every day users are disrupted, new users don’t notice, and the occasional student user likely will think a refresh gets in the way and ask why does their online course environment still suck when you obviously have time to make changes on this site?

Major website overalls on public sites are a waste of resources with little ROI

Here is a generalized version of redesign process in higher ed:

• Someone says ‘we need a fresh look’ (usually fueled by marketing folks or recruitment ‘studies’)
• Committee is formed to look at ‘revamping’ the home page
• 6-24 months pass with around a dozen people on a committee discussing designs
• assumptions are based on personal preferences about what people want to see on the web
• Someone brings up implementing or changing the CMS, another committee is formed to look at that in parallel
• ‘three’ designs are chosen, CMS’s are investigated
• In a perfect world usability studies occur
• In the practical world, ‘previews’ are given to key politically sensitive areas on campus
• After some news releases and committee discussions at various levels some last minute ‘additions’ to menus or content are made for the flavour of the month
• page is launched
• users freak out, some love it, some hate it, all have to learn the new navigation to get on with what they have to do online
• more additions are required for political reasons

Have I gone through this? Yes, twice in seven years. I changed jobs just before my third time came around. In the 15 years or so of a web presence for most schools I would imagine they have done this an average of 4 times with the range between 3 and 8.

This cycle plays out just about everywhere in higher education and I think it largely because we ask each other what we did and copy/tweak/repeat. My guess is that the investment into this type of cycle is around:

• at least 3 FTE of ~45K salaries initially
• into the dozens of FTE for campus wide change
• if you buy a CMS ~100-500K plus more FTE

There is also a cost in disrupting people’s work flows (staff tend to have click patterns to things they need everyday, moving that causes cardiac conditions to worsen), committee time, and the other things that don’t get done.

What do you get back on that investment? Nothing. I don’t believe for one second that students decide to go to a particular higher education institution because their website looked cool, modern, etc. If high school students say that they are just telling you what you want to hear (teenagers do that? really?). Finding the information they need about what it is like to go to school there, programs, the city, the cost, etc would influence them but not a picture of a researcher up to their waste in sludge (grad students that care already know who that it and what they do).

Incremental changes by design and invest in content: clear, concise, informative

I am not saying you should never freshen up your website. You most certainly should but it should never require a re-launch unless you re-branding or something significant. Slight changes to navigation, content, colours, etc can occur without throwing it all out and starting fresh. Your previous design can’t be that bad (if it is, replace it by all means) but it is likely looking pre-web 2.0 or worse, way overboard on web 2.0ness. So clean it up, design change, but don’t do a demolition unless you absolutely have to.

Take your experience with other websites. If you have to be there to find something do you care what it looks like? No. You only care if you can’t find the information you need or if Google didn’t get you to a quality source on the first search. Students, staff, faculty, friends, etc all come to a higher education website not to hang out but they come to find out specific information. If they can find it and it is readable and your site isn’t some over designed 10px paradise with animated gifs they will have a positive experience.

I do believe things like HTML 5 and Microformats places more focus on the content then the look as the content becomes more portable. More and more people do not see your content in a look and feel that you have 100% control over (you never had 100% control) so why focus on that? Make it so your content is structured properly and relevant. Search engines will like you more as will the people using them.

Update: Smashing posted an Article on Feb 3rd on what being clear and effective in communication on the web means. Facebook offers a great example of continuous improvement in design without relaunching anything (the new design was launched once but changed many times) over a period of 5 years

Where design efforts should be focused: on the tools students use everyday

…and that is a whole other blog post. Fact is that higher education rarely spends time on the experience in web based applications that students, staff, faculty must use everyday. Why is that? I have some thoughts that I will post later ;)