Following on from the success of the first code sprint and our second one planned we took the opportunity to share our experience and thoughts on how the sprints fit into a wider context by joining up with Mairi Fraser from IS Apps to deliver a presentation at an IS lunchtime seminar. We wanted to explore why we are working to produce an EdWeb collaboration and development framework. And with this being a technical audience we also went through the structure of a sprint with the view of starting a discussion in looking at opportunities to introduce this in more areas across the University.

In the beginning

In the business case for the new University Content Management System we said that we needed to build a flexible system to cater for the diverse business needs around the University. This would consist of a central service including all the layers of support provided by Information Services but with the addition of the EdWeb distribution allowing people to take the complete code base and modify it to meet their local needs. Features that could benefit the University publishing community as a whole could be pushed back to the central service and made available to everyone. The clear message was to provide opportunities for colleagues to be innovative, collaborate, problem solve, knowledge build and share good practice.

The business case for the new University CMS stated that we would provide opportunities for colleagues across the University to be innovative, collaborate and share good practice

We built our flexible service

Whilst this is an oversimplification it makes sense to concentrate on 3 of the main deliverables of the CMS project. The first is of course the CMS itself which runs the central website including websites for all 3 Colleges and many Schools and business units. The second is the distribution with it’s added flexibility allowing customisation. And the final part is our design framework EdGEL allowing components to be taken and added to projects encouraging consistency and putting student experience at the centre of every project.

Continuous improvement

All these deliverables help us to work towards a process of continuous development rather than depending on large projects followed by periods of inactivity. This is especially important with the web. Technology changes quickly and unpredictably and the demand to be able to respond quickly was part of the original drive to build a flexible service in the first place.

Code sprints

While everyone was in agreement that this new collaborative approach was the way to go it was quite a change in our working practices and we needed some way to deliver a proof of concept and make some pragmatic steps to get things going. To kick things off we used the IS innovation fund to pay for developer time and also for food and coffee to fuel the day. While this code sprint approach is not new, we are following some well established routes in the Open Source community, it is easy to forget how innovative the sprints, the use of the distribution and the GEL are is in the University as well as more generally in a Higher Education setting. So the innovation fund was the perfect place to start.

So what is a code sprint? It’s borrowed from the Drupal community but is also common in many open source communities and comes under a variety of different names such as hack-day, hackathon etc. It’s basically a bunch of developers coming together in a room and working on fixes and enhancements but can also involve non-developers such as testers, UX specialists, product owners and support teams. With our first sprint completed and our second one planned we are well on the way now to proving that not only is the process possible but that it can be also be a building block for something bigger.

The start of a collaborative framework

Drupal has a very long established system of allowing developers around the world to work on all aspects of the Drupal CMS itself allowing them to contribute back to the main code base so that the updates are available to everyone. The natural next step is to allow this happen with EdWeb.

By doing this we can tap into a huge talent pool around the University. We have a lot of skill and expertise so it makes total sense to use this. It makes development quicker and more efficient but also contributes to a huge learning process. We need to encourage and nurture an environment where people are not threatened by colleagues asking questions, challenging approaches, offering up possible improved solutions. We don’t always need to be the best at everything immediately. That route stifles change and doesn’t lead to collaboration or allow the freedom to be innovative.

There are many benefits to this approach. Both in terms of running the service but also in how we work, code and develop in general. These include

• refining our code management processes
• increasing our adoption of version control software to host, share and ultimately protect our code.
• improving our processes for developers to work locally, within their own preferred environment and on their own device.
• recognising the importance of clear documentation when opening systems up to help colleagues get up to speed as quickly as possible.
• providing guidance, support and training, not just centrally, but as part of a wider internal community.

The fear of opening up systems is entirely understandable. A lot of us are running enterprise systems that are essential for core parts of the University’s business. Of course these need to be protected. And it’s this part of the collaboration process that is absolutely essential – defining the scope of the contribution. This contribution could be code, it could be design, it could be documentation. The important thing is to define that scope so that you can build a process that allows the contribution but includes the checks that are necessary to protect the system. It’s not impossible to do this. It’s not always easy and can take some lateral thinking. But if you build this opportunity for collaboration into your systems and combine this with a drive for innovation in your University Strategy people will come and want to contribute. It’s important not to panic and close the door thinking that people will break things, threaten the status quo or pull apart your finely crafted processes.

Into the future

With a large devolved community requirements for new functionality, fixing bugs and enhancements come from a wide variety of sources. By opening the system up and allowing more people to be involved in the development process it empowers stakeholders to work together to prioritise future development and find areas of common interest where costs and resources can be shared to maximise efficiency. While we have a strong and engaged community all the help we can get in homing in on exactly what our CMS users need the easier it is build the CMS that the University needs. With stakeholders fully engaged with the process we get their experience with their users which gives us a much broader reach across the University.

We just need to build on this work to develop a comprehensive and well documented collaboration framework so that we can move forward in a cohesive and coherent way. There are so many benefits to working in this way from getting things done to saving money. But the really big plus is that we can all learn from this process.

How to collaborate for a better University Website experience – a project to map a development collaborative framework for EdWeb.

Save

Save

Save

Save

Save

Save

Save

Save

Save

Save