Agile Otter Blog

I feel safe to say that "being agile" is more than a mere state of mind, because an agile person or team has definite practices and tendencies that are not present in non-agile environments. I don't doubt that there is a change in values, but I argue that those changes will have practical, daily results that can be seen. Too many people hear/see "just a mindset" and think of the four tiny sentences in the front page of the manifesto (which skips over the first paragraph, which is by far the more important IMHO). To wit:  A team is working 80+ hours a week.   The design and architecture were carved in stone last year.   The members all "do their own work."   Each team member has 18 tasks "in process"   They're "debugging their way to release" without automation   The last five retros have ended with "oh, well. We'll try to do better, I guess."   They are all competing against each other for recognition/award...

An i nteresting article from Sara Mednick linked insight and sleep, but in her explanation on page 27 I saw some interesting echoes of the work done in 1920s by Graham Wallas. This is an excerpt from the paper linked above (emphasis mine): The insight gain studied by Wagner et al. initially revealed itself in an implicit manner.  Then, through a slow process (enhanced by sleep), it emerged from the nondeclarative into the declar- ative realms as a fully assembled insight into the task structure.  The authors proposed that insight gain is not a pro- cedural learning process, since the reac- tion time data did not become faster with learning, which is the hallmark of procedural learning.  Instead, all participants who gained insight (regardless of whether they were in the sleep or wake groups) actually showed a slowing in reaction time just prior to insight gain compared with participants who did not gain insight.   “Specifically, the slow- ing of reaction...

An interesting article was published in the New York Times recently reporting that, experimentally at least, teams have a measurable collective intelligence, and that this intelligence is drawn from unexpected wells. We might expect that those teams had really smart leaders and high IQs in general than others. It seems reasonable in today's world where we respect individual skills and individual characteristics and bank so much on the charisma and dominating spirit of strong leaders. That is why it is so interesting that this theory is entirely wrong. Instead, there are three reported attributes that seem to favor some teams: Equality Empathy More females in the population. The second, empathy, was a bit surprising only because male developers pride themselves on separating their feelings from their work -- compartmentalizing the subjective from the subject matter. Maybe that was wrong all along also, and a barrier to passionate or fulfilling work. In short, we don...

First look at this video... We can have a laugh at this poor lady's bad moment (and frankly, I did -- don't judge me). But it is funny because we see this all the time in different forms. How many times have you seen a team crank up the size of its sprint "commitment" because they didn't make the last one? How many times have you seen people struggle with a practice by doing it "wrong" over and over until they simply got sick of trying and quit? When we're focused on something else (getting the release out, dealing with a bad review, feeling bad about a skill we need but don't have) we can easily get into this kind of a mess. Here you know that she knew intuitively that her problem was that the gas cap was on the other side, but she somehow got it into her head that it was the wrong side of the post and not the car. She kept pulling up to one side and then the other, sure that she got on the right side of the post this time. It was...

2014 was the year of the brain.  I decided to put aside most of my other reading materials and concentrate on reading books about brain function. I read up on neuroleadership and cognitive science and motivation. I got into a lot of content, and learned a lot of interesting things which should help me not only to coach and lead others, but to manage my own mental state better than I ever have before. Some of that learning was from The Leadership Gift, where my involvement was kindly sponsored by Industrial Logic. Underneath all of these studies and stories and new understandings, I learned a lot about empathy and sympathy and caring for others. What it means to be human is essentially that we're stumbling through a paltry handful of decades with impaired ability to gather, assess, judge, and accept reality. We're all from different places, with different mental models and mindsets, and we can work this all out together if we're willing to open up. But we can. We ...

The question asked was "how do we know we need a coach?" The more general question is "how do we know if we need help?" The question seems to assume that the goal of coaching and training are rescue; that the team is in trouble or incapable of success. That's horsefeathers. I think that the more valid question is "are we working as well as we can?" Here are my criteria for teams that don't need anything: We deliver Delivering software keeps getting easier We are always learning We have fun If all four of those are true for a team, then that team probably doesn't need help. Of course if those are true, then the team is poised to provide a lot of help to other teams by describing how they work.

This is from 2005, when I was at an all-linux, all-python shop called Progeny Linux Systems. A lovely time, really. Great people, interesting technology, challenges and opportunities every day. Not everything we did was stellar, but we were moving together in a good direction. We started using git when it really was a "git" (a stupid person or thing) and the tools were very confusing because they mixed noun names and verbs, and people were just kind of used to it being confusing. You used to have to go by hand into the innards of the .git directory structor to create tags and branches.  A "porcelain" was a wrapper around git to make it more useful and tolerable, and ours was specific to building custom Linux distributions. It was a cool project.  My contribution was very meager: I complained about the inconsistent naming of git tools at the time.  I started with a question  here : So when this gets all settled, will we see a lot of tool renamin...