Who You Calling A Jesse?

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.

With our second StartupCampWaterloo behind us here in Waterloo we hit a milestone. Over 100 people were in the main area of the Waterloo Accelerator Centre to talk with Startups and help each other with ideas (quick estimate based on 88 chairs in the room plus Ali’s colourful chairs). I am pretty sure all those that demo’d got some useful information and experience out of the evening.

A big thanks to Stefanus De Toit for opening up the evening and breaking-in the crowed by sharing insights like: Turning academic research into a product is hard if you don’t keep your paperwork in order; hire your friends; wow people with lots of 3D chickens to get investment (actually prove your concept with a solid demo). Another big thanks to Austin Hill for closing off the evening with a great presentation which included: don’t be afraid of sharing your ideas because someone already tried it – it is your execution that is important; Canada needs more of its successful entrepreneurs re-investing in the startup scene; beware the vulture investors; do a startup while you are a student; it helps to work for a startup if you are thinking about a startup as startup culture is infectious.

What was learned from this one is that 60 second intros with voting works out really well. Keeping things short and keeping the slides out of it kept the conversation interesting and focused. The big buzzer also helped. Only took one person being caught by it—no one else dared challenge their time limits. Plus it kept us on time, mostly.

I had a lot of good feedback and now can relax—until the next one. What are we going to do next? BarCampWaterloo is on March 29th, a DemoCampGuelph will be in April, and StartupCampWaterloo3 will be sometime in May. If you can’t figure out if you want to go, I have a post coming up tomorrow that will cover that ;)

Other folks to thank for making the trip from places afar and/or helping out last night… The Toronto folks venturing outside of the GTA in their large 4×4: David Crow – thanks for the books and disruption, Jevon McDonald,  Jonas Brandon.   Ali Asaria brought some chairs and name tags and Simon Law for came down from Montreal. The other organizers Simon Woodside and Mic Berman ensured that we appeared as unconference as possible ;)

Most importantly, the night was good because of the folks that were there. Waterloo has a great community.

It is interview time here at Waterloo. It happens once every four months, thousands of students and employers enter a dating game for talent and experience. Waterloo is a bit unique having a building dedicated to the process (just happens to be where my office is) and a frequency of three times a year for the process to run. Large companies like Google, RIM and Microsoft are hear hiring large numbers of students but so are local startups like AideRSS and Semacode along with all sorts of companies from different fields and different sizes. Posters on the walls with all the different information sessions show all the opportunities for students.

Why do the companies come here? Waterloo has the talent and I would argue there is far more and better talent than Stanford (update: Larry disagrees or does he?). Our students go to the Valley or Seattle or Boston or Ottawa and all points in-between to work for big names and get started on their carriers while they are working on their undergrad (or grad) degrees. A lot them stay local (Google and RIM are in Waterloo, along with a lot of other interesting employers) and even more would like to stay local for a term or two if a great job can be found.

For local web/tech startups this is a great opportunity. If you developing an idea and you need someone that can code and wants to contribute, for around 10K you can get a junior student for four months to do that. Senior students are more but you get higher quality and more experience. Just to prove a startup concept though, a junior co-op student is inexpensive and hugely beneficial.

The project I am working on depends on the quality of Waterloo Co-ops. We are building a new system to run the job/dating game and have a great bunch of students to do that. They code, they ask questions, they learn, they are excited, and they build really cool things from your ideas. Over the years I have worked with a number of different students and all of them made me look good—which is what you want when you hire someone, right? ;)

There is a side benefit to local startups hiring students I think as well. If you keep the students here, keep them engaged, and get them excited about trying out their ideas you help the local community build resources. I think it’s one part of the puzzle that may help Waterloo’s stealthy startup scene become even more open and exciting.

If you are wondering how to hire a co-op, contact CECS and they will have you set up in no time.

In my relative short career I have not had the pleasure of surviving a unionised environment except as a summer student doing landscaping work for the City of Sault Ste Marie. IT related work environments just don’t seem all that interested in a union, I would argue most knowledge workers have little interest in such a club. However here we are in 2008 at the University of Waterloo facing a vote in an attempt to certify OSSTF as a bargaining unit on campus. The vote is today however the outcome won’t be decide for approximately a month due to some dissagreement in who is in the bargaining unit.

The one thing that does get me about this entire process is how the law in this province favours unions over the individual. Maybe in industrial work environments the method used to unionize makes sense as workers generally may be easily replaced and can be easily bullied. However in a professional work environment, where it can take a few months to a few years before a worker performs at top form with higher education credentials, it feels like the whole process tramples on your rights no matter which side of the fence you sit. The behaviour out of the union itself just feels like they are after members, they don’t actually care about the workers otherwise they wouldn’t pursue unionization where the support is 50-50 at best (here it is 60% against, but they need to vote).

This whole experience has taught me a lot and I’d like to think I managed to get through it, up to this point, as President of the Staff Association (the opposing force) with only being called a few names: Meat puppet, lap dog, etc. Oh and apparently I have been paying people to vote… that would mean I had personal wealth large enough to do that. Cool, someone tell my bank manager ;)

Over the past year or so the MMNP effort has been working on ways to utilize mobile and media based technology on campus. A year ago a pilot project looked at the possibility of students replacing their land lines in residence is relatively smart phones. Lots was learned (primarily that students are shell shocked by the telco cost and don’t really use them even when a large chunk of costs are covered) and the project moved on to different ideas. One of those ideas was a living environment that doubles as an incubator for entrepreneurial students.

Enter 2008 and the announcement of VeloCity. The Daily Bulletin article covers all the details. From the VeloCity site:

“It’s a place where some of UW’s most talented, entrepreneurial, creative and technologically savvy students will be united under one roof to work on the future of mobile communications, web and new media.”

I was involved with the project early on and it is great to see that Sean has taken his idea and made it a reality. I expect to see some exciting things come from this housing experiment. What a great opportunity for some students!