Sunday, October 23, 2011

Connectivism and Agile Software Development

networkImage by sjcockell via FlickrAs a director of distance education, I often have multiple projects going on: some with the in-house team or with others at a distance in grant projects. I have been researching how projects get done for a while now. I read about "agile" software development. I in no way would like to imply that our team is at that level of efficiency - but we are also in a place where my tiny dept. needs to look at our mission and values and the "Agile Manifesto" or at least items from it will make it in there. The Agile Manifesto was written in 2001 but typical education work environments focus on the work week, the semester, and very broad time lines. Education institutions often work in terms of specializations. Outside of pure academic research, IT departments are driven by job descriptions, not inspiration, passion, or vision. What I am finding is that just as we need a new theory of learning for the networked era, the digital age (i.e. Connectivism), we need a new theory of project management for the digital age. The idea that we are going to make significant progress on projects with folks who only meet once a week or month, have little stake in the outcome (besides a paycheck) is just wrong. I don't think that model ever worked. Maybe not all of the principles are applicable to an education environment. It goes like this:

Principles behind the Agile Manifesto

We follow these principles:
  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
    This first principle implies not just delivery, but communication with the customer. "Early and continuous" in my mind speaks to customer expectations and continuously checking in to understand the possible changing needs.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
    This principle is important because one problem with project management is that half way through a project, a team can find out that the deliverable will not meet the customer's needs. One has to be committed to those needs and not just focused on finishing a deliverable. 
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.Again, in an education environment, this is about expectations and communication. Faculty we have worked with expect us to take their requests for learning objects and take them to the next level, even after we have moved a "final" version forward. 
  4. Business people and developers must work together daily throughout the project.
    When I worked at Tacoma Community College as an instructional designer, our Fearless Leader, Andy Duckworth, hooked up the whole elearning dept. with instant messaging. At first, it was just for us in the dept. but as faculty found out that we could be instantly available, some of them joined in too. There were fears of "over-connectedness" but that never happened. What did happen was that small problems could be quickly solved in a timely fashion before they developed into big problems. Small problems become big problems when they are not solved in a timely way, 
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
    How do you know you have motivated people working on education projects? The right people for my teams are those that not only have proficiency in their skill area (like graphic design or coding) but have a driving curiosity about how we learn, education, and communication. 
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
    This flies in the face with how we often have to work. This is especially true, I find, with workers who are not used to communicating efficiently and effectively online. I value face-to-face conversations - I know why they work, but this was more true in 2001 than it is today because of the advances in networks and the software used to negotiate them (e.g. Elluminate Live).
  7. Working software is the primary measure of progress.
    This is often completely alien to the education workplace - deliverables and outcomes often take a back seat to process or politics. 
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity--the art of maximizing the amount of work not done--is essential.
    Wabi-Sabi for Artists, Designers, Poets and Philosophers should be required reading for any design team. 
  11. The best architectures, requirements, and designs emerge from self-organizing teams.This is something that I learned from George Siemens and Stephen Downes. I was in one of their MOOCs (massively open online classes) where the students were encouraged to self-organize into groups using the tools they were most interested in or comfortable with for communicating and working together. We learned as much or more from those teams than from any "sage on the stage" and that is how the class was designed. 
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjustsits behavior accordingly.
    I would like to see more of this in instructional design. Those paradigms can be a starting point for some designers, but we need to knock instructional designers out of their comfortable paradigms (e.g. ADDIE) and listen to the needs of the students, faculty, and the production team.  
A good summary of this process could come out of "Emergent Design" which Wikipedia says "emerges in the creative design process, rather than being a blueprint that exists eternally in the ether like the Platonic source Forms and also that the artifact that is designed has emergent properties that are more than the sum of its parts."

This just in: The Electric Educator posted an interesting take on this in September:
http://electriceducator.blogspot.com/2011/09/agile-development-meet-online-learning.html
Enhanced by Zemanta

1 comment:

  1. Hi Geoff, I had time to read your post this evening and found it helpful to clarify some of my own thoughts.

    I think #5 is a key to success. The team needs to work well together and feed off of each other.

    I struggle with #6 as well. "Hallway conversations" frequently accomplish more than formal meetings. Such conversations are more difficult to have virtually. Your suggestion for IM communication is a possible substitute is a good one.

    #12 is also a key point. There are always improvements that can be made. We stress reflection to our students, it is time that we do the same.

    ReplyDelete