Risky Business

future aheadIn March I attended a visioning workshop held by the recently appointed Pro-Vice-Chancellor of Learning and Teaching, Prof. Belinda Tynan , and attended by 60 of my colleagues. The 60 were recruited through a competition for ideas, and the best ideas won the day, so the event had people from all levels and areas of the Open University which was a refreshing way to bring bright minds together. The workshop discussed where the Open University should be by 2025. The approach we took was designed by a group who work on Future Studies and involved starting at the global and gradually working down to our own turf; In the meantime losing the baggage of the here and now, and also finding ourselves forming a consensus by engaging in cross-fertilized discussions on topics to do with educational futures.

It’s fair to say that I found the workshop empowering and inspiring, it had everything from contemporary performance art to RSA style animation. I’m currently working on the area of “Innovation to Impact” which is very close to my heart and something I’ve been working to try to strengthen within the Open University over the past few years, working alongside Prof. Josie Taylor, the previous Director of IET, who has recently retired and with David Matthewman, the Chief Information Officer at the Open University.

Another supporter of this work has been the Director of Learning and Teaching, Niall Sclater, who has recently left the Open University to pursue new ventures. I raise my cap to Niall for the work he has done in the relatively short time he’s been at the Open University, including the introduction of the Moodle VLE (along with Ross MacKenzie) and the Roadmap Acceleration Programme, and most recently leading the Tuition Strategy work for the OU. I wish him all the best on his latest adventure! – I’m starting to feel like the last man standing in the TEL area.

Coming back to innovation, Ann Kirschner wrote a piece about Innovation in Higher Education a couple of years ago and many similar articles have since followed however I still enjoy reading her article as it appears to be well researched and still a good compass to where innovations are heading. Tony Bates also covered these areas recently in a blog post around a Vision for Learning and Teaching in 2020. We covered many of these and other aspects at the workshop but sticking to the topic of innovation and risk the main thing that rang true for me from the workshop was that we have become very “risk averse” (complacent) at the Open University and there was, among the 60 delegates a very strong sense that we needed to feel able to take some risks and to be more agile (a very overused word) to survive and thrive by 2025.

The “innovation pipeline” is a concept we’ve been considering (how to improve the flow between incubators and central areas, i.e. the journey from prototype to large scale mainstreaming). We want to improve this at the Open University and last year I gave a short presentation to the Learning Systems Advisory Group about that topic. I love the quote that I took from Ron Tolido, the CTO of Amazon, “@rtolido At Amazon, you must write a business case to stop an innovation proposal, rather than to start one. Silences 90% of nay-sayers”. The Open University is no Amazon of however we do need some of the pioneering spirit…

 

…in the past week I have also attended an “executive away day” for the Institute of Educational Technology at the OU, organised by the new Director of IET, Patrick McAndrew. Patrick has always been an keen early adopter of technologies and new ideas and he is wanting to making some organisational transformations with IET showing the way. For example, at the away day we went through a micro version of an agile project, we had a scrum, a sprint, another scrum and a velocity check all within one hour in the afternoon of the away day. The project was to develop an induction for new starters and we all took on tasks and worked through them, helping each other out. We have now taken the step to becoming an agile unit.

I have been using an agile approach to some recent developments, in particular for iSpot where I was hoping to start using the agile or lean approach back in 2012 (see my magile post) but only actually achieved any form of agile methodology last year when we started running into trouble and found that we needed to resolve issues with a much tighter timeframe and resorted to frequent (not daily but every other day) scrums and short sprints of three weeks. This worked very well and we were transparent with the project team which kept things ticking over and very quickly (within nine weeks) turned the project around and got it back on track.

I believe that Patrick wants IET to be a leading light for the Open University to become an agile organisation. I fully support him in this and I will be doing my utmost to ensure that we embrace this and to prove that adopting an agile approach does not compromise on the quality of output.

There will be more from me on the L&T vision workshop outputs once they are officially synthesised, endorsed and made available in the public domain.

Agile Ballooning

Over the next three months there are projects planned which will use 140% of the available resources. In reality this means that we’ve got to hire in freelancers and contractors to cover work and ensure we’re meeting all the commitments. All of the work is strategically significant and high priority, and I’m acutely aware that the funding available to make these things happen is only available until August is unlikely to be available again in the next couple of years so we have a small window of opportunity to get things done. I thought that I’d explain what the developments are and how we’re planning to manage them.

