Agile Otter Blog

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

For all the 'take back agile" and "agile smagile" and "apologizing for agile" and all the other post-agilists and so-called post-agilists in the world, I give you Otter's law: Any methodology followed via obligation and knowledge-avoidance cannot produce positive change.  I've ranted about change gone wrong and methodologies followed badly and horrible oversales and undersales and all, but it comes down to otter's law ultimately. Too many companies have huge gains from using XP and Scrum and what-have-you. Too many others tried "the same thing" with entirely different results. Some teams are whole-heartedly into the whole agile thing, and they seem to have pretty good. Others don't seem very excited and don't get much out of it. Is it excitement that they need? I don't think so. I think that the lack of excitement and the lack of progress have the same root. I think it's a lack of profluence in agile-a...

I was looking at the excellent work by appium, and saw this little snippet in an example: var el = driver.FindElementById ( "name_input" ); el.Clear (); el.SendKeys ( "Appium User" ); el.SendKeys (Keys.Return); There's nothing horribly wrong  with the name el, except that it's exactly what we ask people not to do with names.  El is short for element (a bit of mental mapping, but the length of the name reflects the shortness of scope). But it is not informative. The variable "el" (EE-EL) looks like "e1" (EE-ONE) to the casual reader. The name doesn't look right.  Also, "element" is what it's made of, not what it's for.  Yes it's an element. But it means "the name input field" so "nameField" or"name_field" or "name" might be better. Or even "input" if it's the only input field in the block....