One Man’s Walk in work

I led a session earlier today at Agile Open Northwest exploring the different shapes backlogs take. I am pretty familier with a couple, but I’ve been hearing about new ones, and wondered what other ones might be out there.

We found quite a few.

• Lists (ala XP as well as Scrum)
• Story Maps
• Using Kanban to Limit Your Backlog
• Chris Simms’ Urgent / Important Grid Backlog – stories are placed according to their importance / urgency, then promoted into “doing” on an intuitive basis by the person doing the work
• A nuevo XPish type – where only the current month is considered, each month has a theme at the top, and 4 iterations of stories that support that theme underneath
• Arlo Belshee’s Arloban (my name) – continuous flow w/ a small (3ish) limit and 3 vision cards on the left to remind people why they’re doing it
• Jim Benson’s Graduated Limited Backlog – where you consider a small number of very important items, a larger number of medium important items, and a larger number of low importance items. This is similar to the Grid backlog and good for Personal Kanban at least.
• A more progressive scrum backlog, where you only consider themes for things that are far off, then break them into epics as they come closer, and finally into stories when you are about to do them.
• Visioned MMFs – limiting the backlog to a small number of MMFs, but pairing them with the vision they support
• No backlog – generating only enough stories for the next sprint a few days before hand
  and using vision cards with it)
• Mindmapping – many of the benefits of storymapping, but supports arbitrary levels as well. They build out branches only as they need them.

We were reminded that the value / effort curve for analysis looks like this, so we should try to spend less time on it up front. However, a little time has a big bang for the buck. And sometimes, more time is necessary, even though there are diminishing returns.

We also spent a bit more time talking about Story Mapping, and about how the huge win there is not the map, but the process of creating the map and getting everyone on the same page.

It was fun, and I was happily surprised to see so much diversity out there!

Apologies for the lack of polish, but I thought it better to get it up here roughly than not at all.

Jim Benson and I are starting Seattle Lean Coffee on Wednesdays from 8:30am-10am at Uptown Espresso on Westlake & Republican.

We’ll be talking about things like visualizing work, limiting WIP, and *self organizing teams! If you’re in Seattle, join us this and every Wednesday morning!

What is Lean?

If you’re not familiar with Lean – people in the Agile & Scrum communities often describe it as all the lightweight, pragmatic, evidence based approaches that Agile has, but in language that makes sense to a CEO. In fact, it goes beyond Agile and has been translated across many industries, actually starting in Toyota’s manufacturing and supply chain. Today many of the fastest moving software teams that use Agile & Scrum are also adopting Lean thinking to get even better.

Want to know more?

• seattleleancoffee.wordpress.com – the official site for seattle lean coffee
• personalkanban.com – jim’s work on applying Lean to our personal life / work – very GTD
• kanban101.com – want to know more about Lean in Software? Go here.

I’m teaching the Ruby on Rails course at University of Washington Extension this quarter. I’m pretty excited to teach a 10 week course for a university. The one thing that makes it completely different from corporate and conference gigs is that I’ll need to grade homework! It is pass / fail, but still. Weird.

There are a lot of problems with grading. There is a huge loss of knowledge between when a student submits the work and I pick it up. I’ve got to figure out a lot of things before I can even begin to check it – where is it? is it working? why isn’t it working? And if it doesn’t do exactly what I wanted it to, I have to decide if that’s okay, or if I should throw it back over the wall. If I have any questions, I need to e-mail / phone the student. Also, if I let students do different projects, then every time I switch from one project to the next, I also need a huge context switch.

I could go on, but I’m hoping you’ve started seeing what I saw.

It’s almost like the students are developers, I am the customer, and I’m describing a traditional development project. WAIT A SECOND! I have all kinds of tools to make these projects suck less.

What agile grading might look like

Here’s what I’m thinking right now :

1. We have 3 hour classes that I was going to let students work through most of anyway, so why not do all the grading there, face to face, on their computers.
2. Pair (and rotate) the students. They’ll learn more, and I’ll have half as many streams of work to manage.
3. Instead of grading “assignments” (or releases), I’ll break up my assignments into stories, each of which will have acceptance criteria.
4. In class, I’ll put a story board up, with the one strange characteristic that each pair has its own backlog. It might look like this :
   
   Work will flow from “assigned”, to “in progress”, to “to grade”, to “accepted”. Only I can move a story from “to grade” to accepted.