Firstly we’ve had a number of successful small bids by academic colleagues. One of the most interesting of these, led by Doug Clow, is the development of a community based version of iSpot – this project is called iSpot local and is JISC funded for the next six months. The project is around community engagement as much as technology and there are a number of Bio Blitz’s to engage locals. Because the system is can be largely standalone we’re using a freelancer to carry out the work and using a series of hooks to the main iSpot service. The plan is that the iSpot local modules will be made available and can be set-up by anyone using a generic Drupal instance. Then you request an API key to allow your service to connect to iSpot and transfer the data between the services. Without the key you’ll still get the local community toolkit but it only becomes really useful when you can overlay all the data, the ‘spots’, that are localised to your community. There will be a map which will be set to your region or area (you’ll need to configure it initially to set it for your region) and the sightings in your area will then be displayed. The freelancer is having to work pro-actively on a steep learning curve to get the services working efficiently but he has been making good progress and we’re confident that the system will be ready for the first Bio Blitz on the 21st May.

A second project which we’re currently involved in is around the aggregation and presentation of Digital Scholarship data, this is led by Martin Weller, this is interesting because it is getting data feeds from a number of existing services and pulling data to form a view of an academic’s digital profile. As Martin says

Boyer defines scholarship as being based around four functions: discovery, integration, application, and teaching. We can think of digital scholarship then as the changes in all four of these that are brought about by the impact of digital and internet technologies. For example, if we take ‘discovery’ to be largely synonymous with ‘research’ then a digital scholarship view would be interested in the way researchers are collaborating using new technologies, sharing and visualising data, forming research communities using social media, etc

Up to now we’ve been using a contract developer (Richard Greenwood) to build the service but Richard is now required on another project around developing android apps (see below) and so we’re employing a contract developer to complete the final phase of work which is around adding further data feeds and working with the researchers to develop the visualisations.

The third project we’re undertaking is to develop mobile apps for the iSpot service. iSpot recently passed the 10,000 user mark and so it’s at a stage where we’re considering the use cases and the baseline activities that need to be developed through to ‘production’ level service. I’m excited by the opportunity to work with the OU’s Knowledge Media Institute to create mobile apps. We’re concentrating on developing an app for Android and iPhone initially but we’re creating an API which can be used across mobile platforms. Richard Greenwood is going to be working on the API and also developing the beta iPhone app. The apps will allow users to easily use their phones to capture images and upload and share them. Because of the location specific information and the visual aspects of iSpot it is a perfect service to deploy as a mobile app and it will interesting to explore how things like the image carousel and mapping information can be recreated through an app.

The fourth project we’re working, led by Mary Thorpe, is called PePLE, the concept is to create a professional working environment to support social workers, as Mary says…

PePLE is a resource for the training and continuing professional development of social workers that can be used with flexibility to fit in with the operational demands of workplaces. The resources can be used to support independent study or existing employer led provision.

The site is unique in terms of the tools it provides and we had to make the difficult decision (as we did with Cloudworks) to use a framework other that Drupal for it because there were too many constraints within Drupal to allow it to be considered. By the way there’s a good blog post about the decision to move to CodeIgniter by another of the developers, Juliette Culver, for those that want to explore the pro and cons of different PHP framework environments. The work on this project is almost complete and the site is being used as a resource to support OU Health and Social Care courses.

The fifth project we working on is the development of the OU Media Player, which I’ve already blogged about in a previous post. Work is going to plan on this project but we’ve had to be very agile and flexible in our thinking and do some reassignment of work throughout the project, to ensure things get delivered as expected since there are fours units all working together on this project and the timescales are tight. There an early demonstration of the embed service in action (note not yet accessible!).

So these projects are all significant and all have deadlines of end of July. What are the lessons we’re learning for doing all these things together and with limited resource.

1. It’s the people who make the project work. Good people who are flexible in their thinking and are into solving rather than creating problems.

2. Being pragmatic. Don’t think you can do the ‘gold star’ service within three months. In particular getting a realistic scope and keep it realistic. The developers need to be good as deciding when the requirements come in how to manage those against existing ones.

3. Use freelancers and contractors where you can on the commodity items.

4. Keep reporting and documentation to minimum. Rely on the developers to self organise, using tools such as TimePanic to keep active tracking of their time on projects.

