Introduction
Why is it that we tend to over-complicate decision making when it comes to introducing innovative ideas? This can be especially true when someone wishes to try out a new and emerging educational technology in their teaching practice. Will it break the bank, threaten the stable core or simply put the institution at too much risk? In order to impact organizational culture and maximize the spread of innovation at one regional university, an explicit diffusion of innovation (DOI) approach known as, Technology Demonstrators, was implemented from 2015 in an effort to “under-complicate” decision making. This program drew upon agile principles and addressed all five elements known and evidenced to have an impact upon diffusion of innovation, namely: relative advantage; compatibility with existing values and practices; simplicity and ease of use; trialability; and observable results (Rogers, 2003, Robinson, 2009). The following paper discusses the agile approach used in technology demonstrators, offers examples of agility in action, reflects upon our lessons learned, and provides recommendations for those wishing to influence a culture of innovation within higher education.
Determination and Agility In Action
As with many Universities, the University of Southern Queensland (USQ) has adopted organisational practices indicative of traditional top-down hierarchical decision making processes. We tend to put a heavy emphasis on production efficiency (doing the same things, better) and a large resource intensive ‘task force’ project management approach, while suspecting that there are insufficient levels of discovery and experimentation leading to change at the learning and teaching level. That is not to say that there are not many innovative learning and teaching practices at USQ, however these practices are typically piloted in the grey area of the University and not readily captured or shared, reducing their potential impact.
Recognizing the importance of technology “in context,” the Technology Demonstrator approach has been designed to ensure that the prime stakeholders, academic staff, determine and drive the selection and decision to demonstrate the effectiveness of a technical solution to a teaching and learning challenge. After all, who is in a better position to determine the most relevant ideas about learning and teaching, than teachers and learners? This aligns with Jones and Clark’s (2014) notion of moving away from “doing to” and towards “doing with” staff and students when it comes to introducing technology in higher education. To achieve an academically determined and driven approach, open principles supporting agile practice were applied to the project. Agile principles most obviously considered were:
- Participation, in the process of solving problems, and the willingness to explore and see where it takes them, understanding that this may not end up a fully supported solution
- Courage to speak one’s mind, expose one’s practice and act on one’s commitments, and take responsibility for trying, even when doing so is unpopular
- Evidence-based to support reflection, improvement and sharing
- Self-organizing groups to engender conditions respecting professional agency and self determination, and reducing waste of time, while enabling collaboration across the university
- Incremental Development to naturally support and learn from the integration of new knowledge, changes in scope, and cost containment
- Simplicity & Emergence to reduce cost, engender flexibility, and avoid unnecessary risk mitigation
- Decentralisation to reduce the impulse of command and control cultures and bureaucratic compliance
Examples / Cases Demonstrating these Principles
The Technology Demonstrator project commenced at USQ in late 2015 with the first Demonstrator outcome being published in March 2016. By September 2017 the project achieved over 26 Demonstrator Projects, explored over 60 technologies and worked with over 9,000 of USQ’s 27,000 teaching staff and students across all except three of USQ’s 12 schools and two colleges. Notably, apart from the project team salaries, the project spent only $2836 on testing and exploring over 86 technologies.
These projects had no pre-determined goals, little to no paperwork, and timelines were set by the academic, which was essential to project success. The project embraced those teachers who had acknowledged concerns around their technical ability or location – their confidence and participation with a little support was in some cases overwhelming, incremental and exciting. Simply, there was no complexity designed into anything.
Of the many teachers we supported, there was a clear thematic question that emanated from each of the projects – how can we deliver rich, authentic and timely learning resources to those who experience vulnerability due to studying at a distance? Teachers appeared less interested in ‘quality’ in terms of beautifully polished learning resources developed by a Media team, while there was clearly interest in ‘making things different’ in practice – and quickly. This put a priority on using simple apps to facilitate learning as it happens and of course, these simple resources had to be easy to access and use. The projects, for the most part, existed in ‘playgrounds’, off-site thereby enabling the team to work outside existing USQ infrastructure and allowing team members to change direction quickly and easily.
To demonstrate an idea, participants were required to actively participate in determining and articulating what they wanted to demonstrate. Technology Demonstrators were decentralized by design, tending to work outside existing systems and many business as usual processes. The criteria to become involved in a demonstrator reinforced agile principles in that they were simple, emergent, and provided the conditions under which individuals were eager and willing to participate. There was no risk of failure and no need to engage in a long application processes to participate and secure resources. Purely there were three criteria:
- Criteria 1: The Project lead must be able to articulate the purpose in terms of what they are trying to demonstrate, preferably in a sentence or as a user story.
- Criteria 2: The Project should not take any more than 90 days (or a traditional academic semester).
- Criteria 3: The project should be low barrier, low-cost and low-risk (have no significant dependencies).
The three criteria ensured that the Demonstrators had a measurable quality and adherence to these criteria is what allowed the program of Technology Demonstrators to eliminate much of the standard compliance overhead. The idea that teachers were saying, “I want to demonstrate that if I do X, learning outcomes will improve,” ensured that we knew what we wanted to try and what we hoped to achieve. In addition, we knew that it would only take a few months, so it needed to be pretty simple, and because there was no third party depending on the Demonstrator, there was little risk – everything was a “success” because we learned something from every Demonstrator.
Lessons Learned on the Value of Agility
Openness and agility seem like they should be natural impulses, but they are frequently challenged by organizational dispositions toward secrecy, rigid business processes, and formal compliance. As sponsors of the Technology Demonstrator project, we learned dozens of things every week, which were routinely reflected in our practice immediately, but our biggest lesson was to simply be true to the values and principles of agility.
It is absolutely critical not to impose any judgment on pedagogical quality or soundness of the idea. Sometimes it is difficult to let the outcomes of the process inform the teacher, but it is important to respect the courage that a perspective Technology Demonstrator leader exhibits when testing how to improve their own teaching and it is equally important to reinforce the importance of evidence-based decision making.
It is easy for passionate teachers with creative ideas and for project support staff to get excited about a Technology Demonstrator. That being said, it is the support staff that needs to artfully exhibit the discipline to observe and enforce the value of simplicity, while also embracing emergence as the Technology Demonstrator develops. The 90-day limit helps everybody manage the impulse to design complexity into a solution instead of allowing it to emerge
The Technology Demonstrator support staff, and particularly the coordinator, must respect the principles of agility in practice and exhibit humility. Although the staff may be experts on the techniques used to support a successful project, they cannot assert their biases on pedagogy and other aspects of the learning and teaching process.
Recommendations
The Technology Demonstrator program of projects involved dozens of professionals and academic staff and thousands of students all with unique needs and motivations. Although we could easily generate a significant list of recommendations based on our experiences, most would be context specific and of questionable value to anybody considering this approach to culture change and technology diffusion. Instead, we will make one fundamental recommendation –
Practice the values and principles of agility. Be open, and honest, and courageous and humble. Let the community know that this is a change initiative, but nothing will change without participation. That is, if we want to be different, we need to do things differently.
[1] Rogers, E.M., (2003). Diffusion of Innovations, Fifth Edition 2003, Free Press, New York, p221.
[2] Robinson, L. (2009). A summary of Diffusion of Innovations (Source: Summary_Diffusion_Theory)
[3] Jones, D, and Clark, D. (2014) Breaking BAD to bridge the reality/rhetoric chasm. In: 31st Australasian Society for Computers in Learning in Tertiary Education Conference (ASCILITE 2014): Rhetoric and Reality: Critical Perspectives on Educational Technology, 23-26 Nov 2014, Dunedin, New Zealand.
By Ken Udas, Susan Brosnan & Bill Wade
Ken Udas
Latest posts by Ken Udas (see all)
You must be logged in to post a comment.
There are no comments
Add yours