One Man’s Walk in work

I’ve been gone from the M$ stack for quite a while – 2006 was the last time I was in .Net land. But recently, I’ve come back to it through one of my clients, and I have to say, I’ve been pleasantly surprised.

Between lambda expressions, closures, and extension methods, C# is looking a whole lot like Ruby these days. And with Resharper, working with Visual Studio feels a whole lot like using IntelliJ.

But that’s where things get weird.

The client will buy Resharper licenses for any developers that want them, but I’m having a heck of a time showing people why Resharper is cool…

Why Resharper is Cool

Resharper is plugin for Visual Studio that adds refactoring support (among other things). The guys that wrote it also wrote IntelliJ the Java IDE that changed the way the Java world writes code and raised the bar for Java IDEs..

I learned how to refactor by pairing with people like Dan North, Matt Foemmel, and Charles Lowell and a bunch of other amazing ThoughtWorkers. We used IntelliJ. Every other week when they released a new version, we’d all pull it and as we wrote code, we’d find faster ways to do things and share them. Our language even evolved. We started talking to each other about inlining that variable, extracting that method, introducing a a field for that, etc. We started thinking and talking at the level not of individual code changes, but at the level where you’re stacking 5 or 6 refactorings on top of each other.

And that’s really what Refactoring is – a domain specific language for writing code.

Using this DSL, in a tool like Resharper, my personal coding speed is easily 2 times if not 3 or 4 times what it would be in the same language without it. And over and above that, even without it (say in Ruby) I still think in terms of chunks of work, refactorings.

So what’s the problem?

Despite the awesomeness of Resharper, despite pairing with me as I use refactorings to blaze through things that would have taken mounds of time otherwise, developers here fail to be impressed.

I’m not sure why.

Perhaps, the problem is that I haven’t tried teaching them the language, the Refactoring DSL. Every language has a barrier to entry that is greater than zero. And Refactoring is no exception.

Perhaps a series of brown bags on Refactoring / Resharper is the answer.

Perhaps I should think about how I might be able to use Where are your keys to teach them the DSL.

If you’ve found a way to teach people the love of refactoring, I’d love to hear it…

I did a 5-minute lightning talk tonight at QASIG about Conflict strategies. I had a lot of fun with it.

I figured in 5-minutes I had time to introduce the audience to a simple model of how people handle conflict comprised of 5 strategies, hopefully making each strategy sticky with a short story about when it made sense to use.

This model is the Thomas Kilmann Conflict Mode Instrument . The point of having such a model is to make the implicit explicit. To take the responses to conflict that we learned as infants and young children and to give us a vocabulary for looking at how we react to situations of conflict and an opportunity to choose a new path.
——
I first learned about this model while doing an intensive mediation training course at Seattle’s Dispute Resolution Center. It was an excellent course, and I’ve since used this model often when trying understand what’s going on both in myself and in others engaged in a dispute.

It’s quite handy.

Here’s a link to my slides – How do you handle conflict.pdf.

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!