|Case Study: Cardiff University & Napp Pharmaceuticals - A DSDM/Agile team|
Case Study: Cardiff University & Napp Pharmaceuticals - A DSDM/Agile team
Case Study: Cardiff University & Napp Pharmaceuticals - A DSDM/Agile team
Adam Mitchell, Senior Solutions Developer for Anglia Ruskin University and a member of Agile Business Consortium, explains how eight ‘magic’ PM principles ultimately delivered award-winning project success.
Picture the scene: a room full of business users with an abundance of exciting and somewhat extravagant ideas, senior managers from both the business and IT keen to deliver on time and in budget, and finally me sitting between the two sides trying to manage everyone’s expectations. That’s how it was, the first time we (later to be an agile team) met to discuss the how, what, who, why, and when.
Just a developer at the time, only really standing in for a work colleague (a project manager) who couldn’t make it, I had no idea that this was to become my first project management role, on a project spanning two different countries (well, England and Wales) and a team that went on to be nominated ‘Best Agile Team’ at the Agile Awards soon after the project was delivered.
I needed to find a way this would all work, take a step outside of my comfort zone, and throw myself in to it.
The project was essentially building a website for Cardiff University (www.paincommunitycentre.org), which we ordained to be ‘The gold standard for people seeking information about pain management’. This website was to be a portal for people enrolled in Cardiff University’s Masters Degree in medical pain management, plus also healthcare professionals and anyone else interested in information relating to managing and treating people in pain.
So the scene was set; lots of ideas from the business (too many if we wanted to deliver anything this side of the new year), the usual low budget, and a launch party already pinned in our calendars with lots of important people and the press attending to cover our anticipated success; suddenly it became very apparent that we had to deliver on time, else look very embarrassed at this black-tie event having to explain to the press why we had failed to deliver.
Luckily for us all, we didn’t have to explain ourselves, but like any project it wasn’t a smooth journey all the way…
So, how did we achieve what we set out to accomplish, and how did we manage to end up being nominated ‘Best Agile Team 2013’? Well, it all came down to a couple things; working together effectively as a team and managing the approach using Agile techniques.
From the onset, we decided to use DSDM; this meant that before we jumped in and started developing, we devoted sufficient time upfront to establish the team, the roles and responsibilities, prioritising our high-level requirements, and mapping our development, test, and delivery paths.
If I look back now at what really made this project work, I’d put it down to the eight principles that define DSDM. Now, I know that sounds a bit clichéd, but it doesn’t matter how skilled or dedicated each member of your team is - keeping a mindful eye on these 8 principles is what I put down to being our biggest factor for success.
1. Focus on the business need
Using MoSCoW prioritisation, the whole team was involved each time the requirements were considered, which meant everyone had a say. We made sure we reviewed their order of priority before we started each timebox, making sure only the most important stories were worked on; this was not always an easy task, but one that was absolutely critical if we wanted to deliver what the business needed, and not just what they desired.
2. Deliver on time
Having fixed our black-tie launch event with press coverage really set the challenge for delivering on time. We timeboxed our work to coincide with our monthly face-2-face workshops where we would review prototypes of the requirements that had been developed, and discuss the next requirements that we would start to develop in the next timebox.
Meeting regularly for teleconferences and facilitated face-2-face workshops involved the whole team, who were all empowered in decision making. This really gave us all a feeling of being ‘one’ team with mutual respect which motivated us very well. The tricky bit here however was making sure everyone was committed to attend; for this we alternated the meeting venue between Cambridge and Cardiff for our face-2-face meetings, and went out for a ‘social’ meal the evening before each meet-up. Nothing builds a stronger team in my opinion than removing yourselves every now and then from the work environment and getting to know each other better.
4. Never Compromise quality
From the outset, the development of the website was regularly reviewed in workshops by reviewing prototypes of the requirements in each timebox. After each review, the requirements were re-MoSCoWed to ensure we kept building in the expected level of quality and only focusing on what was important. Admittedly, testing could have been done earlier for the initial ‘Must’ requirements, but once the value of the testing was realised, it was done early enough on the remaining requirements.
5. Build incrementally from firm foundations
Before any development took place, we made sure we all understood the requirements we were going to develop (in each timebox) by discussing them in our face-2-face meetings. This gave us all a chance to understand what was being asked for before the features were developed in to the website. The technology to be used was also established upfront to counter the risk of choosing something the development team was not familiar with, and to make sure it could satisfy the requirements.
6. Develop iteratively
The requirements were split into clusters within timeboxes. As each requirement was developed it followed a process of investigation, prototyping, reviewing, refining, consolidating, re-reviewing, etc. Throughout this iterative process, we learnt a great deal and became better at anticipating the work involved for the subsequent requirements.
7. Communicate continuously and clearly
Weekly teleconferences and monthly face-2-face facilitated workshops helped ensure we communicated effectively. In addition, we had a project site (accessible to both the development and business teams) which was regularly updated with the project progress; showing which requirements were currently being working on, meeting minutes, next steps, a calendar of events, etc. Each requirement was prototyped and presented at the face-2-face meetings, to ensure everyone was kept involved and empowered to comment on it. Only once we were all happy with the outcome did we commence further work on developing the requirement.
8. Demonstrate control
The project plan and progress of each requirement was regularly updated, available to all members of the project via the project site. After each requirement/feature was developed and deployed, it was shown as being complete, giving us visibility on the progress of the project. It was vital that everyone felt we were in control of the project, and that we were on track to complete what we needed to achieve our goal every step of the way.
So there you have it, trade secrets on how to achieve success in a project? Not really, these principles can be found in any DSDM textbook; the trick is keeping them at the front of your mind throughout the project, during each meeting, whenever a decision has to be made, and especially when there’s uncertainty about what to do next. To me, being Agile is defined by these principles, though everyone has to buy-in to their value.
Achieving that certainly helped us deliver our website and enjoy the taste of success (and the champagne) at our launch party!