D.S

langrsoft.com

Langr Software Solutions » Scrum

Langr Software Solutions » Scrum — Main Menu — Home Consulting / Coaching Training - Information About Training - Student Quotes - Technical Training - Process Training Resources - Agile in a Flash blog - Articles - Jeff’s Wiselike Page (Q&A!) - Books Jeff’s Blog About Home Consulting / Coaching Training Information About Training Student Quotes Technical Training Process Training Resources Agile in a Flash blog Articles Jeff’s Wiselike Page (Q&A!) Books Jeff’s Blog About ScrumAlliance ™ April 30, 2009 by jlangr 0 Comment On the scrumdevelopment Yahoo! group, a discussion revolves around user group concerns over the trademarking of the phrase “Sc*um User Group.” (Note that I’ve starred the name in order to avoid trademark violations.) A few inquiries resulted in an official response from a Sc*umAlliance representative. I find it odd that (a) no one belonging to the “Sc*umAlliance” (whoever they really are–I’m suspecting maybe Mars, but given their legal nature, maybe Uranus) frequents the scrumdevelopment group, (b) none of them chose to respond directly on the group once apprised of the concerns, and (c) Ken Schwaber didn’t have an immediate answer (regardless of his affiliation with the Sc*umAlliance). I suppose there must be people (lawyers, no doubt) who don’t have to be at all interested in the product they support, but it just seems wrong somehow. Agile requires lots of communication and continual negotiation. Bits of command and control have their value at times, but in most cases C&C begins to eat away at the trust relationship required for continual negotiation. I suggest people considering or doing Sc*um dispense with the trappings of a trademarked process and look instead to understanding what agile is really about. The progenitors of agile–i.e. the agile manifesto signatories–rightly eschewed “heavyweight” processes–processes centered around lots of documentation and meetings. I think there’s a new category of “heavy” that should be spurned, and that includes processes controlled by people so heavily wrapped up in legal and licensing protections that they can’t bother discussing changes with the community who would be affected. On Email Lists and Advocacy March 30, 2009 by jlangr 1 Comment I try to keep up with all of the various agile “Yahoo! Group” lists: extremeprogramming, scrumdevelopment, refactoring, testdrivendevelopment, agile-testing, and so on. I post once in a while when I see a topic I feel qualified to respond to or that I’m passionate about. Lately I’ve been getting a lot less value out of these lists, some of which I’ve been following for ten years. Many of the lists degrade into passionate statements of position, i.e. advocacy. Inevitably, people get burnt. Tempers flare, people get upset, some stomp their feet, some simply withdraw . I myself have gotten burnt on this same list, feeling that someone (probably not coincidentally, the same person who is withdrawing now) was looking to simply piece apart every single word written to find as much fault as possible with it. I withdrew completely from that discussion. I’ve also withdrawn from perhaps a couple other difficult discussions (out of the hundreds I’ve engaged in over the years). Sometimes it’s because I felt the environment was too hostile, and I justified it to myself by thinking that the individuals involved were being immature or offensive or whatever. But that’s not courage speaking. I looked back at my most recent example and regretted how I handled it. Withdrawing didn’t solve anything. Sometimes a simple statement, meant to be innocuous by who wrote it, is taken as a stab and affront. We can pout and take our toys and go home, but that’s not at all useful or commendable. Courage can help us find a way to face the challenge and learn how to get past the issue. We don’t have to agree with everyone or get along with them, but sometimes a sour incident can lead to a valuable relationship. So how is this at all relevant to anything? Well, if we are to succeed, agile software development requires that we face challenges and not bury them in isolated cubes. Similar clashes occur not only on email lists, but in real life, and we’re particularly going to see such clashes more frequently in highly collaborative teams. Conflicts that are not handled properly will detract from a team’s ability to deliver. The XP value of courage is still essential to learning how to regularly deliver quality software. Pigs, Chickens, and Asses September 15, 2008 by Jeff Langr 0 Comment In Scrum, those “not accountable for deliverables” (emphasis added; see Jeff Sutherland’s article ) do not get to talk during certain meetings. Pigs (product owners, ScrumMasters, and “the team”) are accountable for the success of the project. Everyone else is a chicken, because they’re not accountable for the project. Their opinions are distracting and thus damaging to the project. Thus customers–people who ask for and pay for the product–are not part of the tea