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.
|
|
Interesting… I’ve always viewed the product owner (or [product] growth facilitator in OpenAgile speak) as someone who coordinates getting the answers from the business, not the filter by which they come through. They do have the single responsibility of prioritization. It just decreases the confusion of too many hitting the developers without coordination. A project manager can’t do that as they usually do not know the business goals well enough.
I think this is the type of tailoring required to be Agile as opposed to just doing Agile. So I think Michael is rightly pointing out that if the product owner is becoming a barrier or filter, then he or she is not helping the team really.
On the architecture side, I do think some things can become part of a story (example expected response time), it should probably be added though when it becomes a problem (hopefully with some proactive exploratory testing) or if you know it will be an issue, by adding it after you have the basic functionality working. Get it working and then address it.
As far as abstracting pieces into separate architectural components; I like to use the idea of 3rd strike, pull it out. In other words, if you start building a 3rd application that has a similar set of functionality in one area as 2 others you previously built, look at abstracting those 3 into one component and refactor your code in all 3 apps then to use the separate component. It keeps you from over engineering for a problem that you may not encounter but once or twice.
Nice recap! I appreciate you getting the information distilled and put out there!
Paul
Great post…
I think we saw the team as the people needed to produce the software not the people required to solve the business problem. If we see business value (not working software) as the desired output we will learn that we all are part of “the business” and that the distinction between IT and the Businesses is as destructive as the distinction between testers and developers on an Agile team,
The old joke says, “Why do software developers like to hang out with actuaries?” and the answer “It makes it seem like they have a life.”
There are often good reasons to isolate business folks and developers. The personalities are often very different. In the best of all worlds, everyone would work well with everyone else. We live in the real world and a socially inept person that actually likes to sit at a keyboard all day often doesnt communicate well with a business person whose life would be sad without constant human contact.
The speaker’s suggestion to open up the lines of communication is well taken but caution might well be advised. And some personal growth might be needed or even promoted within the team.
Lee,
Your caution is well noted, and over practiced. It sounds much like separate but equal, which doesn’t work. I work with many software developers who are exceptional in their craft. I have worked with the hermit type software developer as well. In my experience the folks I work with now are far more productive and effective than any who would require the company of an actuary to experience human interaction. We don’t need gatekeepers, we need people and their connections. We need clarity not mysticism around business or technology. We need collaboration, not silos. The reason we see the divide is because we perpetuate it with the notion that a technical person can’t understand business and a business person can’t understand technology. Well here’s a bridge we can use, we don’t solve technical issues, we solve business problems.
Honestly it sounds like Micheal has encountered some teams that need some support and coaching. The Product Owner/Growth Facilitator should increase the interaction between the team and the business not act as a barrier/filter.
Perhaps Micheal would like to forward me the contact details for the clients in question so I can offer my services
Cheers
Mark Levison
Any Agile team where developers mutely and slavishly follow orders from a product owner is unhealthy and destined for disaster. I’ve never been on such a team, but I’ve been on enough others that I can see the disaster that impends with a totalitarian product owner.
I’ve worked with some product owners who would have _liked_ to be totalitarian, at least at the beginning, and seemed to be offended that it didn’t work out that way (all women, interestingly), but a product owner who isn’t interested in listening to technical input is throwing away a lot of value.
In fact, the two most successful product owners I’ve had both operated chiefly by explaining their problem to the devs, letting the devs come up with solutions, then pruning off solutions that were inappropriate in some way, fine-tuning the rest, and letting the pair who got the card make the final call.
I like to say, “We can give you this if you really want it, but I’d like the chance to try to talk you out of it by explaining how I can save you money without costing you value.”