The Scrum Guide 2011... snap!

During a 30 minute spike today on UI blocks, the discussion wound around to...

Couldn't the "developers" implement some of the BDD steps?

Well the "testers" do that.

Oh... Well we're accruing quite a bit of debt from the rough UI we have at the moment. Couldn't the "developers" work on the UI/UX?

Well the "business analysts" and "UI experts" do that. 

It seems very, very odd when you think about it. It also seems to run counter to some pretty basic scrum principals. I was going to let it slide, but then I saw there's been an update to The Scrum Guide (2011).There have been a few refinements made to the document, they are listed in the summary page. Have a read, it's very easy to follow. There's a few gem's on page 6 (some paragraphs removed)...

The Development Team
Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness. Development Teams have the following characteristics:

• They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality; 
• Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment; 
• Scrum recognizes no titles for Development Team members other than Developer. Regardless of the work being performed by the person, there are no exceptions to this rule;
• Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole; and,
• Development Teams do not contain sub-teams dedicated to particular domains like testing or business analysis.

At the risk of getting all high and mighty, shouting "you're doing it all wrong!" or "the book says you're not allowed to do that!"; which obviously achieves nothing, and irritates a lot. I've been trying the gentler "as part of improvements for next sprint, what could we do to become a more cross functional team?" approach in our sprint retro.

We shall see...

He said: "What do you think of my manifesto?"

Agile Manifesto

I said:

"I like your manifesto, I'll put it to the testo"

Alas, the room fell silent when I said that. There might have also been a tumble weed, I'm not sure.

Apparently agile project management frameworks are a little more popular than old Irish punk bands. Oh well...

Sultans of Ping FC

Samba server is easy... Samba domain login is, err, tedious...

Server = easy
To get a samba server up and running (as a PDC or just a file share), is easy peasy...

• https://help.ubuntu.com/10.04/serverguide/C/samba-fileserver.html

Four steps - two really, since you are really just:

• editing /etc/smb.conf
• restarting the daemons

Client = hard

Ahh, but getting another Ubuntu desktop to authenticate to the Samba PDC like a regular dumb Windows box -- now that's a pain in the ass. If you are using Active Directory, you can cheat and use Likewise Open. But I'm not, so I have to wade through http://www.clearfoundation.com/docs/howtos/add_linux_workstation_to_the_samba_domain

I mean it works and all, and I'm grateful for the help -- but really:

• editing /etc/smb.conf
• manually creating /home folders
• editing /etc/nsswitch.conf
• blowing away (yikes!) /etc/pam.d/common-account
• blowing away /etc/pam.d/common-auth
• editing /etc/pam.d/common-password
• editing /etc/pam.d/common-session
• reboots
• editing /etc/sudoers

Come on, really, couldn't that be a little easier?

Even the pretty "Ubuntu Software Center" was less than helpful...

Which to the novice end users pretty much means:

Well we installed it like you asked -- but you're on your own from here. Go wade through man pages why don't you...

Oh well, on the plus side -- the (lengthy) steps outlined above do result in domain+single-sign-on goodness for my Ubuntu desktops. So I'll probably forget the installation experience sucked.