Agile Otter Blog

All anger presents as righteous indignation. Have you ever been angry without thinking you had every right to be so? The person you're angry with certainly seems to deserving of the wrath and disdain we feel in the moment.  Maybe being angry makes us too sure, too certain of our view of others, too unquestioning of reaction to others.  Anger almost always seems like righteous indignation -- while you're in it. Righteous indignation is a powerful emotion and an addictive one.  It leads to a lot of victim-blaming.  Surely if those people didn't make us mad, then they wouldn't have to deal with the consequences of making us mad.  Anger justifies acting badly. When we are angry enough we can use force, bullying, pillory, public humiliation, verbal abuse, defamation ... well, that's okay because we are the good guys . It's okay when Batman takes the law into his own hands. It's okay when Superman drops someone's office building on Luthor. It's oka...

For decades now, people are taught a definition of "success": a successful team delivers the full scope on time and under budget. It has been the mantra of project managers and has been taught in books, in magazines, in college classes, and by word-of-mouth for GENERATIONS of managers and workers. Starting in the 80s and 90s we started hearing echoes from the 60s that a successful project is built as a series of small successes with incremental and iterative work. Next, we hear that a project is successful if it meets the client's needs on the day of delivery , rather than the day the contract is signed. And then we hear that successful products are different from projects, and project-thinking may not even be valid. The goal is to build a user base, not a defined content. Now it is about the income (economic engine) that the product represents.  No more thinking about the day of delivery and the payment for delivering the thing; it's a longer view. And t...

I had answered a question on LinkedIn , after which a friend was kind enough to quote my answer on twitter with a kind recommendation. I decided to reproduce that answer here. Enjoy! The Post "We have initial idea for a change but approach and end result is not clear. The approach and overall requirement tend to change during the course of development."  Congratulations! You are in exactly the standard circumstances for a truly agile approach! The secrets here are to be incremental (adding bits at a time, rather than coding to a designed end-point) and iterative (revisiting code to improve its design and function) using inspect-and-adapt. The standard rule is "make it do something, however trivial, on day one; then keep it running at all times" and "add functionality in very thin end-to-end bits so that you don't have a big integration nightmare at the end." Enemies of this approach are anything that makes it hard to iterate, increment, ...

What is your role in the code base you find yourself in today?  Owner?  Renter? Guest? Visitor?  Vandal? I ask seriously because I'm learning that the answers matter.  A lot. An owner makes property improvements, upgrades, installations, replacements.  It belongs to them, and its value is important. An owner can paint, can put in a staircase, can replace the plumbing. A renter tries to not make things worse and can make superficial improvements. Maybe they can paint or change out some things, but only with permission from the owner. Anything that is really wrong, that's on the owner. A renter doesn't repave the drive, put in a deck, fix the drainage of the basement. It's not really theirs. A guest is just there for the day; not really permitted to make changes at all. They can use the facilities that exist, but that's all. Could you imagine, "Hello people of Pisa. I just noticed your tower is crooked, so I fixed it."  G...

I wrote a thing yesterday…. it was in python, and I was using PyCharm (which is very nice, and a departure from using vim + sniffer). It was something I didn’t know how to do initially, and couldn’t really figure out how to test drive.  I did it without pair- or mob-programming. It was essentially a screen-scraping tool to dl the latest version of a zip file... that's not really interesting. I had to learn or relearn some libraries I’d forgotten about, using docs and StackOverflow , and the “inspect element” feature of chrome quite heavily.  I whinged about the lack of ids and names on elements in web pages on Twitter, but eventually got it worked out. Because I wasn't sure how to make it work to begin with, I used the ipython repl  (via the 'Python Terminal' window in PyCharm. I would try various ways of locating the anchor link I wanted until I found one that I thought was far less-fragile than the other ways (such as some rather dubious XPath ). I basi...

Those People When you hear "those people are always complaining" then you're probably looking at a systemic problem.  It's probably not a personality flaw ; it's probably that the system in play disadvantages them constantly. It's easier to do victim-blaming, but maybe it's time to investigate. The Fundamental Attribution Error is too easy to fall into, especially when it allows you to write off a whole group of people you don't know how to please. This isn't a social justice thing (only), but it's an organizational thing. "Testers are all whiners", "the programmers are always grumpy", "middle managers are so brusque and rude", "ops people are jerks" Which group "always complains" where you work... and have you ever looked at the systemic reasons for that? I've heard leaders say "QA people are all whiners" when their way of working seemed to always bring testing prof...