Introducing Audrey

Reflective tiles on external wall of Elliot College extension

Last week Angela Watson and I gave a presentation to the Academic Division on the Kent XCRI project. We explained the overall aims of the national XCRI-CAP initiative and how that would bring benefits for propsective students and others but most of our presentation concentrated on introducing the fortyor so people present to the prototype Programmes Plant – the course administration system we are developing. The Programmes Plant – affectionately known as Audrey for reasons which I will leave you to work out – aggregates the data we need for the XCRI feed but it also does much more. It is a multi-user PHP application which next year we will roll out to administration staff in schools and departments – many of those in our audience will be directly affected by the work we are doing. Faculty staff will enter information on programmes, learning outcomes, entry requirements etc directly into the application. After moderation by the Publishing Office to make sure entries conform to our Style guide and other rules, the data can be published direct to the course pages on the web. We are confident that the benefits of the Programme Plant will rapidly become apparent to all users – though of course we can’t deny there will be some disruption whilst we retire old systems and get users up to speed.

Although not a stranger to speaking to groups small and large this particular presentation was making me nervous – I know Angela was having similar thoughts. We decided on a live demonstration of the prototype despite the misgivings of some of our developers. They didn’t want to be left with egg on their faces if the prototype threw up an error. Angela and I perhaps had more confidence in them than they had in themselves. Or maybe we were just foolhardy? Anyway, as we had expected Audrey behaved impeccably. I think a successful live demo in real time can really boost the audience’s faith in a team’s ability to deliver. Much more effective than a few screen shots of ‘how we think it is going to look’. It makes the transition from some ethereal future vision to something – well, ‘concrete’ is probably not the right term, but I think you get my meaning. But it wasn’t that that was making us nervous anyway.

I think it is always difficult to ‘announce’ to a group of staff that ‘this is what you are going to be working with’. No matter how much consultation you carry out beforehand, there will always be those who think you have got it wrong or didn’t take their advice or that the old method was better. And sometimes they are right. But not this time we hope! Audrey Version 1.0 will not be perfect – like any other software it will be tweaked as the users start to use it for real work. Users will feed suggestions back to the developers so we can continue to improve it and fix any bugs. Even so, we have worked very closely with the product owner throughout the whole project and so we are confident that users will see benefits immediately.

I think what really made us nervous was that in preparing for the unveiling of Audrey we came face-to-face with the realisation of just how important the work of this project is. Not just to the project team, not just to the Publishing Office, not just to Schools and Departments – but actually to the whole future of the University and to all our staff and students – prospective and current. Does that sound over dramatic? I don’t actually think it is. Now I am not saying that we weren’t somehow aware of this anyway but when you have to explain what you are working on to someone not directly involved you do have to step back and put things into the context of the bigger picture. Within the project team it is easy to concentrate on whatever particular facet of the project is current and lose sight temporarily of the whole.

To put things in simple terms, we are building an application that gathers data which will form the bulk of our public-facing output. The Programme Plant will aggregate data for the XCRI-CAP feed but will also manage all the data for Kent’s on-line prospectus pages. It will also be the basis for much of the data that we will provide to Unistats (KIS), HEFCE,UCAS, third party websites such as prospects.ac.uk and other websites which may not even exist yet. All these things are important but without on-line course pages we would struggle to attract students. This is a project we have to get right.

I am pleased to say our presentation went very well and the work of the project was received with (almost) universal enthusiasm and approval. As I have already said it is not as if we didn’t know this work was important but it is worth sometimes taking a few moments to remind ourselves.

Preparing for the next technical sprint

Autumn has arrived

With the KIS Widget now configured, tested and implemented on the University of Kent course pages we are now doing some preparatory work for the next technical sprint at the beginning of November. One of the areas we will turn our attention to is a proposed re-design of the way we present data to prospective students on-line. Staff in Enrolment Management Services have drafted enhanced and improved course pages and held discussions with other members of staff to fine tune these suggestions. Some of the changes are aesthetic or aimed at making the pages more readable and accessible. Other changes present additional data or links to related data – such as student profiles and information about Open Days. The KIS Widget, of course, features too, under a Further Info tab. Angela Watson will bring these proposals to the next XCRI-CAP Implementation Group meeting on Monday so we can continue the discussion and make plans to implement the changes.

Although at times the amount of work needed to reach all our milestones has seemed daunting I think the project team has managed to remain positive and enthusiastic throughout. For me it seems like we are reaching a point of synergy between different strands of the project. All these strands are obviously concerned with getting essential information to prospective and existing students, whether through printed materials or through internal and external websites. We still have a way to go but I think it is fair to say that we have unravelled a rather confusing and convoluted ball of information flows and now we are pulling them together in neat ordered lines towards our goal of an efficient and easy to use and re-use course data collection and publication suite.

