How do you say pensées in Danish?

In order truly to help someone else, I must understand more than he - but certainly first and foremost understand what he understands.

All true helping starts with a humbling.
Chapter 1 A : SS2

Compel a person to an opinion ... that I cannot do. But one thing I can do: I can compel him to become aware.
Chapter 1 A : SS4

I am regarded as a kind of Englishman, a half-mad eccentric, with whom we jolly well all, society people and street urchins, think to have their fun.
Pap IX A 288

The Point of View for my Work as an Author 1851
Søren Kierkegaard
(Volume XXII of Kierkegaard's Writings)
Translated by Howard V. Hong and Edna H. Hong
Princeton 1998

How To Fail With Agile

Here are the twenty guidelines from How To Fail With Agile: Twenty Tips to Help You Avoid Success, an article by Clinton Keith and Mike Cohn in Better Software Magazine, August 2009. I copied the text from an HTML Version.

I like to use these in the retrospective of a successful project. If it all went well, how did we avoid doing these things?

1-5 are Management Issues, 6-8 are Team Issues, 10-13 are Product Owner Issues, and 14-20 are Process Issues.

1. Don’t trust the team or agile. Micromanage both your team members and the process.


2. If agile isn’t a silver bullet,blame agile.


3. Equate self-managing with self-leading and provide no direction to the team whatsoever.


4. Ignore the agile practices. They don’t apply to management.


5. Undermine the team’s belief in agile.


6. Continually fail to deliver what you committed to deliver during iteration planning.


7. Cavalierly move work forward from one iteration to the next. It’s good to keep the product owner guessing about what will be delivered.


8. Do not create cross-functional teams. Put all the testers on one team, all the programmers on another, and so on.


9. Large projects need large teams. Ignore studies that show productivity decreases with large teams due to increased communication overhead. Since everyone needs to know everything, invite all fifty people to the daily standup.


10. Don’t communicate a vision for the product to the team or to the other stakeholders.


11. Don’t pay attention to the progress of each iteration and objectively evaluate the value of that progress.


12. Replace a plan document with a plan "in your head" that only you know.


13. Have one person share the roles of ScrumMaster (agile coach) and product owner. In fact, have this person also be an individual contributor on the team.


14. Start customizing an agile process before you’ve done it by the book.


15. Drop and customize important agile practices before fully understanding them.


16. Slavishly follow agile practices without understanding their underlying principles.


17. Don’t continually improve.


18. Don’t change the technical practices.


19. Rather than align pay, incentives, job titles, promotions, and recognition with agile, create incentives for individuals to undermine teamwork and shared responsibility.


20. Convince yourself that you’ll be able to do all requested work, so the order of your work doesn’t matter.

Pairing as the Junior Partner

Agile 2009 Conference in Chicago. The Live Aid effort developed an iPhone application to let donors give to the Mano A Mano effort supporting communities in Bolivia. I spent a couple of afternoons helping out.

I knew nothing of the domain, infrastructure or programming languages. It was all being done on Mac Book Pro laptops, so I couldn’t even get a scroll bar to work in Firefox. That’s how useless I was.

Except that no pairing partner is useless. Here’s what I contributed:

• Syntax and spell checking as my colleague typed


• Fluency in HTML when we were modifying web pages


• Discussing the value to be gained from making the pages fully XHTML compliant


• Guessing how to enter a bank account number into Pay Pal when it refused my pair’s efforts


• Helping a new colleague get starting by just knowing a little of the directory structure


• Reminding my pair that the first step was a failing test, not a pretty, well-written or comprehensive test


• Congratulating my pair when he got that test to go from red to green


• Noticing a precedent in a Cucumber test for how to echo the HTML to the console


• Writing down the test cases so my pair could start working through them


• Seeking targeted guidance from the Ruby and Rails experts on the team


• Speaking up at the stand-ups

I think I did enough. I’m certainly grateful to a partner who fills in those gaps when it’s me who’s meant to know what to do.

Please visit (by iPhone or browser) www.manoamano.org to see what we did, with your credit card at the ready. And a big thanks to all of the team for letting me help out, with a particular mention to Dwight Illk.