This post originated from an RSS feed registered with Agile Buzz
by Keith Ray.
Original Post: Consequences of Decision-Makers
Feed Title: MemoRanda
Feed URL: http://homepage.mac.com/1/homepage404ErrorPage.html
Feed Description: Keith Ray's notes to be remembered on agile software development, project management, oo programming, and other topics.
I was thinking "how do Gore & Associates do projects?" Since there are no managers, but only "sponsors", I imagine that new product development is organized by (and around) product champions, like 3M and Toyota. Quoting the Poppendieks: "Every new product program has a strong leader, at 3M it is the ‘champion’ and at Toyota it is the shusa or chief engineer. In both cases, these people ‘own’ the product – their name is associated with it. We have Art Fry’s Post-it notes and Kosaku Yamada’s Lexus. These leaders are the ‘voice of the customer’ to the team and they assure the proper amount of design goes into it before detailed development proceeds. [...] The concept of a project manager is foreign to both companies, as is the idea of monitoring tasks" [instead, they monitor results].
Do these companies start selling a new product before they create it? That's a sure way to put make time-pressure the priority over everything else, including quality. I've heard that the Post-it note project was "cancelled" three times before it was completed, so I'm guessing that 3M doesn't sell products before they're "hatched". However, many software projects are are sold (with scope and time-frame fixed) before they're planned -- sometimes before they have any estimates. And they are not re-planned when detailed estimates (or reality) show that the scope and time-frame are unrealistic.
In a problem-solving workshop that I participated in, 30 people in one room simulated a company, and the 'salesmen' were selling something we didn't know how to make. And I was part of that. I was also one of the designers for a product we didn't yet know how to make. It was hilarious. Everyone was in one room, and yet we did not communicate, estimate, and make plans based on the reality of the product development process -- a process that we hadn't yet learned how to do. This happens even more so in companies where the salesmen and the developers never meet; where the consequences are not aligned with the promises.
A typical rant about the way most software projects are done says"Late, over budget, buggy systems is the norm." and blames managers for not understanding the difficulties of software development: "So when I now go to a manager and attempt to explain that the coupling in the system is going to crush us in a year or so unless we take steps to address it now, their world view doesn't include a perspective that let's them say 'Oh right. I remember making this mistake.' [...] They can see the value of features and functions, but decoupling the system is not something you really value until you've felt the pain of not actively doing it."
The manager described above doesn't feel the pain from the consequences of his decisions (So why is he in the position to make those decisions?). Jared Diamond says this is one of the root causes for societies to collapse: "A theme that emerges from Norse Greenland as well as from other places, is insulation of the decision making elite from the consequences of their actions. That is to say, in societies where the elites do not suffer from the consequences of their decisions, but can insulate themselves, the elite are more likely to pursue their short-term interests, even though that may be bad for the long-term interests of the society, including the children of the elite themselves."
Extreme Programming and other agile methods try to get the domain expert / product champion / "Customer" closely involved in the project, but at the same time doesn't permit the Customer to make the technical decisions that developers should be making. The Customer isn't allowed to prevent the programmers from writing unit tests and keeping the code clean. However, the programmer's aren't allowed to implement features that the Customer doesn't need or want. The Customer controls scope, but does make up the estimates. If the scope doesn't fit the time-frame, XP makes that obvious pretty early in the project, and it becomes the Customer's responsibility to change either the scope or the time-frame. The Customer isn't a member of an elite, insulated from the developers and the consequences of his decisions.
Previous Topic