5. Organise meetings effectively. In the team we have a system which I’m exploring where we only arrange meetings on Monday or Tuesday and the rest of the week is purely for programming. This allows the ‘flow’ that is needed to develop. So all the team only arrange any project meetings on the Monday or Tuesday in any week. The meetings are kept short and a fixed agenda. I have monthly 1-2-1’s to check progress (the team use Google Docs to record their progress for these 1-2-1’s) and rely on project blogs to keep me informed of any day-to-day changes.

6. Issues are flagged up and recorded and resolved quickly and without fuss or blame. We assign an owner to problems and fix a date to have things resolved. We use the same Drupal module that Drupal.org use for managing bugs and feature enhancements. I bring in project support staff to assist me with organising resolutions if they involve multiple parties/units.

7. Ensure the developers are not ‘managing other people’s monkeys’, I use the 1-2-1’s as an opportunity to explore what the developers spend time on to try to ensure that the majority of time is on the development of the services and not on administration, design, support.

8. Be transparent. Keep active communication channels open with the project team, stakeholders and end users. This can be done in numerous ways and will help to ensure rapid feedback and iteration.

None of these things guarantee success but they help to reduce failure rates.

Are waterfalls agile?

People talk about agile but what do they really mean by agile?

David Matthewman CIO, OU

David Matthewman CIO, OU

I read a very insightful and interesting interview with David Matthewman, the OU’s newly appointed CIO, in Computing Weekly and I’ve also had a number of discussions with him about development and programming. In the interview he says “As part of a more disciplined approach to market methodologies, Matthewman will be introducing a more prolific use of agile and scrum development, as well as service management standards such as ITIL.”

I think this is a move in the right direction for the OU and for other organisations who similarly have adopted up until recently very traditional waterfall methodologies for enterprise level system development, however agile development methodology on it’s own won’t solve the problem. I read a paper last week commissioned by Hays for example which was about agile development called “The Elephant in the Developers’ Room” – it’s kind of drawing conclusions it wants to make the case for agile, but the headline statistics alone are stunning:-

  • 60% – 80% of project failures can be attributed directly to poor requirements gathering, analysis, and management, costing US businesses $30 billion per annum
  • 50% of major projects (defined as costing >£10m) are cancelled when at least 40% of spend has been incurred
  • 40% of system problems are found by end users
  • 25% of all spending on projects is wasted as a result of re-work
  • Up to 80% of budgets are consumed fixing self-inflicted problems
  • Only 8% of large-scale applications projects (those that cost between £6 million and £10 million) succeed.
  • Just 16% of software development projects close within acceptable constraints of cost, time and quality.
  • Cost overruns of anywhere from 100% to 200% are common in software projects.
  • IT workers spend more than 34% of their time fixing software bugs

Anyway I had a twitter discussions with some developer colleagues, which is by the way the best way to solve the worlds problems, and the conclusions were as follows:-

Agile methods alone wont fix the problem of very large developments failing.

Here are some of the practical reasons why very large projects fail from experience with projects of 60m+ which I been involved in with SUN and Microsoft and others who do this stuff well on the whole:-

  1. Some issues are behavioural to do with the makeup and background of the team
  2. Some are to to do with poor management, not specific project management but people management and lack of ability to think creatively, direct appropriately and react (important as scope changes)
  3. Project scope changes, so some issues are to do with inflexibility, not reviewing scope regularly and adapting
  4. Some are to do with lack of empowerment of developers, making them both understand and grow, giving them challenge and enabling cross working
  5. Some are to do with siloing of activity, “only X knows about that” mentality
  6. lack of ownership of issues “not my problem mate” – it’s everyones problem
  7. Good (critical) people leaving during the project. Perhaps there’s a place for a ‘golden handshake’?
  8. Some are to do with complexity. i.e.not breaking the big complex system build down into smaller manageable chunks.
  9. Some are to do with people not understanding the vision. Everyone must understand it.
  10. Finally by far the best projects I’ve worked on are ones where everyone contributes to the solution, feel tied to the success of it. The reporting, logging and reviewing processes serve a purpose that those in the project understand, i.e. it’s directly relevant to assisting them and their colleagues. The organisational structure is kept light and serves to help development, rather than for MI alone.

As we move into a more commoditized, off-the-shelf, ROI, SLA, cloud-based, shared solution, outsourced, yield enhanced and recession proof world it’s important to remember that the ‘uniquness’ of an organisation is created through the innovations that come from within rather than without. Developers can still add that uniqueness to an organisation by building bespoke services very well and at scale.

