CSIRO is one of the world’s leading scientific research institutes, credited with some of the world’s leading inventions that we all enjoy today- you can thank them for the WiFi you’re probably using right now as well as the plastic banknotes in your wallet and even for keeping pesky mosquitos at bay (yes, they invented Aeroguard too). It’s fair to say that none of these amazing breakthroughs would have been possible without a high level of collaboration between teams at CSIRO.
But in mid-2014 it was becoming apparent that CSIRO’s scientists were being bogged down with administrative tasks, leaving less time for collaboration in order to make more scientific breakthroughs. It was time to make a change to the way the organisation operated to support its researchers.
SROM (Supporting the Research Operating Model), is an enterprise wide initiative built around collaboration technology to enhance productivity, reduce administrative burden and unlock researchers precious time to concentrate on making important discoveries. As part of this initiative the IMT team learnt some valuable lessons about delivering collaboration technology the agile way.
1. Connect People Through the 3 C’s
With a workforce of 5000+ people spread across 54 locations nationally you need to rely on technology that is ‘connected’. Online technology that connects people through Conversation, Communication and Coordination to keep everyone on the same page with what’s going on. If your bespoke technology is disjointed or disconnected you’re in for a world of pain at this scale!
2. Play by the Rules
Everyone needs to understand the rules, where the goalposts are and which way they’re running before they take the field. If you’re going to rollout new solutions in a new way, take the time to coach people on how to play the ‘Agile’ way because most have been working the ‘same’ way for years.
3. Take the Time to Listen
Often IT think they know what the best solution is and will present users with a solution before they’ve really understood what the problem is. Business users often come saying ‘this is the product we need’ but can’t express the reasons why.
It’s important to take the time and effort to listen to what people need and then interpret these needs. Asking some fundamental questions in order to uncover their real needs instead of their wants is imperative.
If you invest the time upfront it makes the product development process down the track much easier with greater potential for success.
4. Demonstrate it Right the First Time
Only after you’ve listened to your users and really understood what they need should you show them an example of what their solution might look like. In the past we’ve shown our users something out of the box but this often makes no sense to them. It has no context within their day to day work.
Demonstrate the solution right the first time by showing the right people the right thing – and not everything! This is easily done by mocking up a very simple prototype. Something that can be done in hours or days is all we’re talking about here.
5. Accept a Minimal Viable Product
For our SROM roll out, we adopted the Lean Startup principle of the “minimum viable product” (MVP). A MVP solution gives your users some functionality they can use in production straight away without having to wait for everything. It gives them an early look at what the product will evolve into and is a great means to deal with requirements in practice, rather than in theory.
Acceptance of a MVP approach requires strong education with an emphasis on getting things regularly rather than waiting for everything. When a MVP solution is implemented successfully it will bring back those stakeholders who’ve had negative experiences with IT solution delivery. Those solutions that previously took a long time to build (sometimes more than 12 months) and often no longer meet their needs because their needs have changed since the process had started.
6. Define Requirements the Agile Way
For our SROM rollout, we moved away from traditional requirement gathering and towards a more flexible approach. So instead of producing lengthy requirement documentation that described everything in detail, we did enough to produce working prototypes. Based on those working prototypes and user feedback we then set about building our minimum viable product. This agile method of requirement gathering is less document focused and more flexible and creative.
We know this process works, it’s been tried and tested at CSIRO many times. But there are times when we have to go back to step one because people are quite embedded in that traditional way of working. The trouble is the traditional way takes too long, costs too much and leaves everyone disappointed with the result. We’ve found a better way and we’re sticking to it!
About the Authors
Sarah Blake is the Manager of Business Workflow Services at CSIRO. Sarah leads a team that is responsible for delivering new collaboration solutions and educating users on their effective use.
Norman Spurr is the Executive Manager of the IMT Applications team at CSIRO and is responsible for group strategy, execution, capability and portfolio delivery.