Agile Otter Blog

Error-avoiding is overrated. Too often people want to wait surprisingly long periods of time before making a move, in fear that their move might be the wrong thing to do. The amount of fear and pre-thought we put into projects can be staggering. I'm not here to say that design and architecture and platform design aren't important. Clearly there is value to having a workable plan and a goal in sight.  However, the idea that you must be right on the first day of development flies in the face of all our experience with application development. You only need to be "right enough" at first, and able to correct as time goes on. We can become invested in concepts, ideas, development stacks, and architectures to the point that we forget that all up-front design decisions are just guesses. It's akin to a man walking up to the blackjack table with the intention to draw twice on the first hand and once on the second, even though those hands have not been dealt. The proble...

I'm back to hacking some python (fun stuff!) and have been noting some packages that every well-dressed virtualenv should have. I'm interested in knowing what you use, and for what. Essential packages I can hardly live without: bpython - because it's my favorite shell sniffer - because CT is the bomb, and sniffer works on mac (autonose not so much) mox - though I don't totally love it, I'm somewhat used to it now. May switch to something more context-manager-like. Task-specific stuff: BeautifulSoup - if I'm parsing stuff. I really like this library mechanize - if I'm writing tests on a web framework. Other than js weakness, it's quite nice feedparser - for rss stuff PIL - because image manipulation is no fun without it What do you feel a well-dressed virtualenv should wear this season?

Dear Mercurial, I don't love you (yet). This looks fine if you only spend a few minutes in the 2-3-2-3 loop. On the other hand, if you're in a very busy team and there are refactorings going on (and when shouldn't there be?) then you will want to have a loop from 3 to 1 pretty darned often (at LEAST a handful of times a day). At step 1, "For a while" should mean "if a couple of commits have been made by coworkers." The problem I have with mercurial is that the process of pull, merge, commit is too cumbersome. I have coworkers who swear by rebase, and others who have been bitten enough that they're scared to death to use rebase, and instead pile up the "merge" commits. There needs to be some kind of change made, if only to fix rebase, because this work flow is broken for active, productive, agile teams.

Today we held the first ever Puzzle Challenge at my client's site. The goal of the challenge was for each team to pick a work style that aided them in getting the greatest number of puzzles completed in a very short time (10 minutes per sprint). The set of puzzles to solved was a mix of crosswords, mazes, word-search, sudoku, word jumbles, and number blocks. The teams were told that there was no partial credit at the end of the ten minute sprint. The teams were given a menu of practices to choose from: Team members could one mode of adaptation, leadership, teamwork, noise level, and task switching. A style of 11111 would mean a 1 in each of these categories, a style strongly resembling an "ideal" organization in the buttoned-down 80s. A style of 33333 is basically a productive chaos, which might have been more widely recommended in the free-spirited 60s. Teams made an initial selection, then were allowed some adaptation. In initial selection of work s...

code_swarm - Python from Michael Ogawa on Vimeo .

Poignant quote on working in cross-functional teams with learning milestones: "I predict that you pretty quickly will get feedback from your teams that the new process is reducing their productivity. They will ask to go back to the old way of working, in which they had the opportunity to “stay efficient” by working in larger batches and passing work between departments." Ries, Eric (2011-09-13). The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses (p. 19). Crown Business. Kindle Edition. 

See the recent article on management lessons from Linus Torvalds.  Some important call-outs: On external quality: Torvalds concludes, “Way too many projects seem to think that the code is more important than the user, and they break things left and right, and they don't apologize for it, because they feel that they are ‘fixing’ the code and doing the right thing.” On tooling: “I don't think tools are all that fundamentally  important.” “Now, what is important is that there's  a good workflow for the project , and tools can certainly help with that,” said Torvalds. “But most projects don't necessarily really need tools. There's a lot of projects that simply don't have enough changes to really require any tools at all for their work flow; [...]"