TUI Travel, based in the UK, is a broker for European vacations. I had a chance earlier in the year to speak with one of TUI Travel’s development team leads. A story on the intersection of data and database management, change management and continuous delivery is coming out soon on SearchSoftwareQuality. This article on Agile development at TUI is a bonus.
John Beeston, who was the Management Information Development Team lead at TUI, said that Agile adoption at TUI was still not complete and he hoped that as it matures developers will become more used to receiving and incorporating more feedback more often. Agile has been pushed up from the bottom by teams like Beeston’s that have been willing to experiment and try to make things better. “We’ve still got a ways to go in terms of rapid delivery to get where I want to be,” he said, “but we are working more collaboratively and with better communication.”
Tracking and defining requirements has been another big win for the Agile movement at TUI. Beeston said the main internal customer produced requirements and user stories, but wasn’t directly involved with IT. Basically, the product owner would throw requirements over the wall and then find out what the development team did with them. “Agile helped us highlight and track our user requirements. Agile methods helped get people disciplined about the definition of ‘ready to start’.” That discipline, in turn, started improving relationships and communication between groups.
“Our next project will tell whether this approach is working,” Beeston said. So far, according to Beeston, their Agile processes have been “fly by the seat of the pants” and it needs to be more structured and repeatable. “I think the myth around Agile is that people think it can be chaotic and still successful, but to be sustainable, Agile really needs to be very structured.”
Beeston advised other fledgling Agile team leaders to focus heavily on communication and remember to write down what’s said so you can remember it later. “If you’re only doing one or the other, you’re going to have problems,” he said. Beeston noticed people talking and not writing anything down. That means they can change their minds later and they don’t have anything to look back at if they forget what was said. Beeston argued that will lead to the same problems as miscommunication or lack of communication. Writing things down is the only way to keep the team on the same page.
Beeston also recommended using solid collaboration tools. His team used Rally as a central point of communication. Rally acts as a hub where each team lets everyone else know what they’re up to. In theory, this should mean that developers can react to changes from the analysts before there’s a last-minute panic, and vice versa. In practice, “There still are last-minute panics because not everyone is trained up to the point where there are no human errors,” Beeston said.
Beeston said it was important for all members to use the collaboration tools properly and to participate in all the ceremonies appropriately. He stressed the importance of defining things like the definition of done and sticking with that definition. “Don’t say one thing and do another,” he warned.