Last week, our technology program brought in a trainer on Agile development methods, which is really an alternative approach to project management that’s particularly brought to bear on large software productions. One compelling aspect of the agile approach is the attempt to reconcile what every member of a team brings to a vision--including the difference between what a customer says and thinks they want, and what they really want. As we worked through strategies for continuous learning and adaptation and development, the trainer presented on question that struck me as useful beyond project management: are we solving the right problems?
In a technical context, it’s easy to pull that question into work at every level, particularly when designing a product for a user with particular demands and ideas about what the software looks like. It’s easy to lose site of the user’s required outcomes and end up with a great solution to an entirely different problem than the user had to begin with. In universities, our ability to create an ideal learning experience for students with a range of different concerns can similarly be hindered by the challenges of working and communicating across disciplines and purposes.
The Agile manifesto includes several values with lessons for us at universities, such as valuing individuals and interactions over tools and abandoning ideals of long-term planning in favor of responding to change as it manifests. One of the advantages that strikes me with the Agile approach is the likelihood of failing early is improved by the overlaps between different methods and piece of the production, as mapped out subway-style here. I’ve been thinking a lot about failure lately, but it’s easier to risk failure in small projects. It’s harder to take that risk when doing something big, like restructuring a degree program or perhaps an entire university. And I find that it’s in endeavors like these where it’s easy to set out determinedly to fix the wrong problem.
Projects that involve adding technology to campus can be particularly suspect when it comes to solving the “right” problem. It’s easy to get drawn into the new and shiny, but as Lincoln addressed in his post on prudent tool choice, “hacks for hacks’ sake” are often just another mode of procrastination rather than a tool to solve the real problem at hand. When I hear about technology initiatives that have led to dusty investments sitting in closets waiting for someone to manifest them as innovative pedagogy, I often think of these as physical evidence of the challenges of institutional problem-solving.
Appropriately, this workshop occurred the day after commencement, which stands out each semester as the day where many members of the university, including faculty, students, and staff that never otherwise cross paths, celebrate the culmination of some of our shared efforts. The event highlights how universities are unintentionally collaborative, a practice which makes it continually difficult to identify and built shared solutions. If we apply the metaphor of software development to the challenges of the university, it’s easy for us to become teams working at cross purposes and thus fail more slowly than we intended to--or fail to learn from one another’s failures.
What strategies do you use to collaborate and assess problems with your teaching, your program, or your university before you set out to find a solution? Share your experiences in the comments!
[CC BY 2.0 Image by Flickr User Forsaken Fotos]
