Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Comment Re:Obscene (Score 1) 760

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.

It has.

Comment Re:Use a square and face outward (Score 1) 520

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.

Comment Tech Gurus are bad at Scrum Mastering (Score 1) 434

We've been doing Scrum for a while now at my company, and one of the conclusions we've reached is that you should never make the tech gurus the scrum masters. And that conclusion is totally independent from who you *do* want to make scrum masters, just don't pick the technical guru. The reason? Tech gurus tend to be the technical core of the team, everbody asks them deep technical questions all day long, they also have the responsibility of building the most complex technical features that nobody else can really do, which means that they spend their days entrenched in the core technical stuff of the project *which is exactly the opposite of where the scrum master should be*. The scrum master should, ideally:

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.

Slashdot Top Deals

Money can't buy love, but it improves your bargaining position. -- Christopher Marlowe