in Agile, Technology and Society

Why Agile Needs to Start in Academia

About a decade ago, I was in the midst of completing my degree in information science at the University of Michigan.  Wanting to avoid just taking a bunch of vanilla courses, such as computer programming, data modeling, and cognitive psychology, (which all are valuable and important courses to take), I sought out courses in other schools and departments to broaden my horizons.  One such course, in the School of Art & Architecture, was a physical computing course called “Interfacing.”

In the Interfacing course, an art student would pair up with a student from the School of Electrical Engineering to collaborate in building a series of electronic interactive art pieces.  Since I had registered for the course via the School of Art, I was considered the “artist” and was paired up with an engineering student.  Together, we developed our project idea, an analog radio that would tune itself based on proximity sensors, allowing people passing by to discover that their movement was affecting the radio frequency.  Then, we created a circuit board from scratch, soldered on all the necessary electronics, and programmed a 10K chip with the logic needed to have input from the proximity sensor to drive a motor attached to the tuning wheel of the radio.

While we only had mixed success with our nifty little human proximity tuner, the most important lesson was that of working across and truly integrating two disciplines, in this case art and engineering, and discovering that what the other does is not as mysterious and weird as one might think.  I didn’t know it at the time, but this was my first foray into Pairing, a concept currently receiving widespread and well-deserved attention thanks to the Agile movement. Pairing is most well-know in the form of Pair Programming, in which two developers share one keyboard, one “driving” (i.e. typing), the other “navigating” (i.e. telling the other programmer what to type.)  To an outsider, this may seem a strange ritual indeed, but it is in fact a powerful way of generating a highly focused whole-brain work session, in which one person is continually debugging the work of the other. (I.e. as the driver types, they are also thinking about and evaluating everything the navigator tells them to type, able to continually make course-corrections.)

In our case, we were pairing across disciplines, which can be just as powerful.  It becomes an act of debugging or evaluating the work of the other across dimensions.  While the engineer may be deep in their C programming mode, I am thinking about how the resulting code will impact the experience of people walking in front of the tuner.  While the engineer is gaining a deeper awareness of the impact of their coding choices on the people interacting with the machine, I as the “artist” am gaining a deeper appreciation for the complexities of software development (for example, when programming a chip, you can’t call a library function such as “abs()” to get an absolute value, you have to actually write an algorithm for that from scratch.)

Unfortunately, this type of cross-disciplinary pairing is, as far as I know, incredibly rare in academia.  Instead, artists or designers are often housed separately and away from engineers and computer scientists, rarely if ever having any contact with one another. The same seems to hold true for those in the interaction and graphic design fields. Until my first day on my first job out of school as an Information Architect at a small web agency, I had never worked with a graphic designer. I have to wonder how many of those students currently studying interaction design are spending time working side-by-side with software developers.  Based on my informal survey, the amount of time they spend together in academia is approximately zilch.

It is no wonder, then, that so many people in the interaction design community I have spoken with seem to think of developers as the Other, as people who simply are different from Us, who simply do not understand the subtleties and nuances of designing a user experience, who do not think the same way that We do. It is no wonder that so many people in the interaction design community suffer from what I call The Genius Problem, in which they see themselves as the creators of ideas, while developers are mere builders, construction workers who transform these ideas into reality.  It is no wonder that so many people in the interaction design community greet the idea of Agile software development with a high degree of suspicion.  It is no wonder because that is a mindset that academic institutions (unwittingly) have indoctrinated them into during the formative years of their practice.

