Agile Otter Blog

I did not manage to use my Christmas break to get a lot of work done on the book . I tried, but there was much going on in our world (almost all good stuff) and I was unable to get the focused time I was hoping for. You might be able to access a sample of the draft as of today. It is only a small bit of the book, but maybe enough to whet your appetite. I hope to decide on the "early adopters" price soon, and finish up the initial set of illustrations (thereby getting rid of the ugly ascii art that appears in some places, and breaking up the expanse of text that appears in others). If you want, use the public page to suggest a price. Thanks for waiting. I hope you'll find the result thought-provoking and useful.

Messages from the past have a way of reaching into the future and getting your attention. This week everyone is talking "apocalypse." This is because of an ancient mayan calendar which quits tracking time on Dec 21st. The joke (I hope we all know it's a joke) is that it stops because that's when time ends. Of course, my calendars used to run out every year (before Google Calendar). The word "apocalypse," according to my sources, was a theatrical term. It referred to the moment when the curtain was pulled back and all was revealed. When I learned that, the title of the biblical book "Revelations" finally made sense, as did more of the text within. Today I'm facing my own apocalypse. An ancient message (from two years ago) has come back and presented itself to me. I like this team. They're good people, and they understand their business. They write quite a lot of code, and they get along. There is nothing to dislike, and much anyone...

Wherever I go, I find people who want to "implement agile" but they want to start with processes and tools. They could develop techniques first, but they want to begin with working at a very large scale and comparing capabilities across teams and maintaining individual accountability and individual review. They want a big program they can plug into their existing system. A lot of organizations want to "go agile" starting with long-range planning, so that they can control the direction and results of the agile teams and track their progress toward n-year goals. They want an agile way to drive their teams in a straight line. Some corporations have layers of hierarchy devoted to contacting customers, usually in the interest of controlling perceptions and getting marketing intelligence. They wouldn't let developers within a mile of anyone who actually uses the software, for fear that they would let the internal culture and personality of the company leak out. O...

(note: I added a 15th, but was worried that changing the title would invalidate links, so you get a bonus observation at no extra cost) I frequently have to address questions about velocity, so in the interest of time I present all the answers here in a short post: Velocity is a gauge, not a control knob. You can't just turn up the velocity -- you can only break the gauge by trying. Velocity is (frustratingly) a lagging indicator. It primarily tells you about the fundamental process and technical work you did weeks, months, or years ago. You seldom get an immediate, true improvement. Though velocity is a gauge, it is subject to  Goodhart's Law . It is rather dodgy when used as a basis for governance. Velocity value is highly derivative of many factors, chief among them being the work structure of the organization. The more governance and procedure (permission steps, queuing and wait states, official limitations,  risk of personal blame, reporting and rec...

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

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

Today we held the first ever Puzzle Challenge at my client's site. The goal of the challenge was for each team to pick a work style that aided them in getting the greatest number of puzzles completed in a very short time (10 minutes per sprint). The set of puzzles to solved was a mix of crosswords, mazes, word-search, sudoku, word jumbles, and number blocks. The teams were told that there was no partial credit at the end of the ten minute sprint. The teams were given a menu of practices to choose from: Team members could one mode of adaptation, leadership, teamwork, noise level, and task switching. A style of 11111 would mean a 1 in each of these categories, a style strongly resembling an "ideal" organization in the buttoned-down 80s. A style of 33333 is basically a productive chaos, which might have been more widely recommended in the free-spirited 60s. Teams made an initial selection, then were allowed some adaptation. In initial selection of work s...

I approached my second (their third) day of #ACCUS after a full night's sleep. The evening social time was great, because it involved some fine people. I had two sessions, one each in the first and last timeslots of the day. Pairing Styles The first was a little workshop to identify and evaluate pairing styles. I was there to collect data primarily, and I did. We mapped the styles I had identified and added to them. The best part was the conversation among the attendees as we tried to evaluate them. The emergent thesis is that styles are not inherently good or bad, but that they reveal the relationship of the partners. All styles could be energizing, or could be draining, depending primarily on: The involvement they bring to the session The degree to which they both focus on the code instead of each other The degree to which each recognizes the contribution of the other The Coaching Oracle Deck This idea was based on Brian Eno's famous Oblique Strategies  concept...

I missed the Friday session. I worked a full day in Des Moines and then drove 11 hours (and into an earlier time zone) overnight. I only arrived this morning at about 4:30 or so and got parked and checked in. I slept from a little after 5 until 7, and then got up and headed to the conference after falling down some stairs and finally finding the conference site. Even tired, slightly battered, and a little frustrated, I had a wonderful day. I was pleased to meet up with many great coaches, devs, managers, and non-IT people here. I even have some new "new best friends." The morning sessions involved growing learning cultures, integrating project teams, and systems thinking. They were had great questions, wonderful discussions, and prankish humor. It was a great morning. I had intended to participate in the afternoon sessions, but the first one (on complacence, coincidentally) I missed to talk about other passions of mine with some of my coaching friends of old, and some...

A friend of mine (Hi George D) suggested that this would make a good poster, but all I have is a couple of blogs, so here is the message that inspired my buddy. My experience is that the less well a team has done in the past, the more oversight is piled on, and that oversight reaches higher and higher levels. There really is no legitimate reason for the CEO to want to know which programmer 5 or more levels below was assigned to a particular task and if he's behind schedule by a week or so. In healthier organizations, the groups and managers that interface with the development group tend not to have the same meddlesome urges. In our transitions, the biggest problem we face tends to be peeling back the expensive and unnecessary oversight. If the team can be rebooted and work with a single stream of smaller, simpler stories (rest of agile practices included) then they can win over the rest of the org in relatively short order. Sometimes in only a year or two, som...

On Aug 4, 2008 I moved from Object Mentor where I was an Agile coach and mentor to various companies to Textura where I have been an internal coach and now am managing a team of developers. I realized that I need a new professional outlet now since I won't be filling up the pages of the Object Mentor blog. My friends recommended that I start working on personal branding by starting up an individual pro blog outside of my work environment. I will be writing from myself, and not from the point of view of any employer. Welcome to the result of that. Now I am working the agile transition from a whole different angle. Hopefully, this will be a great time of growth for me as well and I intend to blog my observations about agile practice as usual. I hope it will be a place where people can participate by giving me new observations, advice, and even possibly an occasional boot to the head. Enjoy. We will cover many miles together.