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.

A twitter conversation got me rethinking about the concept of content vs design yet again. I am constantly in a battle with having to design an interface for content, actions, and requirements that are either contradicting or simply not known yet. That is hugely frustrating however there are ways to design some general things without knowing the specific content and through a few iterations you get there. That is usually what you are forced to do if you are trying to be truly agile.

In Higher ed, what rules is content or design? My feeling is that it is still content. Aside from Alumni and High School students, the gross majority of consumers of information in the higher ed web space are a captive audience. They are staff, students, and faculty that are simply doing their daily activities in a web space they have to use. Sweating over design and what that design should be may not be a fair trade off over just simple content organization. If content is so important I think the use of Microformats is as well because it allows the higher ed space to open up that useful content to a larger audience and potentially enables their internal audiences to use that content better.

Design (impressive, high end, etc) should be more important for micro-sites that are targeting external audiences. An impressive design can be that ‘wow’ factor that will attract those high school students or make your internal audience more comfortable to find information within your web space. However, content may still be more important in the form of a social media foot print in youtube, twitter, facebook, and other places where you don’t have control over design… only the content.

That is not to say good design isn’t needed but I think if you have only 1 day to spend fixing something in your higher ed web space, fix up the content.

Do you want to make the system better? Do you want people to use your code? Do you want to work with me? It is close to the end of the first round in co-op here at Waterloo and we have a couple jobs posted. Here is the jobmine info so you can find it easier:

Winter 2009 Co-op 00092349 Software Developer
Winter 2009 Co-op 00092354 Software Developer – Q/A
Winter 2009 Co-op 00092662 User Advocate

We need some passionate students that are keen on web technology to get us to the pilot stage in the spring. Do you think you are up for it?

The technology you get to play with is mostly Microsoft – SQL, .NET, etc – but the GUI likes to use jQuery (before Microsoft decided it was cool).

How can you explain the state of mobile development (both web based on device installed) to non-mobile folks that are use to a windows dominated world that makes ‘adjustments’ for Mac from time to time? Here are my basic assumptions:

• CDMA devices are in some walled garden most of the time.
• Carriers don’t want to be a service provider, they want to control and profit from the whole experience.
• Long term contracts from carriers in North America slow down new device uptake.
• GSM devices are common and low barrier targets.
• Software on phones is rarely updated.
• No device is ‘easy’ to develop for, in fact most are like putting together an entire house worth of Ikea furniture along with all the little things.
• Mobile browsers suck.
• Microsoft doesn’t yet get mobile, but it will.
• RIM changed the game (with email, utility, service) but forgot about changing the rules.
• Apple changed the game further and re-wrote the rules (utility, Application store, touch it).

From those assumptions I am still at the same place I was over a year ago: supporting ‘all devices’ with regards to mobile development is not practical in North America. This includes mobile focused web sites and device installed applications. That isn’t to say there isn’t a market worth going after. Apple gives you access to a lot of people through it’s App store and you can target their browser easy enough. You can target Blackberry as well and if you target both I think you will hit a pretty good market.

The trick in my mind is defining where the market is. What developers need is good (unbiased, up-to-date) research on who is using what devices for what. Not because mobile developers don’t know their audience but because their paying clients, understandably, deserve some real numbers to decide what they need.

Last week I had the pleasure of participating in a meeting between a local mobile start-up and a mobile marketing start-up based out of Toronto. A major chunk of the meeting was spent discussing the various issues of platform and carrier issues.

The marketing group have a client that wants an app on ‘all phones’ – Bell, Telus, Fido, Rogers – but the local start-up can not justify the resources nor can they even think they could support all devices. The client wants to support all phones not because it thinks that is where their target market is but because they don’t know what devices their target market uses. If they new it would be easier for everyone.

This leaves me wondering… is it even possible to collect accurate information on device usage? Is it easier to just target the iPhone since they have data plans and are more likely to have users that want to try out stuff?

I don’t think people in larger organizations (maybe people in general) are use to the development processes of anything that could be considered ‘2.0’ so when they are participating in the early stages you need to be sensitive to that.

The system my team is building is essentially an enterprise 2.0 application for the higher education business of co-operative education. It is like some odd form of dating. It can seem like students are pimping their skills to the highest bidder (employer) but it’s not just about money. For students money can talk but so does being able to find a place to live for four months, having a job that isn’t just mindless work, nice office, helping their career afterwards, etc.

Oversimplifying the explanation of the project: Our goal is to create a web based application that does everything from building a resume to a job posting to applying to jobs and setting up interviews. We are designing it as a self-service collaborative environment that will eventually place the university staff in a position of oversight instead of direct service provision. This has to hook in with other university business applications.

When trying to be agile and include the user in our early stage development we have run into the fact that people that are use to business applications are not use to seeing a rough application. They treat it like it is production quality at the earliest of stages and in turn can bog down development. What happens is an overload of feedback and emotion which just takes the steam out of the user advocate and front-end team.