However I do not want to sound complacent and previous experience has shown that until systems are released into the wild and used in earnest by experienced practicioners we will not be able to judge how succesful we have been. There may still be one or two knots left from that ball of confusion.

On November 1st our team of developers will begin the next technical sprint. We have had a largish gap since the last chunk of development but will catch up with six 2 week sprints back to back. We have planned how we will use each of these sprints and aim to start with UI tweaks for the Programmes Plant and Load testing. Load testing is vital as we need to be confident that the application will retain good response times at those times of the year when the number of users which be much higher than normal. It is of course during these high pressure periods that the advantages the Programme Plant will bring will really prove their worth.

We will also use one of the upcoming sprints to create an inital XCRI feed and to test it against the validator. Now the Programmes Plant has reached its current stage we are reasonably confident that we can produce the XCRI feed without too much additional work but we don’t want to risk leaving this until the end of the project. Just in case.

Load Testing the Programmes Plant

Staff in the Enrolment Management Services department continue to give feedback on the new course data administration system – most of it positive I am pleased to report. In the next few weeks we will carry out load testing on the system. We are currently working with staff who will use the system to create realistic scenarios to test against. This is never an easy task as many factors can influence how many people will be using the system at any one time – one of them being the design and usability of the application. Often there will be very few people logged into the system and even less actively using it but at certain peak times that number will be much higher. Working out how much higher is the problem. The best estimate we can make is that between twenty five and thirty would be a reasonable maximum to expect to be using the application during ‘normal’ periods. Not all of them will be processing data constantly – some may be using the system to check and locate data – which will cause less strain on the servers. At peak times – say shortly before publication of a new prospectus – there may be as many as fifty or sixty users on the system.

We are hoping for a positive result from the load testing – it certainly cracks along with only a couple of users on it. But if it does not perform as well as we would like there are things we can do and at this stage of the project there will still be time to do them. We could beef up the hardware and we can isolate processes or even lines of code that are causing bottlenecks. If these measures do not increase performance to an acceptable level we might have to look at staggered workflows.

Our next technical sprint – aside from load testing – does not begin until November. We are using the time until then to look at how we might be able to re-use data which is managed and stored in other university systems such as the Student Data System and the Module Handbook Database. The ideal is one authoritative source of data but this is not so easy to achieve as one might first think. If data only flows in one direction – feeding the new Programmes Plant – then we will potentially have a disconnect with the source if data is edited in the new system. But we do not have the remit nor the resources to develop the originating application to keep it in synch.

Our current methods for storing, editing and publishing course data are circuitous and less than efficient with much potential for disconnects and differing versions of data. We have to face the fact that within this project we are unlikely to solve all the problems but if we design these first steps well we can build on this work and continue the good work in future projects.

On the KIS data front we are ready to go though I think it is fair to say that the size and design of the KIS widget has not won it many fans around here. It would have been nice to have had something that we could customize to tone with our online prospectus a little better. Early days I guess…

Spotlight on the Programmes Factory – or is it Plant?

Just a quick update in this blog. After a fairly intense period of development and prototyping we are just about up against clearing. So developers are going to be somewhat occupied. We have one more feedback session with the product owner this week. Time to take stock and look at some of the less technical – but equally important work packages.

We have been beavering away as a fairly small group for the last couple of months and I think it is fair to say we are pleased with progress on the new Programmes Plant software. (Is it the Programmes Plant or just Programmes Factory II? Not sure really but we can worry about that later.) The development of the Programmes Plant up to this point has mainly been about how it will be used by the EMS team. We have worked directly with those who will use the system in that department. This has required a great deal of commitment from the Enrolment Mangement Services team as well as from IS but the result is that we are delivering what is needed. It is a really important consideration for any HEI or FEI considering going down this route – the mebers of staff who will be the users of the system must be given the time to provide a high level of involvement – which of course means many hours – if there is to be a succesful outcome.

Now we are ready to start spreading the word and looking at how others in the Faculties and Schools will feed data into the system.

So one of the tasks for the next few weeks will be to introduce the work done so far to our colleagues in other parts of the university. Although we have complete faith in our developers ability to build the application, it will not exist in a vacuum. The Programmes Plant is just one part of a whole range of systems – some software based, some manual and some a mixture of the two – that are needed to get out course data out to those are, and those we hope will be, studying at Kent. And of course to produce the XCRI feed. The long term plan is that these systems are automated and will talk nicely to one another but we cannot achieve all that within the life of this project. Neither can we continue with disparate systems that have the potential to get out of synchronisation and necessitate duplication of effort. To bridge the gaps and maintain communication between our current systems we need to be confident that we have appropriate, efficient and comprehensive workflows in place.