As long as academic institutions in general, and interaction design programs specifically, do not begin to truly integrate their students with those in the computer science departments, this problem will persist.  Agile should not be something that is only taught in computer science departments, and only discovered by interaction designers on their first day at work.  For Agile to be effective, these students need come into these roles with an understanding of what they do as not being something separate from what software developers do.  And for that to happen, computer programming students should be spending time with graphic design students, graphic design students should be spending time with interaction design students, interaction design students should be spending time with computer science students, and so forth. Until that happens, the integration of Agile with other disciplines will continue to be a perpetual struggle.

  1. There are a lot of great points and discussion paths in this post and the following comments, but I would just like to point out the awareness factor of cross-pollinating opposing disciplines or enhancing the skills of a single discipline in the development community. For me, this is an enlightening post.

    I’m not a programmer or designer, but in my experience educational institutions provide a great foundation for learning the skills needed in the working world; however, most of my learning has been accomplished on-the-job. As a marketing major, I was required to take several business courses (including economics and statistics) in addition to social science courses to become a well-rounded student, but I was never advised that I might need certain communications courses (like design – to be able to understand the way things are done, or writing for PR purposes – as PR and marketing are closely related and often integrated) that definitely would have given me a leg up in my career. Not every student is as self-prepared as he/she should be while signing up for college courses, but the professors advising him/her should be.

    With IT, the industry is ever-evolving at such a rapid pace, that I don’t think professors or administrators are as aware of new trends or methods as quickly as they should be. For folks like @Mary who need employees with specific skillsets prior to starting a new position, it is important to not only know what is being taught in academia, but you should also be influencing academia.

    If you often hire graduates from specific institutions, feel free to give your feedback on what you are looking for. You need students to have exposure, at the very least, of Agile (or other) processes or to be able to work successfully with students from complementary disciplines. Many institutions are looking for and open to corporation feedback so that they may better prepare their students. And if you have the skills (and the time) to share your expertise on certain topics, apply to be an adjunct professor or hold a workshop to introduce these students to new processes.

    Some students just need someone to open their eyes to all the variations and nuances of certain disciplines and, very unfortunately, not all professors are sure what new topics to include in their curriculum, some aren’t as up-to-date as they should be, and some simply may not hold the skills to an expert degree to teach the subject.

    Bringing to light the information discussed in this post is an important start to develop the type of developers and designers needed in the industry. I hope others will share the information needed to more rapidly affect college curriculum.

    Great discussion!

  2. I believe that academic institutions are slowly starting to realize the importance of pairing people from different backgrounds, in order to train them to the real world. A few years ago, I took an elective course at Kent State University called Web Design and Programming, as part the requirements for my Master’s degree in IA. Half of the students in the class were from the Design department, and the other half were from Computer Science. I was considered as part of the Design side, or “the artists” as you mentioned. The idea was to divide the class into groups and each group should have at least 2 people from each discipline. Over 6 months, each group developed a real website. I’m not sure if you would call this pairing or grouping, but I think the idea is sort of the same.

    From my group’s perspective, the experience turned out to be great. We reached a good level of collaboration and we ended up developing one of the most successful projects in our class. Not all groups worked well like ours though. Few things that contributed to our success: (a) each team had a leader, (b) each member showed great accountability and (c) the expertise level of the members was relatively the same.

    Even though pairing seems to be the way to go, I think there are several challenges to do that in school. Sometimes, students are not prepared to work in teams yet. If you just put different people together, you might end up creating conflict instead of collaboration. Team work is more than just pairing; it’s creating an environment in which collaboration can exist naturally.

  3. Academics are those who accept change at the point at which it becomes mainstream.

    Agile will need, therefore, to become mainstream before its multidisciplinary approach is even considered, especially since it suggests a span between academic lines.


  4. Hi Andrew – I love the image of a UX practitioner pairing across disciplines as a contextual interview. This is particularly apt considering that other team members, and developers in particular are often the users of the artifacts we produce. In that light, what better way to understand your target audience than to pair with them?

    Thanks for your comments!

  5. Anders,

    Agile development and UX work hand in hand quite well, although I don’t think that’s the issue your article addresses. It seems that your article makes the case for pairing at the academic level, which I completely agree with.

    As you well know, the opportunity you had at the University of Michigan was rare. I, too, came into pair programming simply by happenstance. Yes, it happened in an agile environment; but I don’t think that was a prerequisite. A lot about the situation I found myself in at a web startup was because I was at a web startup. Which is to say, there aren’t hard and fast rules to online web development.

    It’s really the idea of cross-pollination that got me hooked on UX––finding perspective in software development is a difficult thing. Far too often, our work is done with tunnel-visition. We work at desks for 8 hours a day building software that people might use “on the go,” for only 30 minutes at a time.

    I think, fundamentally, the pairing process turns into a kind of contextual interview for UX designers. Learning how users, developers, stakeholders, etc, see a product helps us, in turn, to better account for their perspective. In fact, as UXers work as software ambassadors for a living, so it would seem that “agile” or the idea of pairing may be core to the UX discipline altogether.

  6. Hi Dave – thanks for your comments! I’m not sure if I agree with that my entire article is based on whether or not pairing is effective or not. That is really just an example of any number of Agile practices which I think people in the UX field are not being exposed to sufficiently during their formative years.

    Like Mary says (and thanks Mary for your comments as well!), Agile is a reality that you can’t ignore. Whether you like it or not, agree with it or not, it is a reality that UX practitioners need to be prepared for.

    In other words, this is not about finger-pointing; this is about raising awareness about a problem I have seen first-hand in the UX community – that way too many of them are still very much stuck in a waterfall mindset, which is becoming more archaic with every passing day.

    And that mindset, in my opinion, originates in the academic institutions where the foundation for their practice is set. Even if, as you say, many in the UX community do not have a formal background in UX, I think that more and more of those entering the field will have a formal degree specifically in UX or interaction design. And it is there that we have an opportunity to expose them to the Agile thinking and values that they are evermore certain to encounter when entering the workforce.

  7. Like it or not, we in UX are now involved in Agile run projects. Like it or not, we in UX are rarely in the position to say, “No — I’m uncomfortable with this, I haven’t seen this work, (insert derogatory phrase here) — I’m sticking to waterfall,”.
    We can either marginalize ourselves, see UX work go offshore and/or handled by engineering teams (Google teams for example) or see how we we can succeed and thrive in an approach that frankly makes many of us uncomfortable.

    Anders brings up several interesting points that merit further discussion: how is Agile taught in UX programs and how is pair designing taught in UX programs. Dave’s comments makes me wonder about the geographic placement of UX program graduates.
    Here in the Bay Area, graduates of UX programs have a strong presence. I’m curious to find out what is being taught because these are the folks I may be hiring.

  8. huh?
    Your whole article assumes a truism that I’m not sure has been proven, especially at the academic level, which is that pairing is more efficient (same or cross-disciplinary).

    Further it assumes that most non-agile UXers are academically trained (regardless of type of program). I would say from early survey results that I have undertaken that most UXers have no formal design or even academic education whatsoever.

    Third and this has been MY issue w/ “Agile UX” is that you put the blame on IxD programs. And I’m not saying there isn’t room for tons of improvement, but its not like IxD programs are holding the gates up out of fear of being drowned by programmers.

    But let’s take on the truism #1. In my experience a solid waterfall approach has been infinitely more successful cross-disciplinarily than any type of good or bad Agile I have worked with (and I’ve been forced to work with many). Statistically or through any other empirical measure (and I don’t have anything but anecdotal evidence myself) no one has PROVEN that Agile is better than non-agile. A. b/c there is no single “agile” and second because no one has tried to do cross process studies.

    But the one thing I cannot argue with in your post is that it is always great to sit next to and collaborate with people from different points of view. I’m not sure that “pairing” is the best method for this type of collaboration as there are many ways to gain these stakeholder inputs and have the types of checks & balances you allude to as important above.

    Again though, finger pointing as you do in this piece, pointing at one side of at least a 2-sided equation where the other side has much less understanding of design than design has of engineering in my experience, is really disingenuous.

    — dave

Comments are closed.