To add to the fun, we are an internal team so a loud backlash has political implications. We can actually get frozen in time until something at least is close to production level in the stakeholders eye. The result can be a big time sink but it may be a necessary evil of building an enterprise 2.0 application.

If you have an internal team that is replacing a Peoplesoft-like ‘take what you get’ mantra in enterprise application development you will need to account for the reality that end-users in business are use to that. In the past if they saw ‘early stage’ they didn’t see much difference once it hit production. I think it is unlikely that business users in general have been involved in truly early stage development.

This Saturday is BarCampWaterloo (number 6!) from 1pm to around 7pm (we may retire to the pub before that) at the Accelerator Centre. A much more toned down event compared to StartupCampWaterloo, BarCampWaterloo is where people come to explore ideas and maybe get themselves ready for a DemoCampGuelph (which happens to be April 9th at the Albion in Guelph). I might show some of the stuff I have been working on this weekend ;)

DesignCampWaterloo is March 26th (Wednesday)27th (Thursday) starting at 4:30pm in the Tathum Centre on the University of Waterloo campus. The first one was a bit difficult to follow being in the SLC and all so I am really looking forward to it in the TC. Plus I just have to go up two floors from my office to attend!

There is also a RailsNite next week on Monday at Ceaser Martini’s. Not sure of the start time but I think 7ish might work.

Update: RailsNite does start at 7pm and there is a Facebook event created for it.

Another update: Rick Segal is not coming to Waterloo for his VC roundtable, but he is coming to Guelph on April 28th… Perhaps Ali is influencing people now.

Yet another update: DesignCampWaterloo is Thursday not Wednesday.

You work on something for a couple weeks and then the due date comes close. There is a realization that you won’t meet the milestone unless you get a lot of code written today and deal with whatever UI issues and browser bugs you can. You order in some pizza, fill up on caffeine, and push through a 16 hour or more work day. There is something about that role you get on when you don’t leave your computer, things just make more sense.

My GUI team of co-op students have been pushing themselves this past week and this evening I think they achieved more tonight than all of last week. People will have to wait until May 1st to see it but our internal deadline is much earlier (demos to some stakeholders first and we need April to bug hunt). Maybe I will demo a bit at DemoCampGuelph in April or BarCampWaterloo ;)

Just wanted to post a just over mid-term thanks to Daniel, Shawn, Allen, and Michael for the commitment. They have gone from CS or Engineering students to fairly good AJAX developers in a very short time period. They have made some cool stuff, can’t wait to show it off.

Interesting conversation today that started off with (edited for dramatic effect):

• me: “I am pretty sure what we are doing is not going to be accessible and is going to cause us grief” (me went on about Ontarians with Disabilities Act, University’s commitment to accessibility, etc)
• softeng1: “What will? AJAX? I am sure it can be made accessible” – goes to google, pulls up an article from Juicy Studio
• softeng2: “What exactly is not following the law?”

At this point I probably got annoying because the problem with accessibility is that it is an art over a science. Laws are vague for good reason—there is no black and white, if there was technology would make the law redundant quickly (thinking PDF being a ‘bad technology’ in Australia). I went into the fact screen readers have a heck of a time when things change and there is no page refresh and how stuff not working, at least a little, without js is a problem.

The conversation went on with the software developers insisting there is a software solution. Which is understandable but that is because I got annoyed with the brush off instead of going into the problem. Making a web application accessible isn’t only about using screen reader, I missed that but I am not sure that would have helped…

After the conversation dragged on for a bit we started talking a similar language although the focus was on fixing it with software and testing. I am all for testing but I certainly don’t want to go back and test it in a year and then fix it. I would much rather consider it now. Making a web application accessible is as much about a philosophy as it is the technical considerations.

This left me thinking, my approach was wrong for how these folks think and their experience. Plus I was annoyed by the number of JavaScript reliant things we have already. My concerns are that even though we are spending a lot of time on user testing and usability analysis, technical accessibility would be sacrificed. Are my fears warranted? Probably given the amount of JavaScript, however if we approach it smartly from start we should be ok—that means now.

I have run into a similar conversation quite a few years ago when the web developers on campus weren’t sure what to think about web accessibility. They were far more open to the problem though, not software engineers (or Computer Scientists) as they can build a fix—so they think. What is missing from their world is the appreciation for how annoying web browsers can be and how people interact with them. With software there is more control over presentation and the user expectations are different.

I will need to think about an approach to ensure that the issue of accessibility is more relevant to them. Taking away their mice as they navigate the app might be a good start ;) Or degrading its performance. Most web developers seem to get the problem now but they have likely spent time reading about in the context of the web. Curious as to how others have approached this situation with those that build software, not web apps.

First I think I need to get a few good nights of sleep. The lack of that lately does not help!

