The idea of daily scrums is not for everyone. How are organisations adapting agile software development to improve project management?
In the bad old days, IT earned the reputation of being a great listener, but never really delivering on users' expectations. With the traditional waterfall approach, the IT team would spend ages on a formal specification for the project with the customer, then spend perhaps a further 12 months implementing exactly what the customer had agreed and signed off.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
But too often, the business had moved on 12 months down the line; the project specification no longer met the requirements of the business. Worse still, the ideas that sounded great on paper and in PowerPoint slide decks now looked out of place or clunky when running on a laptop demonstration for the delivered system.
Agile software development and project management has become a popular approach with IT teams who want to avoid losing face with their customers by keeping them in the loop. Agile overcomes the inherent disadvantage of the waterfall methodology, by breaking big projects into small chunks that can be delivered quicker.
The customer gets to see these deliverables on a regular basis, so there is less of a risk of someone saying, “That is not what I asked for,” when the complete project is finally delivered.
But agile is not the answer to all project management problems. Some people argue it takes away good project management practices, like setting a concrete specification. Time and budget control is also harder. While not deliberate, agile software development project teams can sometimes lean towards working first on the easier functional components in a complex project. So they may well get 80% of the work done, but the hardest 20% remains and it is these elements that may well constitute the success or failure of the overall project.
Read more about agile methodology
So organisation are adapting with an agile approach to the waterfall methodology, or spending more time at the beginning on formal specifications in an agile project and focusing on getting the hard bits completed first.
Take time to prepare
For the new Majestic Wine website, system integrator Javelin adapted IBM's Rational Unified Process with eight iterative steps, allowing Majestic's e-commerce director Richard Weaver and his team, to see chunks of the project every three weeks.
Yorkshire Water had to overcome internal resistance to a pure agile approach, so it adopted traditional project management alongside an agile methodology.
As a project manager, James Locker, senior IT project manager at Yorkshire Water, said agile software development provides many touchpoints.
"Personally the daily scrums worked very well for me, as they get everyone on board at a given day. I became more of a project lead, to ensure the team has no obstacles," said Locker.
Yorkshire Water spent time doing preparatory work prior to running the agile project, using Lamri, an IT consultancy. “We needed to align agile with existing processes. This required 10 days of extra work on the IT architecture,” said Andrew Griffith, managing director of Lamri.
Napp Pharmaceuticals' IT department also needed to do a lot of background work when it offered to help Cardiff University to build a Pain Community Centre website.
"We had to prioritise,” explained Adam Mitchell, who worked previously for Napp as a software are developer on the website. Cardiff University prioritised features to include in the project based on the MoSCoW approach. Working closely with the customer, in this case the project team at Cardiff University, Mitchell and the Napp IT team established a set of “Must”, “Should”, “Could” and “Won't Have” features to implement. Mitchell said this meant the implementation had 60% of features that were “must haves”.
Mitchell and the team from Napp ran regular reviews with Cardiff University. These reviews ensured the list of priorities was kept up to date, avoiding the mistakes traditionally associated with the waterfall approach to software development, where the customer decides on the feature set and only sees the finished product.
Mitchell said: “The hardest thing is getting people to commit to weekly briefings and monthly face-to-face meetings.”
For Mitchell, the project's success lies in the fact that the team across Napp and Cardiff looked at what functionality was essential for the new web site need. “We then build incrementally from a firm foundation,” he said.
The project plan was made available on a website so everyone could see it.
Ann Taylor, a reader at Cardiff University was the lead for the project from Cardiff University. She said: “We were part of the process, to test the website.” Testing involved assessing different user personas, based on levels of computer competency from novice to a gadget expert.
She said the project had been a success but added: “It doesn't look anything like I imagined it would look like, but we are getting 2,000 users a day, so there is lots of stickiness to the site.”