Agile Otter Blog

I was once told to "exalt the obvious." There is a power in it, because sometimes we overlook obvious things that are blessings to us and can reshape our world. This, I think, is one such. 'Way back in the 80s and 90s we were trying to get people to practice Object-Oriented Design and Object-Oriented Languages were gaining a bit of ground. Heck, in '86 or so C++ started to be a big deal, because it mixed some OO with our beloved C. Soon we saw semi-OO BASIC and even a version of Object-Oriented COBOL. Wow. We tried to codify principles and practices that helped people to do good design. You probably followed all the great stuff we did at Object Mentor, led by Uncle Bob Martin (who I still appreciate and respect, though we don't see each other very often). We expounded on coupling and cohesion, as well we should, but we lacked the mechanism in our programming environments to help us really seat the idea of OO in the minds of our fellows. Serendipity We...

There was an opportunity at a recent open space conference for Mike Rizzi and myself to conduct a short session on "what to read." As expected, there is more here than anyone could hope to digest in a year of hard reading, but I think this might be interesting to the Agile Otter audience, and I hate to waste all the good work Mike did in organizing and fact-checking the titles. Here is Mike's note from the conference proceedings:  In this session, everyone wrote on large index cards titles of books that have inspired them. They were then arranged them on the floor looking for patterns and affinities. We then took turns saying why each book inspired or helped us. The fast paced discussions were fascinating, and I left with even more books to add to my reading pile(s).   -- mike rizzi Enjoy. PHILOSOPHIC BASIS Symposium and Phaedrus - Plato Liftoff: Launching Agile Teams & Projects - Diane Larsen & Ainsley Nies Impro: Improvisation and the Th...

I was speaking with my friend Bryan who, like myself, does a lot of work with very large organizations. Many of them are great places and have sincere interest in being wonderful places to work with wonderful people. Sometimes, though, they struggle. In considering the nature of their struggles, I realized that I've collected or formed some observations of dynamics and I've not really vetted them all publically. I'd like to take this moment to think out loud and, with kindness and curiosity and empathy, see if we can develop and refine these observations -- or possibly strike them entirely if they seem utterly false. Please join me via comments or emails (tottinge@gmail.com or tottinge@industriallogic.com) to let me know what you think about these observations, what I'm missing, and what I can do to fill out the set better. Just remember, this is about curiosity and systems -- I'm not here to tear anyone down. Dunbar's Number Researcher Dunbar notic...

Somewhere back in the first quarter of 2015 I decided to declare this my Year of  Living Shamelessly. I decided this means that I will live by all the best guidance I've been given, to the best of my ability. I won't surrender my responsibility for my actions and consequences to "but I was following the recipe" but instead, I will try to practice (in a mindful way) those teachings which I find to be most profound. These teachings come from my protestant upbringing and scriptures, from my early and current mentors, from people I respect and love, from many books on processes and human behavior, from psychological and neuroleadership sources, basically from anyone I've listened to whose teachings have resonated with me in a deep way. I've been pushing forward on these fronts: Empathy One of my key learnings from last year was that considering how you would feel in the other person's shoes is not empathy; it's self-involvement. It led me to judge o...

Often it's not the meat of an agile criticism that bothers me, but the revisionism. I rather like the article by Nick Kolakowski , except for this: "Agile has its roots in the Agile Manifesto, the product of 17 software developers coming together in 2001 to talk over development methods" Likewise this by Michael Church : The “Agile” fad grew up in web consulting, where it had a certain amount of value:   Not quite. It got a name and a manifesto then, but it was a gathering of practitioners of "lightweight methods" (and one waterfall guy: Hi Steve) who gathered and wrote the manifest to describe what they had been doing for some time. All the agile methods of the time had been hammered out in real projects for years. XP, for example, was begun with the 3C project in 1993 and was being written about extensively in comp.object usenet group well before the web, and before it even had a name.  It was a collection of radical ideas at the time and wa...

Charlie is a developer. He's just been assigned/volunteered to take on an interesting technical challenge. It will involve research, learning, and experimentation so it is exactly the kind of assignment that most developers would love to have. It is a problem that will take at least 10 days to solve. This problem, by its very nature, is a 12-day problem. Forget that, and this story will mean nothing to you. If the solution to the problem was clear-cut and obvious, then it would already exist in a library or a book or in google or StackOverflow. It doesn't, to the best of Charlie's knowledge. Of course, he looked. This isn't Charlie's first rodeo. Vinnie is Charlie's manager. He's a smart fellow and has quite a bit of experience. He has a good sense of organizational dynamics and deadlines and an amazing memory for minutiae that escapes other managers. He can juggle tasks and schedules like a wedding planner and never misses crucial dependencies. He kn...

When you are writing tests you end up using literals or hand-constructed data objects. However, using literals can obscure the meaning a little. Not horribly; most people can puzzle them out quickly enough, but you can make it easier on the reader. In most of these tests, the values are pretty much arbitrary, but the relationship between the values is essential. For instance, when checking that no bonus is given when sales is less than quota, I could state that sales is 10,000.00 and that the quota is 9,900.00.  Pretty much anyone could tell that the quota is less than sales here, right? But what if we made it really explicit?      double quota = 10000;      double sales = quota - 100; This is how I like to roll. For instance, in python:      event_date = datetime(2015,9,10)      later = event_date + timedelta(days=10)      earlier = event_date - timedelta(days=2) And how ...