Next week (December 4th) sees two pretty exciting campus conferences happening. The first is WatITis – a one day conference for IT staff at the University of Waterloo. Would you believe there are just over 300 IT staff at Waterloo working in dozens of different departments? This will be the first year I am not presenting (current job’s stuff isn’t presentation ready yet) and I am not sure I will have time to attend… but it is a really good event.

The following day is the Power of IDEAS conference. This one is open to anyone for a really low price (below $100 for off campus folks, free to on campus people) and focusing on inclusive learning strategies, usability, and accessibility. Derek Featherstone did the keynote for the first one in the summer of 2006, this year he returns for the closing keynote. I will be presenting on building usable web applications and will offer a glimpse of what I am doing in the lower level of the TC as well as some reflection on other higher education home pages and other applications I have worked on over the years.

Keep an eye on the Power of IDEAS conference. Lead by the Office for Persons with Disabilities office, it will only grow (this year there are over 90 people from off campus registered, last year we had around 20). I think it is just great that a conference dedicated to promoting accessibility and usability.

Under what I think is the wrong category, the iPhone is named Invention of the Year by Time. It’s not an ‘invention’ at all though, unless you count the overall phone, PDA, and billing experience. Apple has maybe invented a better process for mobile computing and cellular networks. The iPhone is an enabling technology through its experience, not through its email, browser, etc. It makes the mobile device easy to use and thus inspires a load of developers to mimic that experience on their applications. For that, it is just amazing. The iPhone should get gadget of the year—which it probably will, voting is still open.

Having only played with an iPhone, owned a Blackberry and an Nokia E62, and still have to deal with the moronic customer service of Canadian cellular providers my opinion is purely based on observation but it is pretty obvious that the inability (or lack of motivation) to provide the activation, service, and billing experience that comes with AT&T in the US is what is stopping Rogers from offering the iPhone.

I still want a real keyboard btw… N810 with the iPhone OS would be perfect.

I have been on thing about figuring out coding patterns in HTML. Since I did the UW CLF back in 2004, I have been thinking about a macro-format for content generated on higher education web sites. Any CSS framework uses some abstract naming convention now—so I guess what I have been looking at is a “blueprint” that works specifically for higher ed.

What I did today was grab the code structure from about 10 higher ed web sites (three each from the UK, US, and Canada plus one more). It is just amazing how different HTML can be. Most sites are similar design wise, they have very similar content, and they supposedly trying to provide the same type of experience to the exact same audience.

Only three had Microformats on them, one had errors, and all are ‘valid’ HTML/XHTML. Good and bad ;) Well time for a break then on to more research and maybe even some prototyping. You can call what I am researching is a possible Macroformat for higher ed…

There has been a pretty interesting flame war that has erupted over a posting by Jeff Croft entitled What’s not to love about CSS frameworks? It seems like it has been quite a while since a good flame over web standards and best practices has played out. The tone of the post likely has really fueled the war but the topic itself seems to truly polarize some in the web standards community. Why is that? The devil is likely in the definition and I see it as the less formal art world colliding with the engineering world (something that has been slowly happening for a while with web development I believe).

Jeff Croft posted some follow ups: A follow up on CSS frameworks and The final word on frameworks, from someone way smarter than me. Andy Clarke interjected a comical What’s not to love about instant cake mixes in between that offered some satirical insight. The comments on the posts are shocking in some ways but once the definitions were clarified I think it comes down to artistic approaches meeting formal engineering process.

If you agree a framework is just a collection of reusable code that offers enough abstraction that you could apply it to whatever project you are working on then you have probably some engineering exposure ;) Reusing things is common practice, if you have a problem with that then you are just plain dumb with your time. This reuse of code features is part of what makes Dreamweaver CS3 such a good tool for rapid development. The CSS templates that come with it offer a powerful ‘framework’ to start with. Would you consider that a framework? I dunno. The ‘CSS Framework’ proper that is implied (blueprintCSS ) is in fact a more extensive framework that tries to solve more problems.

I think frameworks are great. I am building one now along with my GUI team of co-op students for a new system here. We are using a more formal engineering process to approach it but what we are essentially doing is creating a framework of GUI elements along with their HTML and JavaScript. Love them or hate them frameworks are just another thing the web dev world ‘re-invented’ from the software engineering world.

Looking to browse book covers but not wanting to walk down to the book store? Check out Zoomii. You can fly around the book shelves and get a feel for the book size, select what you want, and then purchase it through Amazon.

Chris Theisson has been busy over the last few months showing off his new Amazon affiliate site Zoomii to folks at DemoCampGuelph, DemoCampToronto, and BarCampWaterloo.

This store shows you 20 000 or so book covers and their relative size. You can simply browse the shelf and check out the interesting looking books. For an AJAX based site it is just amazing to fly around the book shelves. I love how fast it is and the search results are just nicer than what Amazon normally gives you. If you are a visual person, this store is certainly more fun than the typical Amazon experience. You have to bounce over to Amazon to make your purchase (maintains your comfort level with Amazon).

If you want to try it out I have a couple invites available to me so just post a comment.