5. In addition to all of this, I’ll break the 3 hours into hour long “iterations”. At the beginning of each, I’ll present any more stories to add, do some lecture, and we’ll talk about where we are on the board.

So how does this solve our problems? If I am not completely happy about a story, instead of accepting it, I move it back to assigned. If I have questions, I ask them. There is little ramp up, because the student will be there trying to get me to mark off each story.

It’s still early, but this seems to make so much more sense.

Push vs. Pull

One interesting thing is that after I’ve solved all the other problems, I’m still left with a push system. In my experience, push systems are almost always suboptimal. They will yield some teams that are frustrated because they can’t keep up, and other teams that are wasting time because they’re done. When I need to interrupt people to give them the next few stories, it won’t be at the right time for anyone, and it will be breaking their flow.

There are pull models for learning, though. In Montessori schools, the guide’s (teacher’s) job is to go and give individual lessons to each student as they are ready for them. Then, at their own pace, the students practice each lesson on their own. Watching the students, the guide then decides when they’re ready for the next thing. Of course, the student often asks for the next lesson too!

Don’t think I’m quite brave enough to try this the first time out… Maybe next time.

Thoughts? Suggestions?

I’ve jumped.

After 7 years of ThoughtWorks, 2 years of Pivotal, and a couple of small contracts in between, I’ve gone independent. I’m looking for work as a coach, trainer, or facilitator – mostly focusing on software teams that want to work on their process. So, not very far from what I was doing – I expect engagements will be a good deal shorter and won’t be doing any more straight development work.

A lot of work

I really thought I’d have more free time. In fact, between the gigs I’ve been fortunate enough to land, finding and preparing talks to give,, meeting people at networking events, reading everything I can get my hands on, and writing on my blog, my website, and about facilitation patterns, I’ve got more on my plate than I could ever actually do. Nevermind the non-profit I serve or the dance classes I teach. If it wasn’t for GTD, I’d never see my wife or friends.

Still, this is way more fun than I’ve had at work in a while. I seem to be getting the most important and strategic things done, and my wife has been giving me a ton of support. I’m also getting better at saying “no”, thank God.

Finding work

I’m not sure I can claim to have a fully developed marketing “campaign” yet, but I’m getting there. I’m reading and working through Book Yourself Solid, a book that has been three times recommended to me. It’s good.

My current strategy is to play to my strengths. I’ve got a lot of targeted experience and knowledge about enabling agile teams. Face-to-face, I’m a good listener, a decent connector, and gosh darn it, people like me. I’m trying to put myself in front of as many people as I can and be excellent. So I’ve been giving talks and leading exercises at conferences and user groups. I’m also focusing on establishing deep connections with people. I want to find your pain and help you with it. Maybe that means connecting you with someone else, suggesting a book, giving you some free advice, just listening, or talking about how I could help you in a professional capacity.

So far, it’s working well. I’ve gotten a few leads and a bit of work, and I get to spend my time helping people from a place of integrity – not what I thought marketing would feel like.

What I need from you

If you’ve worked with me in the past, you now know I’m available, so keep me in mind next time you hear about a team that’s struggling. I’m also looking to collect some quotes about how awesome I am, so send those my way .

I’m in the business of helping and connecting people right now. Let me know what’s blocking you, maybe I can help.

I often find myself wanting this method. This is my 3rd or 4th writing of it – it’s shorter this time. Inject is my new best friend.

class Array
  def to_hash
    inject({}) {|hash, i| hash[i[0]] = i[1]; hash}
  end
end

What this snippet does is take an array and turn it into a hash, like so

