Agile Otter Blog

I was surprised to find that Jeff and I have been talking so much about testing over at Agile In A Flash . Jeff and I are quite emphatic about the importance of TDD and automated testing in general. Some of our most popular cards are about testing.  It shows our bias that a lot of the value of Agile methods are lived out in the elevation of testing to a first-class concern. We always want to know that our code works. We never want to be in the dark about it. Quality should be a given in an agile project. Heck, quality should be king in any project. High-quality, low-functionality enables iterative and incremental development whether the team is agile or not. We always want tests to set the goal for us. While the blog (and deck) are not just about testing, testing holds a special place in our minds and hearts. I guess it should not have been surprised at all.

I know it's going to sound like I'm trying to talk my boss and yours out of giving us both raises, and of course I'm not, but I keep hearing people tell me they're worried that they can't work in teams because their system pits them against one another. Usually it's an excuse or reason for not pairing. "If I improve my colleague, he will beat me to the incentives" or "if we do his work first, then there's a chance I'll fall behind."  I'm not a fan of individual work assignments , and I'm not a fan of competitive incentives . Rather than rant about it, I'd like to point you to some other authors and how they feel about the topic: Daniel Pink suggests killing your performance ratings . InfoQ balanced comments pro and con individual rewards. Peter Scholtes says reviews are  ineffective, even harmful  and performance appraisal are incompatible . Esther Derby suggests ways to support team-based work  and  performance ...

Did you watch Monty Python's The Meaning Of Life ?  There is a great scene that takes place in the Very Big Corporation of America, excerpted here: CHAIRMAN: ...Item six on the agenda: the meaning of life. Now, uh, Harry, you've had some thoughts on this. HARRY:  That's right. Yeah, I've had a team working on this over the past few weeks, and, uh, what we've come up with can be reduced to two fundamental concepts. One:  people are not wearing enough hats.  Two: matter is energy. In the universe, there are many energy fields which we cannot normally perceive. Some energies have a spiritual source which act upon a person's soul. However, this soul does not exist ab initio, as orthodox Christianity teaches. It has to be brought into existence by a process of guided self-observation. However, this is rarely achieved, owing to man's unique ability to be distracted from spiritual matters by everyday trivia. [pause] BERT: What was that about hats, again? T...

One day, a fish came to visit some kangaroos. He saw right away that the kangaroos spent all their time hopping on the dusty ground and browsing among the shrubs. Their habits would never work, and surely lead to their deaths, if they were to come to the ocean reefs even for a single month! "Foolish kangaroos," he called to them, "heed my words and live! This hopping and browsing is pointless madness! You must learn to paddle and snatch live prey from among the rocks! The ocean is no place for hopping air-breathing creatures, so come follow me and learn the better way!" The kangaroos, amazingly well-adapted to their un-ocean-ly environment, dutifully ignored the fish. They looked for common ground for conversation, but somehow the topic always turned to the futility of hopping and the unpleasantness of a dry environment. Sometimes they asked polite questions, and the patient among them tried to explain that their way of life was forever on solid ground whe...

TDD is a pretty simple system, as popularly described.  For an individual doing a kata or playing with some example code it is really just three steps. On card #44 of AgileInAFlash it looks like this: It's the right way to think about TDD, and the right way to get started. When you get to a real project in a team environment you have many other issues to consider.  In a modern team environment, with a DVCS, it looks more like this: Get the current code ( git pull , get clone , hg pull -u , whatever) Run all the tests and be sure they're all really green, to avoid blaming yourself for unrelated breakages. If there are no tests, write a trivial failing test (" assertTrue(false) ") to prove your testing setup (ide, scripts, makefiles) really work. Then delete the trivial test. Write one "real" red test. INSIST ON RED. Write code to turn it green. Local commit "save your game" Refactor (or intentionally choose not to). Check to...

Linda takes us from a negative to a positive affective style, from a posture of seeming or being to one of becoming.  There is just so much to know and understand here. If you don't already love Linda Rising, you surely will after this. Notice the tie-in to Seeming v. Being v. Becoming . Mine is derivative, of course.

You use an experienced coach instead of the nearest guy with a scrum master certificate because you better chance of success when you're guided by someone who cares, connects, knows the work system, and has been through a few transitions before. Empathy and experience are the stuff that good coaches are made of, yet either of them can become a trap. Empathy is crucial, but can pickle a coach. When he identifies too strongly with the team and product he'll soon find himself taking on coding assignments and coping with (or adopting) the local pre-agile culture instead of pushing for transformation.  Once the coach's role has been relegated to staff augmentation, the freshness and clarity of his vision is greatly diminished. Likewise, a consultant can succumb to prior experience and waste his engagements trying to recreate a past glory. A good coach needs to respect the context and personalities and experience base of each team and help them to do their best; doing othe...