Agile Otter Blog

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...

There are many kinds of good, and how we approach them tells a lot about us as people. Take 'Agile' for software developers.  There are (at least) three different ways to approach this particular kind of good: One way is to try to adopt the appearance of Agile because "it looks good" or perhaps it would be embarrassing to admit we are not. If we are avoiding the appearance of being non-Agile, then our efforts are likely to fail. Agile development is about engagement, yet maintaining appearance is mostly about compliance (or obligation). "Seeming" without first "becoming" is a kind of misrepresentation, and can strain relationships that would work more smoothly on a basis of trust. One may want to be recognized as already having the kind of good that Agile represents. This is more legitimate, because most developers have teamed up on tough problems, written unit tests, collaborated with teammates, or worked in short time boxes of a ...

Famously, scrum has used an old joke to explain two kinds of participants in development work. Pigs and chickens is a reference to having bacon and eggs for breakfast; the chicken is involved (donates an egg), but the pig is committed (gives his all).  In scrum, this translates to stakeholders (chickens) and material participants (pigs). It always seemed funny that people who are on the hook to pay for the work are chickens and those who are paid whether or not the product succeeds are pigs. Still, I appreciate calling out the idea of advisors and stakeholders v. material participants. I wonder sometimes about those roles for people who are not primary stakeholders, yet are somewhat involved in the development, but primarily act to give permission or to grant or withhold resources. Are those chickens with a pig complex? Pigs with chicken complex? Porklucken? Non-coding architects who must approve designs Sysadmin/IT who controls the team's computing resources Externa...

This just in from the put-your-money-where-your-mouth-is department: Bob M. hung out a blog post describing the evil that is agile coaching . I didn't recognize myself in the mirror he proffered, but because I'm an agilist I value feedback as the first necessary step in the whole problem solving system. Without a closed feeback loop, how can we reach clarity and improvement/acceleration? So, this is for all the people I've coached, whether as a paid agile coach, coworker, manager, or neighbor.  Take a look at Bob's post for inspiration and pop back here to do me a favor by answering questions: Am I evil? In what ways am I evil? In what ways have I served you, or done you disservice. I await your feedback.

A few ideas rattling around my head need a place to live while I think them through, so I am shoveling them into the ole blog so I can think about prepping materials and exercises for a class I am teaching soon. I was considering an archetype developer that we've all seen (heck, half of us have been ) and how hard it is to reach this particular type when doing any kind of a technology or methodology change.  Here's the stream: There is this guy who believes he's an exceptional programmer, but underrated and under-respected by his peers. Why does he think he's good? Maybe he doesn't really believe it. maybe he's afraid. (@RonJeffries) A guy who never thinks or reads about programming off-hours, never goes to talks, hates pairing, skips reviews. Thinks himself an expert? b/c folks like that have a Darwinistic career advantage over peers who /are/ good but think they're mediocre/overpaid/overrated (@LancePurple). I suspect Dunning-Kruger Effect . Not go...