GlowPlus? The Agile Solution

In my previous post I posed several questions. How can a small agile development group ensure the delivery of a service to over a million users, the security of their data and the platform? How can they provide great support for mobile technologies and meet the expectations of a user group who have come to expect intuitive, responsive and always on online services such as Facebook, Twitter and Skype?

Rule 1- Don’t do it all at once

GlowPlus is an agile development, a “finished” product should never exist. It will continuously innovate and develop new services and features. A small agile team can do this. Why? Because agile development focuses on a constantly developing working product, developing through small incremental changes and always having a working product available to test.

What are the immediate priorities for GlowPlus? Authentication and user management; that has to work with Office365 when the RM Service is switched off on December 15th. There are already tools, software and working examples out there to do this. It can be put together using OpenSource software (simpleSAMLphp for example to provide the Federated login just as we have now) and Microsoft ADFS2.0 server. Creating a new authentication service that works to the scale required in the time available isn’t unrealistic. In fact, it is one of the easier tasks ahead of us.

A small agile team would agree a road map with key stakeholders and the programme board. This road map would detail the priority services, functionality and tools to be developed and deployed. Following this all partners would understand the future of the platform and the nature of the tools/services which would be rolled out over time.

Rule 2 – Use external expertise for your deployment

A small agile group can develop a service, I’ve already shown with Glew what is possible with the tools available, but to deliver this to scale and keep the service running requires additional expertise with some level of experience. There are at least two options here.

Option 1: Move to the cloud and deploy a solution on a service such as Amazon’s Elastic Compute Cloud service which can adapt to meet service requirements and is available as a pay as you go service. We only pay for what we use – minimising costs but with the benefit of the scalable infrastructure of a large deployment partner. With this option the Agile Development Group would still operate the system but the hosting and infrastructure would be in the cloud.

Option 2: Use the procurement service to find a deployment partner who would operate the service on behalf of the Agile Development Group. The Agile group develop the system, test and support it but for deployment the code is handed over to a third party to do a security and scalability “sanity check” and then to deploy. Two groups working in partnership to develop and deploy the service. With this model the deployment partner can change over time however the actual platform remains because it is owned by Scottish Government.

Both these models ensure that the core authentication service and tools remain constant and under the governance of the ICT in Education Programme board. We also avoid the problems we have with managing change and innovation. As we know from bitter experience locking into one supplier means that innovation will not happen.

As for security, a small agile team must take steps to ensure that the platform they are developing is secure from attack and that user data is protected.  For previous work I’ve completed I have used online security audit tools such as McAfee Secure to audit sites and report on security issues.  Such tools scan your site daily, looking for flaws in the site security and then reporting on any they find.  They try to flood (overload) or hack your site.  The McAfee tool does this very well, so well in fact that if a report is generated stating that the site is secure then banks will accept this as proof that the site is Payment Card Industry compliant.  This means the site is secure enough to handle card payments. In addition to this regular security audit, the services of a penetration testing company can be procured to carry out additional security testing of the platform.

Rule 3 – Listen to your users

The agile team developing GlowPlus must listen to stakeholders. There is no point in developing (or paying for) a platform that doesn’t have users. GlowPlus must be a service that attracts users, a service that responds positively to user requests and meets users needs. There should be regular interaction with stakeholders (end-users) to shape the platform and to test new features.

The only way to turn around rapidly falling user numbers in Glow is to innovate and offer users something that meets their needs. Linking the development of support for curriculum for excellence and the development of a user-friendly needs driven platform for learning should result in an improved user experience resulting in increasing user engagement.

And if you get the platform correct, because you have engaged with users, then the training needs and support demands will be significantly reduced.

Rule 4 – Move fast, break stuff

GlowPlus must always be fresh, there should always be something new – some small innovation or addition that engages users.  If a problem is identified, get the fix out as soon as possible. If a service is required, get it out as soon as possible. If users have change requests, get them added to the workflow and released.

A small agile team can shorten the time between development-testing-deployment. Agile development is about having working software. The team will always be focused on having something working. Additions to the scope of the software are just added into the daily operations of developing and innovating. Yes, there will be the odd mistake in development but it will be identified in testing and feed back into the cycle of quick changing iterations of the platform.

With GlowPlus we shouldn’t be scared to make changes.

Rule 5 – Depreciate and then remove

Everything dies, so too the services in GlowPlus – but nothing in GlowPlus will ever disappear overnight. The agile team will manage change by giving notice that a service will stop, well in advance. That service will be be depreciated first (so for example, the main support for that service will be removed but it will be accessible) and tools will be developed to allow the user to migrate his/her content from the service into the replacement service.

Notice I said the user does the migration. To reduce the pressure on the agile development team, as much of the work as possible, in terms of managing user data, will be delegated to the user. If you can move your data from one service to another using a simple step-by-step wizard that does the heavy lifting for you, then it makes switching from one service to another relatively painless.

Once depreciated, the end-of-life of a service will be clearly indicated. Any user that doesn’t move his/her data before the end of life will lose it. This is also a practical way of thinning down the bloat of “dead” content (stuff that users don’t want any more but have just left sitting) that develops over time.  Dead Glow groups, file stores not accessed in the last three years, blogs with the last post over two years ago etc.

Rule 6: Get some, if not all working on mobile

Mobile is different – you have to design and build for mobile. Generating tools for desktop and mobile are two separate streams of work. We need to look at the needs for mobile and ensure that the GlowPlus platform can deliver on these needs.

That means, for example with Moodle and WordPress, where there is already mobile support through native Apps for iOS and Android, that we support them.  All the GlowPlus developers need to do is ensure that GlowPlus supports these tools.  We can support a vast array of mobile computing with just a little joined up thinking.

Rule 7: Be realistic, if it can’t be done say so

Under promise, over deliver.  If things don’t work – tell your users. GlowPlus as a platform, the agile development team and all processes around the system must be utterly transparent. Nothing hidden, discussion in the open and pre-empt negative opinions with honest statements about the challenges and developments.

If the governance of GlowPlus has integrity then users will trust the platform and those leading it’s development.

Wrapping it up

As long as a small agile group is focused on innovation and core development rather than running boxes/servers or doing 1-2-1 training, it should be possible to deliver the outcomes for GlowPlus that we want.

*All Dilbert Cartoons from http://search.dilbert.com/ by Scott Adams