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.

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 past week the front-end team that I lead (it includes GUI makers, User Advocates, and UI folks) along with the rest of the team (SOA enablers) are religiously entering a scrum cycle for the remainder of the summer. We have broken into two groups along the lines already mentioned.

The problem I am having is that my group is a mix of the pigs and chickens and I am not entirely sure how to have them all involved. My approach for the moment is to have the UA/UI folks participate as observers in the first 15 min daily with the UI folks really taking the time to go over their tasks from yesterday, for today, and tomorrow. They leave, then the UA/UI folks do their thing for 15 min.

The other challenge as I see it is that we can’t ‘lock in’ tasks for a two week period as the expectation is that clients are giving feedback and expect to see some adjustments on a very short cycle. To address that I have set up two days of ‘respond to feedback’ where we tackle any tasks that can be done in those two days. Anything that can’t fit goes on the list for the next cycle.

This is going to be a bit awkward at first I think… not entirely sure I have it organized properly yet. Hopefully by the next two week cycle I will get it ;) Wondering though, anyone have a similar problem? How do they handle front end development of web applications in a scrum cycle?

Illya posted some thoughts on Agile Release & Testing Procedures and instead of writing a big long comment I figured it was worth a blog post. At the University of Waterloo I have had experience deploying a number of different applications for a variety of audiences… it is next to impossible to get all the details in a post but here is the general truth: there are no enforced institutional wide procedures for web applications. You might think the lack of procedures is bad but it is a result of the relatively low risk environment (even though the campus community has a low tolerance for bugs and changes). There are rarely formal teams of developers, it is mostly the loan coder building a specialty application – enforced procedures would frustrate them.

When you are dealing with a simple web page, say the uni home page, I have essentially covered the typical user acceptance, performance, and stress tests when the page goes live. I go through the gamut of web browser testing, try some OS variations out, and then get it out there. There is a relatively low risk here as the users don’t interact with a database or a whole heck of a lot client side. Once rendering issues are dealt with, it is pretty much unlikely to have other issues. This is with 30 000 or more people seeing it within a short period of time too. I had relative success but I think it was more luck and the fact we kept web pages simple.

Stepping up the development a bit, throw in a Ruby on Rails or PHP application. My testing procedures involved pretty much the same as the web page testing: poke away at it, fix bugs as they appear, and get it ready to go off of the development server to production. We (co-op student and I) never really sat on changes very long. The thinking was that if it went bad on the production end we just roll back the version, fast. When I made the jump to Ruby on Rails development with Capistrano and SVN that became so easy it was scary. On many occasions we had new versions going up two or three times a day. Minor changes, but they add up. This meant a lot of bugs made it out to the community version but as a whole the community appreciated seeing the progress. Our harshest critics were few and usually the type of people that would sit on things until they are perfect, the web is never perfect.

Now I find myself in the .NET/C# development world. I am happily hacking away at the JavaScript on the front end but I still live in the development environment. Here we have a solid team, a lot of developers, some serious tools, and totally different requirements from the client relationship/expectations end. At the moment we are doing limited testing that makes sure it works and then pushing it to an environment that a group has a ‘sanity check’ and gives us feedback. Releases are going out on a weekly build routine with a daily routine for an internal release. The whole process is evolving as we go but in a very general sense we are aiming to maintain a weekly build schedule for one set of users, daily internally. Our goal is to not leave the application in a non-working state and at any time the build could go live. This habit takes time to develop though… I don’t expect us to be in the groove until over the summer.

That is the nutshell version of what I have had experience with, I suppose it is Agile without the buzz terms. Personally I don’t see a reason why any web application couldn’t work on a daily build process. If you break the big change down to a lot of little changes you reduce the risk of breaking it and you ensure stability (so the theory goes). The problem is that in order to break a big thing down to a bunch of little things you need to take the time to talk it out, plan it out, and scope out what goes into a big thing. It is a way of thinking and it doesn’t happen overnight, most people need experience thinking that way.

I am interested to know what other higher education folks are doing with release and testing procedures.