Abby over at Haxr Chick cites Ken (Schwaber, co-inventor of Scrum) as comparing Scrum to a live-in mother-in-law who is constantly pointing out how you can improve. Great post, and I like it.
But the discussion in the comments is just one variant of the many similar conversations I’ve heard about Scrum. It goes something like this:
Neo: “Scrum is great, but we have to adapt it to fit our organization.”
Morpheus: “You must not adapt the Scrum framework.”
Neo: “Whoa. Now you’re getting all religious on me.”
The whole point of “getting religious” about the Scrum framework is to detect when you are, ah, let me find the right extension to the metaphor here, drugging the mother-in-law rather than dealing with what she exposes.
If we can prematurely adapt Scrum to our situation, we have the freedom to adapt it such that we are comfortable within our dysfunction, rather than improving our dysfunction.*
Ken harps on 2 things to keep us from this pitfall:
keep Scrum simple - 3 roles, 3 artifacts, 3 meetings, associated rules for each; and
don’t adapt the Scrum framework (although adapting the process which you evolve around the framework is not only allowed, it is a must!)
By keeping Scrum simple, we reduce the temptation to tinker with it, and we reduce the amount we have to “interpret” it. By keeping the framework constant, it gives us the same benefit as keeping rulers constant: we get to adapt our behavior to improve rather than adapting the thing which exposes our behavior. It would be some odd clothing made by a tailor who adjusted his measuring tape just to make me feel better about my 44″ waist.
Automattic’s Prologue looks to be a nice solution to a team “war room” for distributed teams.
A frequently-underestimated benefit of the team “war room” is how it enables emergent knowledge. If I mumble to myself (as I frequently do) “now why is Apache redirecting us there…?” someone is likely to mumble back “checked the root htaccess lately?” and perhaps my problem is solved. Great fun. Great help. But hard to achieve on a distributed/virtual team.
I’ve enabled this sort of behavior in virtual teams via wiki, and also via Twitter (thanks to Chris Spagnuolo for the idea). But Twitter doesn’t have the concept of a “room,” so setting one up for everyone on your team — and keeping it private — is a bit of a pain. And Twitter’s one-username-per-email means some annoying collisions.
Campfire and IRC also have their uses, but cost and security respectively might be a blocker for you. Skype’s “conference” is nice, with the added benefit that you can start a voice call/conference whenever you want. But everyone’s updates live in the Skype app, not on a web page. So if someone new joins the team, they don’t get benefit of reading the team’s history.
I think Prologue is just what I’ve been looking for:
installable on your own server
your updates to your team are saved on a web page (you could even incorporate the RSS into your team wiki somewhere)
Very much enjoying Pandora Radio while working. Good example of using stochastic input against a known attribute database to yield surprisingly useful results. Their library of my styles of music is a bit small for my tastes, but it’s a nice compliment to DI.fm
Over the past few weeks, I’ve been digging into links, blogs, forums using this term (Post-Agile)… Have you seen this term? Followed it’s discussions? Any comments?
…Pliant Software is another term that seems to be associating itself with Post-Agile…
I think the software world is sort of like a customer who has an idea of what they want or need, but can’t put it into words. But, and after several iterations of “Requirements Gathering”, has come out of the room with more terms and an RD that is better than it was at the start — but not perfect, yet!
(italics mine)
Yes, I have comments!
I agree that the newness of agile has worn off, and the immediate benefits from it have been tapped dry by many.
I’m annoyed at the PliantAlliance site’s claim for “a new way of thinking about developing software” — pliant sounds like adaptive to me, and Scrum has been saying this for a while.
While the immediate benefits of agile have been tapped, the deeper benefits that can be realized by changing the way we collaboratively build product — not just the way developers write code — have a long way to go. Before we decide that “agile didn’t work,” I’d like to see more organizations actually practicing basic agile behaviour, and I’d like to see actual practices in use catch up to the huge body of literature describing deeper agile practices.
Good Software is a craft, like smithing or theatre. There was never a school that turned out expert blacksmiths; novices had to progress from apprentice to journeyman to master. The “Fame” school doesn’t promise its graduates fame, they have to go out and earn it through experience.
Good Software is the result of human thought — not just human labor — and is highly resistant to being made into a detailed process/algorithm, or body of knowledge.
Good Software is the result of collaboration. Social Science and more enlightened ways of interacting can help, but trying to describe them is missing the point.
I understand that post-Agilists see themselves as giving a name to an existing movement, rather than trying to create a new movement. But it smacks of picking a new name for your club because one member of your club is acting silly, and people are now making fun of you: you fragment the group, you tacitly approve of the bad behavior by distancing yourself from it rather than correcting it, and you spend too much time and energy on labels rather than action.
My friend’s point is right on: the SD world is like a user with a poor Requirements Doc, who “knows what they want, they just can’t describe it yet.” Trying to describe it, trying to codify it, is ulitimately a losing game and a waste of time — just like writing big RDs is a waste of time.
Build successful, adaptive teams who can make good, useful software, point to them and say “THAT is what Agile is.”
This year is proving to have perhaps more than its share of challenges. After spending 26 days with my father in the hospital, I was with him when he died last Wednesday.
I’ve been writing quite a lot already, what with obituaries and funeral programs, so for now I’ll let the feature article in our local paper do the talking for me:
After a 2-month bout with feline lymphoma, today we said goodbye to our beloved pal Kokoro. At long last the dread, the fear, the intensive care, the rollercoaster of good days and bad days is over. Now we can but remember all the joy and depth he brought to our lives, and be glad that we could be the people with whom he spent his golden years.
~ Kokoro, Koko, Biscuit ~
born 1993?
arrived in our lives December 28, 2002
moved on June 23, 2006
You have a nice four-hour block for your working requirements / product planning / process re-engineering / whatever meeting. You allot a “generous” 30-minute chunk near the beginning for the definition of terms. You put a few domain-specific words up on a flipchart to get ideas flowing, point to the first term, and prompt the team:
“So, everybody, what is the definition of _______ ?”
(Two hours later…)
One phrase is detailed to a precision that would satisfy most German engineers, the total number of terms to define has tripled — but none of them have been defined — and you have had to break up three near fist-fights.
A common vocabulary is important, but does it have to be this hard? I recently had a delightful experience which suggests that it does not. Read the rest of this entry »
One phrase is detailed to a precision that would satisfy most German engineers, the total number of terms to define has tripled — but none of them have been defined — and you have had to break up three near fist-fights.