[["apple", 1], ["banana", 2], ["citrus", [3,4,5]] => 
    {"apple" => 1, "banana" => 2, "citrus" => [3,4,5]}

If I didn’t have to deal with the case where there may be subarrays, I’d use nick’s approach

Hash[*self.flatten]

My solution isn’t that much more code, and handles the case of subarrays.

Update

Ola makes the good point that this is actually the best of both worlds :

Hash[*self.flatten[1]]

Thanks Ola. …I still think inject is cool, though .

Cards is a ruby gem that allows you to quickly capture a card wall into a spreadsheet then print it up using omnigraffle or export it to csv (or now tracker)

This release adds a couple really cool improvements in it :

1. Numbers ‘09 finally has applescript support, so Cards can finally reach into it and grab what it needs instead of requiring a csv export.

2. Pivotal Tracker now has a sweet RESTful api that we can use to throw stuff directly into it.

Wouldn’t it be cool if the next thing cards could do for you is update your spreadsheet to add the tracker ids for created stories? Then you could maintain the spreadsheet and tracker. Maybe even get 2 way syncing going or something…

To illustrate, Cards lets you take this spreadsheet from Numbers and turn it into the card walls in omnigraffle that created it.

So first, some background.

In May 2007, a few of us started a not for profit in Seattle to promote blues dancing. We called it Burn Blue. It was my first take at helping to shape not just a team, not just a project, but a whole company. It’s been fun and a huge learning experience for me.

Burn Blue runs a weekly blues dance in Seattle. As such its success or failure completely depends on the dance community in Seattle that come to it. We’ve been really successful in reaching out to this community, and Burn Blue has done really well because of it.

I’ve personally had a lot of fun guiding Burn Blue toward being more community driven & transparent. I love this fuzzy stuff.

Fast forward to last weekend. I was running Burn Blue’s community meeting. We had promised people pancakes and a voice in Burn Blue’s future, and 35 people showed up.

There were however, a lot of challenges :
1. It was a lot of people, a lot of new people, people that hadn’t necessarily been to a community meeting before, people that didn’t necessarily know what Burn Blue was about.
2. There was a lot of information that we as directors wanted to get across to them about changes that we had made.
3. We wanted the people there to feel that this was THEIR meeting, that Burn Blue was there for THEM, and not the other way around.
4. We didn’t know what we didn’t know. We wanted to make sure that we discovered any other important things that needed to be addressed.
4. We wanted to actually get stuff done. We wanted actionable items out of the meeting along with the names of people who would do them.
5. We only had 3 hours.

Long story short, we did it right.

The directors and officers (all 5 of us) had met previously and talked about what we wanted to put into the meeting. We set a very rough agenda and recorded a few things that we wanted to hit. More importantly, we practiced setting an agenda in that meeting and working through it.

We had a big [Visible Agenda] and wrote ours down on a huge post it. It looked something like this :

• 1:00pm – arriving, eating pancakes
• 1:30pm – where are we? (temperature & retrospective)
• 2:00pm – burn blue structure
• 2:15pm – going over people’s input
• intermediate lesson
• venue
• improving feedback
• security
• …

Basically, people got there and milled around a bit while we helped -topher with pancakes (this was in our house). Around 1:30, when the pancakes still weren’t done, I called everyone’s attention together and gave them a couple jobs while they continued to eat and talk.

First, I wanted to get a group [Temperature]. I had written down Burn Blue’s 4 part mission on a giant post it and I drew a line to the right of each for part for people to judge us on.

Second, I had two more giant post its with the classic “keep” / “change” from retrospectives for people to add things to.

This was all information gathering, so I let the [Participants Write]. I also gave them an expectation that part of the meeting would last about half an hour.

Half an hour later, the formal part of the meeting started. We explained a little bit about what burn blue was. Then we started to go through what people had written down.

Karissa, my wife, who’s also a director, saw people beginning to get excited and start talking over each other, and she suggested a few [Ground Rules]. We as a group settled on [Use Gestures], [One Conversation], and [No Stories]. We also hadn’t actually set an end time for the meeting, so I asked people when they wanted to end. We decided that 4pm would make the most sense.

As we talked about the temperature sheet and the keep and change sheets, we wrote down things that we needed to talk about onto the [Visible Agenda]. We almost used it as a [Parking Lot] for everything until after we were done going through the input we’d gotten already.

And on it went. We found, as we’d hoped, that a lot of the things that we (the directors) had wanted to talk about were also concerns of the community. There were also several things that we hadn’t thought about.

We kept going. Our [Ground Rules] kept us focused. Pretty early on, I asked the group for the authority to play “Time Nazi” as we had close to 20 agenda items to go through and less than 2 hours left. When we went over 5 minutes on an item, I’d let people know, but some items were important enough to keep talking about, some weren’t.

We jumped around a bit on the agenda. Several times, the same person that brought up an agenda item conceded that it probably wasn’t as important as another one, and we went in roughly order of importance, crossing off agenda items as we covered them.

We ended up finishing the meeting at 4pm, deciding to leave the last few agenda items uncovered until the next meeting in a few months. As we had talked about each item, we had also been adding to another [Big Visible Chart], our [Action Items].

People left the meeting (though many stuck around to hang out) with a feeling of excitement and ownership. A feeling that things had just gotten better, that they had been heard and they had helped that to happen, knowing what their next actions were. The meeting was a total success.

For my part, I’ve been working a lot on http://facilitationpatterns.org/ lately and have had all these awesome patterns swimming around my mind. I called up several for this meeting. And had done so previously for the directors just before. This helped made the facilitation of the meeting into a joint effort.

It was really fun to take the reigns and pull out patterns that fit and customize them to the situation. I’m looking forward to our next meeting.

I’ve been working on http://facilitationpatterns.org/ for a while now. I’m hoping that it will eventually become a book.

You should check it out if you’re interested in facilitation, and that includes running a meeting, a standup, a retrospective, a release planning session, a quickstart, or even just brainstorming holiday plans with your family.

I have ~ 50 patterns up there already, but most are not fleshed out beyond a short summary. Though expect more up there over the coming months. I’d love feedback on the patterns, the structure, or anything else.

What I’ve heard from veteran facilitators that I’ve shown it to so far is that it’s a really good reminder of a lot of what you already know. This is what I’m going for. However, I think even these veteran facilitators will find a few new things to add to their toolbox.

Enjoy!

You know those 3 lines that show up every time you do an rspec run?

/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby -Ilib:test "/Library/Ruby/Gems/1.8/gems/rake-0.8.3/lib/rake/rake_test_loader.rb"  
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby -Ilib:test "/Library/Ruby/Gems/1.8/gems/rake-0.8.3/lib/rake/rake_test_loader.rb"  
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby -Ilib:test "/Library/Ruby/Gems/1.8/gems/rake-0.8.3/lib/rake/rake_test_loader.rb"

…yeah, those lines. I hate those lines.

So let’s get rid of them!

Each of those lines is rails trying to run test:unit. RSpec replaces the default rake target by doing this:

task :default => :spec

BUT If you’ve played with rake before, you know that this doesn’t actually replace the default target, it only adds to it. We need to remove the default target then point it at :spec

Turns out that’s not too hard. Put this code (got it from here) at the end of your Rakefile:

Rake::TaskManager.class_eval do
  def remove_task(task_name)
    @tasks.delete(task_name.to_s)
  end
end
 
Rake.application.remove_task("default")
 
task :default => :spec

You’re all set!

I’ve had my fun with ruby.

I wanted to learn ruby, so I wrote myself a blog. Then, I wanted to learn rails, so I migrated it to rails. Then, the spam was too much, so I migrated to Typo. Then, I couldn’t take Typo’s memory footprint, so I moved to Mephisto.

But you know what? Even Mephisto is a pain to deploy, and is still a resource hog. It’s kind of the nature of ruby and rails apps. And what’s the benefit to justify the cost? Aren’t there other more mature, stable, better supported and more flexible blog engines in other languages?

…yes, there are like 50 of them.

So I’ve migrated yet again, this time to Wordpress.

I’m really happy with it, but I did have some cool toys in my rails world that I didn’t want to give up. I can use my own machine as a staging environment to blog changes. I can also deploy with a simple “cap deploy”.

So.

My entire website now lives on github and I use capistrano to deploy it after making edits locally. It looks something like this:

git commit -m "..."
git push
 
cap pull

And to give you an idea of the goodness that is ruby and cap, I also wrote a script to pull the databases on my server down to my staging environment. After all, what’s the point of staging if it uses different data. Using looks something like this:

cap backup
 
rake db:pull db:restore

If you want to see how this is done, check out repository