We’ve just started a venture to develop the OU Media Player for example which is going to create ‘the worlds’ most accessible media player’. It’s built using existing services but we’ll add the value to make it provide captioning and accessibility services and to link to all OU media materials on a variety of platforms including the VLE. This is a very small team working over the next five months in an agile way. I’ve got 100% confidence in it’s success because it’s a great team, everyone understands how important it is to the OU and they’re being given the freedom to build it iteratively, creatively and well, i.e. serving the OU’s mission in being “open and accessible”.

Chief Information Officer

We’re currently recruiting a brand new CIO post for the Open University. This is a major leap forward in thinking at the OU and the emphasis of the post is to provide the cohesion between the technology areas of the orgnisation and to manage the complexity to meet business needs (my interpretation – the recruitment agency use much longer more business savvy words)

Historically the OU has been like many other universities and has had ‘ogranic growth’ of information services with a number of faculties leading the way and then some of the technologies getting adopted more widely and then becoming part of a centrally run service, some services from the central support units also get used more widely and some student technologies  get adopted by staff so there are many different technologies and service in place at any one time.

In the recent past there has been a push to centralisation and control and AACS (the Academic and Administrative Computing Service) at the OU has had a difficult job of managing that without having any direct authority to remove other services in place in other parts of the University. AACS also started out as supporting just the admin services with the academic services within another unit. The expanding to support academic systems has also not been without problems. AACS haven’t had influence (or sometimes awareness) over what other units develop for themselves and so there is a multitude of systems with overlapping or duplicated functionality.

The issues always tend to end up as a tension between providing a balance between control (security) and access (openness).  We generally want openness in our services to students, with ‘widening participation’, ‘freemium’ and ‘OER’ being the flavours of the day. We generally need tight control and security of our administrative services and our business critical systems to ensure that we can guarantee business continuity.

There’s also a need to ‘move up the value chain’ and leave the low level service provision to others. The ideas of commoditization and the consuming and adapting rather than building it all ourselves approach of the past and the move to the cloud… (I’m simplifying here but Simon Wardley explains it better than I can)

The answer seems to be the creation of a post which sits at a very high level and is seen (at least theoretically) to be above any single technology area – to be a director of information services and a broker between the different parts. It’s also someone who reports to our ‘Vice Chancellors Executive’ so therefore someone who can explain strategy and can push back at some of the views in order to build a service that meets the future needs of the University.

I think this is a very positive step for the orgnisation. The post is not only to align development but also to think about agile approaches to delivery and to manage a path to facilitate growth of services from research through to operational (where appropriate), from single unit to multi unit to enterprise, from centrally through to distributed, to facilitate cloud-based or shared solutions. It’s to act as the business architect. A role sorely needed.

Planning blight and JFDI

I was watching the gadget show the other night with Nikki and they showed a remote controlled Hummer (£37,000 car) that they were able to race around a real dirt course. The research is done by Cranfield and Nikki turned to me and said Cranfield are always doing good stuff like that why don’t you guys do good research. I of course said that we did. She said that what we should be doing for example is making a VR suit for disabled people to interact directly with their brain a nd allow them to explore VR worlds as if they had no disabilities. (read the Otherworld books by Tad Williams for the concept). I said hmm. Yes we could do that. She also said that we should rig up a system to suspend people from so that they could act out the actions conducted in a virtual world and get the total immersion experience (again Otherworld). I said Hmm. Yes we could do that.

I spoke to Patrick about this yesterday. I’m not sure about the whole VR thing but it would be good to do some work exploring hacks we could do with the Wii mote for example, by doing some ‘mashing’ of various technologies. I’ve always been a fan of this type of string and glue approach to developing stuff. He was talking about colleagues that have built the equivalent of Microsoft Surface for under £100 by using a table, projector, tracing paper and a good bit of software. I was saying how of late there is a level of project amanagement to everything we do that makes delivery take long and be less satisfying that the agile approach that we used to adopt (i.e. a clever academci and a clever devloper working together doing seat of the pants iterative prototyping). We are doing that with Social:learn so I’m doing some direct comparison and I can see how much better that approach can be with the right people and a good set of support tools. (we use Skype, Pidgin/Jabber for IM, Twitter and a Wiki to help share development stuff). Patrick said it was time we created the JDFI. “Just F*ing Do it” group. I really think we must escape to bonds of planning blight that can occur during a restructuring process and instead JFDI. That’s my main objective this year.