Time to get Agile

1 2 Page 2
Page 2 of 2

The approach let the company “pick the four smartest people we have in the company and let them organise their own programs”, Smith explains. “We stepped completely out to act as coaches and mentors, and within two weeks we had moved 50 per cent of our total delivery capacity onto this program under the auspices of four people that had never led anyone before. It’s been a phenomenal exercise, and a phenomenal success.”

Next: Building teams and governance

Page Break

Team building for the future

The push towards Agile business forces reconsideration of project roles, but it also pushes CIOs to become better at facilitating interaction between team members. Some developers have, for example, pushed back against paired programming, an Agile technique for increasing visibility and speeding problem-solving.

Others have struggled with regular stand-ups and ongoing business engagement, which mean their work is held up to the light far more frequently and intensely than in the past. “Developers often aren’t used to dealing with the business face-to-face,” says Bankwest’s Weir.

Yet people from the business also struggle as they’re pushed from being a passive customer to an integral part of the Agile delivery effort. “These are people that have been completely isolated from the very reality of what it takes to deliver capabilities in an organisational context,” says RGA’s Melville. “Now we’re pulling them onto projects and it’s quite confrontational: Not only are we pulling them in, we’re foisting on them a whole new level of accountability and expectation.”

Weir has experienced similar issues: “By bringing the developers and testers directly face to face with the business,” he says, “they often ask questions — and if the product owner can’t answer those questions unequivocally and quickly, it’s pointless putting them all together.”

The key to resolving this dynamic is making sure product owners have the attitude and authority to make decisions, Weir says. But such issues are only the beginning; in order to facilitate Agile development CIOs must also address what may seem like some quite pedestrian issues, such as ensuring team members get enough ‘face time’ and dealing with the logistics when teams are split between sites. “Distributed Agile is hard to do,” says Suncorp’s Smith. Energy distributor, Jemena, recently faced this issue in working with integrator DiUS Computing on a year-long Agile redevelopment of its core energy management systems that was split up into four discrete projects managed using ‘sprints’. Up to 15 DiUS workers, along with a handful of staff from other organisations, conducted group stand-ups via videoconferencing, instant messenger and collaborative whiteboard applications, and the team embedded developers from Sydney to Melbourne, and vice-versa, to minimise isolation between sites.

Subcontractors add another element to Agile projects. Their programming skills may be valuable, but they can also lack the organisation’s enthusiasm for Agile and could potentially become an obstacle if they’re not playing by the same rules. Subcontractors can often learn to play along pretty quickly, however, when provided with short, sharp tasks and clearly defined goals.


CIOs must also consider the effect of Agile on conventional governance models. Agile adopters seem to value function over form, with one survey finding the most important success criteria are, in order, functionality, quality, time/schedule, and money.

“Our issue [with the business] isn’t money; they generally want to give you money,” says Suncorp’s Smith. “Our issue is more about constraining their thinking about how much throughput they can take to their business change, because a lot of things hit the same sets of people. Chemistry and cadence are really important.”

The priorities reflect Agile’s relatively flexible approach to scheduling and its focus on delivery rather than budgets. But they also have implications for the business, such as project documentation. Developers and business leaders often have widely varying perceptions of the importance of documentation, but Agile’s focus on delivery often pushes developers to compromise documentation standards.

It is a deliberate compromise that also reflects the tendency of Agile projects to change in mid-stream. “We’re all technologists and prefer to build software than document it,” says Paula Ngov, senior consultant with DiUS Computing, who led Jemena’s development work. “Rather than completing a full-function specification, we documented them in the form of a behavioural-driven development, in plain-English business language.”

RGA’s Melville has waged a similar war on documentation, eschewing project managers’ traditional Gantt charts for more direct communication and collaboration.

Sensis’ Sullivan is more direct: “Documentation delivers nothing to the business,” he says. “You can’t sell it; it doesn’t return more value; and it doesn’t help customers. What brings money in is actually the code that meets the needs of the business.”

If Agilists seem to be taking a relatively mercenary approach to project development, that’s because it’s in their blood. In the end, Agile is about removing traditional roadblocks to development and encouraging a flat organisational structure that nurtures collaboration, exchange, reflection, adjustment, and mutual progress.

Fostering successful Agile development, however, can even involve changing working spaces — known as ‘bullpens’ in Agile speak — as Bankwest’s Weir found out when a consultant from development partner ThoughtWorks came by for a spot check six weeks into the project.

“She asked why we had put the team in a broom closet,” Weir recalls. “I realised we had set up this strategic objective that said Agile is very important, and that we’re going to throw everything behind this, and then we hadn’t even changed the tiny room where our Agile team was meeting.

“I wasn’t fully behind it because I wasn’t providing the right tools and the right environment to let that thrive. If you’re going to get behind it, you’ve got to really get behind it; it isn’t just about a development methodology; it’s about every single component coming together to make it successful. We’ve invested a fair bit of money creating formal Agile spaces, and the team absolutely love it.”

Copyright © 2010 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2
Security vs. innovation: IT's trickiest balancing act