Long after DARPA's research, commercial entities such as AOL, Prodigy, and CompuServe had their own ideas about how computer networks should function. If a commercial entity had invented the Internet it would have functioned like the AOL of 1993 where all content has to be approved by a single corporation. That corporation would collect a tax on all transactions. It would kick out anyone it did not agree with. It would be far, far different than the Internet we have today and it would have undoubtedly happened much later.
Slashdot videos: Now with more Slashdot!
We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
Use a square bull pen arrangement with work surfaces around the inside of the square. Put a single round table in the middle for collaborative meeting/discussions.
If programmers have to share an office, this would be the ideal arrangement. Its very space efficient (more so than sitting opposite each other), and its easy to collaborate by simply turning around and talking to your teammates. Furthermore, theres plenty of space behind each team members computer for everybody to stand or sit around and work on something together. It must be said that distractions are hell though. Sartre said, "Lenfer, cest lest autres." Damn right he was.
1. Be able to keep some distance, what we call a "helicopter view". (Note how being entrenched in technical details doesn't fit well here?)
2. Consider the progress of items and tell people when they have unrealistic estimates of whether their items are likely to be "done" at the end of the Sprint, according to the Definition of Done that was agreed on with the Product Owner. (Again, something that requires not being entrenched in the details of technical stuff.)
3. Be able to talk to management about items on a functional level, and be able to think along with them about prioritization. (This is again something that requires more of a functional view on things.)
4. Understand enough about the technical parts to be part of the team -- the scrum master should only need half a word from his team members to understand why something is a problem. You don't want a scrum master who is to be "massaged" by team members in order to get something done, like you would have to do with a PHB.
Point 1-3 disqualifies techies, point 4 disqualifies professional project manages. Ideally, you would find somebody on the team who is not a tech guru, but also not a tech dummy; and you would find somebody who takes an interest in procedural and functional issues.
Just to state the obvious: the most important thing about Agile is that you do retrospectives: you have to think about what works and what doesn't, and fix up your process. We've been continually fixing up our process over the past couple of years, and there's *always* things that still need improvement. If the poster has to go here in order to discuss this, his team doesn't have this very basic and Ã¼ber important part of Agile down.