Tuesday, September 27, 2011

Lean Startup and Efficiency

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. 

Linus Torvalds Management Lessons

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

Monday, September 26, 2011

Agile Coaching Camp wrapup

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, and the fun of fortune cookies. Glen Smith and I played with the idea years ago (he introduced me to the idea), and even had a little program to pop up the strategies. Sadly, that code and the original list of ideas were lost. It came back up at Agile And Beyond in Ann Arbor this year, and I happened upon those cards while sorting through my stuff at ACCUS.
We play-tested it informally in the common area while sessions went on elsewhere. I figured it was worth a more formal play-test. 
I think that the session hit two snags. The first was that people were feeling much more emotionally involved as a result of other sessions going on that day, and the other was that I wasn't managing the pacing very well. Rather than play-testing a fun technique by stating a question and rating whether a randomly-drawn card just happened to be good advice in the scenario, we entered into a deeper talk about problems and possible directions. I really hadn't intended this to be a problem-solving session with deep emotional impact, but at an open space whatever happens is the only thing that could have. 
I suspect that the primary value of the cards is that they are generally good things to think about, the randomness of the draw means that they'll come out of left field, and considering them will help take us out of ourselves. This thesis was not supported by our session.  Instead, they were deeply considered, contextualized to the person drawing the card, and considered for their ability to point out a solution.
More on this as it happens.
Other Thoughts of the Day
I hear that a couple of the sessions had people in tears, and approximated a self-help session far more than a professional conference. Certainly I felt that way with the "checking in" part of the session at the end, and the direction many of the "appreciations" took. I'm okay with that, and don't deny other people's need for it, but I'm either a little cold or a little emotionally squeamish, or perhaps just too focused on enjoying the work we do together to really participate. My primary feeling when I hear that a session had people in tears was, "glad I missed that." Maybe those people got more out of the conference than I did, I can't really say. 
On the other hand, I have a stack of new ideas and had some of my intentions and interests vetted and validated. I'm going to dig into more topics that will help me learn, analyze, and adapt my work. That's one of the reasons I've attended.
I also have new friends and contacts, and have connected with friends and colleagues.  This is the other reason I drove across the midwest in the middle of the night rather than going directly home to my family.  
It was  a very net-positive weekend, and I recommend Agile Coaching Camp to all my readers.  
Next year, in Minneapolis!

Saturday, September 24, 2011

Agile Coach Camp U.S. - Saturday (#accus)

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 brand new ones. We talked about coaching psychology, whether our coaching was necessarily agile, and how to avoid "going native."

Entirely without any intention to do so, I missed all of the afternoon sessions. It was a really great time, though, and the contacts are very important to me.

Tomorrow I'm running two sessions of the three time slots available, so I guess I can't miss much.

In the morning we're cataloging pair programming patterns, and in the last session of the day we're playtesting an agile version of Eno's "Oblique Strategies."

There is a lot of interest in a new site/blog for posting and analyzing code, in the strategies deck, in Agile In A Flash, and in the new pair programming work that Jim Hood and I are starting to work on. I have great stuff to do and need to get cracking.

I'm hoping to move one of my sessions so I can join George Dinwiddie and friends in a talk about metrics, but we'll see in the morning. I even had a minute or two with Lisa Crispin.

I can recommend ACCUS for everyone in the business or in its periphery as a great meeting of minds. I'm tired, and yet it has kept me energized all day.


Tuesday, September 20, 2011

The Build is Broken, Now What?

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 only you. If someone is working on the build and you push a second mistake, they won't know if they fixed it or broke it worse. If the build is not broken, why bother pushing errors to it? 
  • If you're not fixing the build, never push a working local change to a broken build.
    This is a kindness akin to not walking in the dirt your mother is sweeping up. If you push a change while the build is broken, the person fixing the build will have yet another update/build/test cycle on his hands before he can push his fix to the server. Don't punish the volunteer by pushing your changes. Wait, pull, merge, retest.

We have installed annunciators for teams. Sometimes they are flashing lights, sometimes a glowing orb, sometimes speakers playing a particular noise, sometimes it's just a person standing up and yelling that the build is down. Usually there is some electronic communication (jabber message or email) as well.

Why do we all need to know that the build is broken, and how long it is broken? So that we can alter our behavior. Someone needs to jump in and fix the build quickly, and everyone else needs to let them or help them. By leaving the build broken, continuing to build and push code as always, or pushing additional errors into the build, we are just getting in the way of the team.

Build annunciators should let you know when you need to get out of the way.  They don't have to be piercing and shrill or overly bright, but they need to keep the team aware that the build is not "green."

It's not just a good idea... well, actually it is.

Friday, September 16, 2011

Pycon: Examples of Atrocity in Python Programming

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).

Wednesday, September 14, 2011

Ambient Annunciators

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 conversations and won't get headaches associated with flashing lights.

Tuesday, September 13, 2011

How Do Scrum Masters Know?

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?

Learning from bad examples

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.

Monday, September 12, 2011

Scrum Master Duties


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

Tuesday, September 6, 2011

You Cannot Possibly Do TDD after Coding

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 whether you do them first or last, and redundancy would be silly and worth avoiding.

If tests are rightfully seen as process, then redundancy is "coherence" and not worth avoiding. It helps us move forward.

The biggest problem with TDD is that if you're not doing the process, then the product (tests) don't make sense.

Hate TDD? Then there's a good chance you're not actually doing it.