Agile Otter Blog

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; [...]"

I approached my second (their third) day of #ACCUS after a full night's sleep. The evening social time was great, because it involved some fine people. I had two sessions, one each in the first and last timeslots of the day. Pairing Styles The first was a little workshop to identify and evaluate pairing styles. I was there to collect data primarily, and I did. We mapped the styles I had identified and added to them. The best part was the conversation among the attendees as we tried to evaluate them. The emergent thesis is that styles are not inherently good or bad, but that they reveal the relationship of the partners. All styles could be energizing, or could be draining, depending primarily on: The involvement they bring to the session The degree to which they both focus on the code instead of each other The degree to which each recognizes the contribution of the other The Coaching Oracle Deck This idea was based on Brian Eno's famous Oblique Strategies  concept...

I missed the Friday session. I worked a full day in Des Moines and then drove 11 hours (and into an earlier time zone) overnight. I only arrived this morning at about 4:30 or so and got parked and checked in. I slept from a little after 5 until 7, and then got up and headed to the conference after falling down some stairs and finally finding the conference site. Even tired, slightly battered, and a little frustrated, I had a wonderful day. I was pleased to meet up with many great coaches, devs, managers, and non-IT people here. I even have some new "new best friends." The morning sessions involved growing learning cultures, integrating project teams, and systems thinking. They were had great questions, wonderful discussions, and prankish humor. It was a great morning. I had intended to participate in the afternoon sessions, but the first one (on complacence, coincidentally) I missed to talk about other passions of mine with some of my coaching friends of old, and some...

Your team is hard at work, testing and coding and planning, and suddenly the build breaks. Now what can you do? The broken build might not be your fault at all, and besides you have work of your own to do. You could go ahead and practice business-as-usual, but this is probably a bad idea. Here's what I say: Never pull from a broken build . Assume that version control is poison. If you are not the one fixing the build (and shouldn't you be?) then you should leave it be. The last thing you want to do is import brokenness into your local build environment. Import from a "green" build, and you will know that any brokenness is your problem. Test locally before considering pushing code to the CI build, even though it takes a bit more time. There is really no good time to NOT know that you've broken something. A little "due diligence" goes a long way. Never push to the CI server if your local build is broken . If your build is broken, it inconveniences...

A nice discussion about things that should not be done in Python code, but frequently are. Nice mention of Clean Code's naming rules (I'm a proud daddy).

Jim Hood (of Pillar Technology) and I just installed our first ever "ambient annunciator" to announce our build's breakage. Well, technically our first two. What it does is watch for a build to fail in Jenkins, then start playing a series of randomly-selected choices from our assortment of spooky public domain sound files. Some are musical interludes, some are animal sounds, some are just weird. Annunciator #2 video, woofer, and R/L speakers. Our intention is that these sounds, playing through a decent set of speakers, will create an atmosphere of something being "not quite right." With both systems playing test noises, it was a tad eerie. You really felt that there was something different about the space. It is a bit more subtle than flashing lights, and we're hoping this will be an advantage. Developers will know the build is broken, and will have incentive to get the space back to normal (it is a little annoying) but will still be able to have co...

How do Scrum Masters Know? This time the question is how the scrum masters know if they're doing a good job. They answered with this short list of feedback mechanisms. Scrum of Scrums Changes embodied in team behavior. Retrospectives Status of Kanban boards Things missed Overall, not a bad list. Your thoughts?

I saw this in a python tutorial today: if os.path.exists("/tmp/uPlayer"): f = open("/tmp/uPlayer/STATUS", "w") f.write("IDLE") f.close else: os.mkdir("/tmp/uPlayer") f = open("/tmp/uPlayer/STATUS", "w") f.write("IDLE") f.close Really, now? We start by duplicating the whole open/write thing in order to create a directory? Maybe one of the problems people have with clean coding is that their examples are poor. If you write, it behooves you to write refrigerator code. Not to mention that close is a function, so it needs parentheses. This code doesn't even do what it thinks it is doing. It's closing the file when f goes out of scope, not when we reference the f.close bound method. It makes me sad for the children.

  This is the result from asking a team of scrum masters what their duties entail.  What do you think?

Just for the record: it is flat out impossible to "do the tdd" after the code is finished. This is just a matter of definition. You can write tests after the code is finished, but that has no relationship to TDD whatsoever. None. Nada. Zip. In TDD you write a new, failing test. Next you write enough code to pass the test. Then you refactor. This repeats until the code is done, writing and running tests continually. It shapes the way the code is written. It is a technique for making sure you write the right code, and that you do so in an incremental and iterative way. In ATDD, you have a failing acceptance tests. You take the first failing tests (or the easiest) and use TDD to build the code so that that part of the AT passes. You run the AT after each major step that you've built using TDD. When the AT is all green, you have completed the feature. This helps avoid early stop and also helps avoid gold-plating. If tests were product, then it would make no difference...