Michael Feathers presented yesterday at the Norwegian Developer Conference on “The Mistake at the Heart of Agile.” “We got some things wrong early on,” suggested Feathers.
A core XP concept was a strong separation of responsibility between business and technology. “XP customer was a gate keeper,” said Feathers, adding that it was a very stressful role that was later adjusted by adding the Whole Team practice. Both scrum and XP had the same organisation context - protecting the development organisation from the rest of the business. Scrum has the concepts of chickens and pigs, with the goal of protecting the team. Product owner is an interface to developers, preventing others from directly contacting the team. “But intermingling roles makes teams more effective,” said Feathers.
Agile processes are an abstraction of software development, and like any other abstraction they focus on certain elements and abstract away others. Feathers pointed out that the process abstraction in agile methods doesn’t deal with architecture concerns. As any other abstraction, it leaks. “Software development cannot be hidden behind a story level interface,” said Feathers, adding that “overly focusing on stories produces legacy code.” He explained that by saying that one way communication from business users to development teams doesn’t give a chance for technical people to provide technical insight, leading to missed opportunities. I wrote about this in Specification by Example under Deriving scope from goals.
Many teams adopt agile processes by just renaming project managers to scrum masters and business analysts to product owners. Conway’s law says that software design will reflect organisation structures, which means that nothing really changes. “Many people see Conway’s law as pessimistic. But Conway’s law is optimistic,” said Feathers, adding that it provides a guideline for organisations to change the way they work to influence software.
Feathers suggested that organisations should forget the dichotomy between business people and development and work on removing communication barriers. He said that the organisations who can find people that understand both technology and business can have a great advantage in the market. He mentioned Google and Amazon as two good examples.
Keith Braithwaite said these ideas were implemented to give developers “a safe place to work” in the face of chaos on the other end and that such structures should be considered a temporary barrier. This barrier is important while people find ways to work together and define collaboration. Braithwaite pointed out that there are teams following highly structured Scrum processes that are perceived as unresponsive by their business users because they kept the barrier for too long.
