Agile Otter Blog

We need to explain our primary statement of benevolence, expressed as "make people awesome." This is intended to express that have an explicit goal of benefitting specific others with all of our work. I have had so many apologetic conversations (not as in "I'm sorry" but as in "apologetics") about the term, and it's been described in several articles (some well, some rather poorly). The message is singularly hard to express, at least in a form that fits on the sticker. Admittedly, it's 2017. Everyone is on high alert, and words trigger people in dozens of interesting ways. To date, the primary triggers are: "make people" - which tends to be heard as "coerce, demand, or force", where we intend it to be more along the lines of "make your visitors feel at home."  "awesome" - which tends to be heard as "valley girl talk", indicating the speaker is bubble-headed or shallow.   Th...

Once we had "lightweight methods" as a frequent topic of discussion. It's still the movement I pursue. Some innovators came through and invented radically different ways of working, usually through collaboration and teamwork. The idea of simplifying the workflow was met with much enthusiasm in some quarters and surprisingly hot disdain and outraged anger in others. Still, those practicing lightweight methods produced software quite well, so lightweight methods persevered.  Lightweight methods took the name "agile", which is a perfectly good name.  Even so, I'll not use it much here.  Lightweight methods pursue "the least process you can afford" at all times.  If you can afford less documentation, then cut some of the documentation out. If you can afford fewer queues and piles, then streamline your process.  If you can afford a cheaper alternative to approval cycles or big plans up front, by all means, use the faster cheaper alterna...

As developers, we want to produce results and we want to produce them fast. Normally, we work in the context of a team, where we all collectively want to be fast and stay fast, and produce results that work. In order to become fast, we have to learn the tools and techniques which allow us to practice fastness and we need to measure whether a technique or tool actually lets us be sustainably fast as a group. That's hard. But it's important. Today I was thinking about all the work we do and the practices we use. In hopes that it will be useful to stir up conversation and debate, I have tried to sum up our practices in a small set of imperatives: Write useful code only.  Don't write defects. Don't write code that invites others to create defects. Don't write code which hides or obfuscates defects (yours or other people's).  Don't cultivate habits which may result in code which contains, hides, or obfuscates defects. Don't take your adva...

Here is a week in the life of a technical coach. I started the week by flying. I'm about an hour's drive from the airport, and this particular flight was only a couple of hours. When I land, I have about a half-hour to forty-five minutes standing outside in a taxi line, then an hour's drive to my hotel. The hotel is wonderful. I have fish-n-chips in the hotel restaurant and check in for the night. The next day work starts. I was working with a team (which remains anonymous). We had a quick talk, then picked up some work to do together. We agreed to try mob programming all day, with punctuated bits of explanation along the way.  I asked that we do real work all week. However, I know it's threatening to pick someone's work that was done in private so far, and then put it on the board in front of everyone and spot code smells and issues. It just seems unfair. As a result we decided to do some real work that nobody had been working on yet.  I suggested that it c...

Imagine if you would a class in an object-oriented language. Notice that x() and y() are not constructors. Now, a "good" user of an instance of Trouble will do something like this: t.x(); // always call x() before y()    t.y();  Whereas a naive user of the class might do something more like this: t.y(); In this case the value of i1 (used by function y )  is either undefined or possibly some leftover value from earlier uses of instance t. How Do You Know? The functions x and y have an implicit temporal binding.  When you look at the object diagram, or if you use code completion, nothing you see will tell you that you must call x before y . Either: You don't know about it, and have been "just lucky" so far You don't know, and are currently making bugs you don't know about You know because you've read the code from top to bottom and understand the implicit temporal coupling.  You copied someone else's example after y...

Your employee “wastes” time doing a feature you didn’t approve. You find out about the feature as it is being released to customers. Customers are enthusiastically happy with the new feature. Thrilled, in fact. They complement you and your team! Do you reign in your rogue employee  give her more influence in deciding future features ignore this one infraction since it worked out okay Quickly write down your answer and then read the next paragraph. ... Okay, you've written down your answer. It doesn't matter so much to me what answer you chose, or if you chose one not given above. What I want to know is what were the principles on which you based your answer. How important was the outcome v. the process?  How crucial is conformance and predictability of action v. success of action and engagement?  Was the employee's act one of insubordination or service to customers?  Which is more important?  If you complete this little meditat...

The question was asked: In Test-Driven Development, what does it mean to start with a failing test?  This is not a complicated question, so let me give the short answer: Write a test that can't possibly succeed because you have not yet implemented the feature; but which would succeed if the part of the feature it's testing were written. You want it to be a good test: clear, obvious, simple, discrete. You want it to fail, so you see what the error message will look like -- whether it will provide enough information when someday it fails unexpectedly. Then you write enough feature that the test passes works (but not the whole feature). The idea is like a video game. You write a test, which is your first challenge. Then you beat that challenge and save your game (to version control) so you can come back. You layer on the challenges until you've beat the game (written the feature). There is more to the TDD cycle, but this is enough to answer the one questi...