We need to map out how our colleagues in the Schools and Faculties will interact with the Programmes Plant and, where data flows are not yet automated, what manual triggers we need to put in place to capture the creation, modification and termination of programmes and associated marketing information. Some of this information we may be able to get via web services from the Admissions system and the Student Records systems but for the time being some will rely on email notifications and on-line forms.

There is a positive mood in the team at the moment and we are looking forward to demonstrating how far we have come and talking to our colleagues about next steps.

Improving the Modules Catalogue

Follow up demos of the Programmes Plant prototype application (see previous blog) went well and we have another technical sprint booked to begin on June 14^th. This is a double sprint giving developers four weeks to work on the next version of the prototype. In preparation for this Mark Fendley, Scrum master and I met with customer representatives on Monday to refine user stories. Following a final sprint planning session on the first day of the sprint we will hand over to the developers to do their stuff.

Meantime the project team have begun the work of looking at Kent’s module catalogue. It is beyond the scope of our XCRI-CAP project to deliver a new application to deal with modules. The current module catalogue software works well but we have identified a few possible improvements which are within the project’s remit. Our project plan states that we will do some work to

improve data quality,
add or enhance searching, grouping and collections functionality and ;
clarify the purpose and remit of the Modules Catalogue.

Nick Thurston kicked off the practical work on this by running validation reports to identify ‘orphaned’ modules – the Student Data system appears to confirm they exist and are active but detail is missing from the Modules catalogue. (Details of these modules are available on the School or Faculty websites). The missing data is not evenly spread across the schools – but I shall not name names. Now these anomalies have been identified the Faculties have been asked to rectify things but that is just the beginning. To have a lasting legacy the project will put in place workflows to try and ensure data stays in synch in the future.

It is interesting to observe that as a result of getting stakeholders from departments who deal with the different parts of the module and programmes lifecycle many of the problems identified at the beginning of the project can be solved almost immediately. For example: Person A says I need to know when X happens. Person B says well when X happens we send out an email to Y & Z. Shall I add you that list? One of the greatest values of projects like the Kent XCRI project is that it gets people together and gives them the space to talk about things. In our busy day-to- day working lives we often just don’t find time for that.

Introducing the Programme Plant

Following the technical sprint the project has been able to deliver a working model of the Programmes administration application to the customer.

A great deal of work has gone into the project since its beginning but it felt like a significant milestone was reached this week. The work of the second technical sprint drew on the groundwork previously completed in compiling user stories from discussion with the stakeholders and making a great effort to understand the customer requirements. Mark Fendley did sterling work in marshalling this work and creating the story cards – a master Scrum master. We had committed to delivering wireframes for homepage and data entry screens and a minimum viable product – a working model with at least five editable fields. However the time invested in evaluating the best platform and framework for the application really paid off allowing the developers to leapfrog over many of the wireframes and produce a working model with a really good looking user interface. The initial feedback from the customer has been really positive and this great job from the development team has really boosted the project.

Of course these are early days in the development of what we are currently calling the Programme Plant but this is a good start. Currently the model only exists on a webteam laptops so cusotmers have not been able to get any hands on experience. A component needed by the application was not available on the server so we had to compromise. This component will be inplace by mid-June prior to the next technical sprint. In the next sprint we will begin load testing – something we are committed to doing at every stage of the development.

Those interested in some technical detail on the experience of the developers in working with the chosen platform – PHP on a Laravel framework – are recommended to check Matt Bull’s blog and comments from others which can be found here: Webdev blog

This week we will present the working model to other stakeholders and seek further feedback. We are committed to incremental development and will spend some time before the next sprint – which begins on 14^th June – analysing feedback and looking again at the users stories.

Well done to all involved in the project!

Another technical sprint begins

Blue skies reflected in a campus pond

Today marks the beginning of another two week technical sprint on the project. This follows the inaugural Steering Group held on Monday, which endorsed the team’s recommendation that we should develop a new Programmes Factory from the ground up using PHP. A couple of days later we held a very succesful planning session with our colleagues from EMS and took delivery of Angela Watson’s excellent handiwork – the core list of data fields.

Mark Fendley, our scrum master then prepared user story cards from what turned out to be a very useful planning meeting. The project start period was always going to feel a bit slow with lots of talking and apparently not much happening – though this was a very necessary stage. It now feels that we are entering a much more ‘hands on’ phase.

By the end of this sprint we should have created the basic data model, though we expect to have to tweak it a little as the project progresses, and have created a ‘proof of concept’ user interface form. This will allow us to seed the database with test data and to perform some early load testing.

As mentioned before we want to deliver the application incrementally to our customers and seek reviews and endorsements for each stage of development. Here’s hoping for a suceesful retrospective at the end of this sprint.

Kent XCRI

The University of Kent XCRI-CAP blog

Author Archives: Leo Lyons