Archive for the ‘Uncategorized’ Category

Seattle Lean Camp

Monday, July 13th, 2015

This summer I’ve been involved with two conferences about Agile and Lean. One was Agile2011, a huge, five-day conference in Salt Lake City. The other was Seattle Lean Camp, a small two-day event at the Center for Urban Horticulture in Seattle (sponsored by Getty Images, Nordstrom Innovation Lab, Modus Cooperandi, and University of Washington Bothell).

At Agile2011, I presented at two sessions, “Intro to Test-Driven Development and Pair Programming Dojo” and “Agile Isn’t Enough”; they went well and I’ll write more about them later.

For Seattle Lean Camp, I was both the Open Space Facilitator and a conference co-creator, along with Person Kanban author, Jim Benson.

Both conferences were aimed at professionals in software development and information management. But while Agile 2011 used a traditional conference structure, the lean camp used Open Space Technology, a structure we hoped would enable participants to experience some Agile and Lean techniques as well as studying and discussing them.

How did this go? Here are a few of my observations about Lean Camp:

  • Jim and I were astonished by the turnout. Not just by the numbers (130 people), but by the breadth and diversity of the attendees. We had leaders in the field, newcomers, and participants who flew in all the way from D.C. and L.A.

  • About half of our participants were people who had already worked with Agile/Lean and who wanted to be involved in networking and spreading the word. The other half had heard about it but had never seen it in action.

  • The Open Space Technology conference model did what it was supposed to do: Enabled attendees to focus on the topics they wanted to discuss. Of course, there were surprises. Owen Harrison, who’s credited with inventing the Open Space conference, said that he’s still surprised every time he leads one.

  • I’ve been a participant in many Open Space events, but it was different being a facilitator. Even weird. It was fascinating to watch as the “marketplace” filled up with sessions. My job was simple to “hold the space” so attendees could make it all happen.

  • Looking back on the conference, my sense was that we could have prepared people better for taking advantage of Open Space. For some, it was an adjustment to realize that the agenda would be developed n a participatory fashion, on the spot.

  • One great surprise of the conference was lunch, and the lunch system. It was really different, and worked surprisingly well. We had Seattle lunch trucks come each day for three hours. To prevent lines and waiting, Jim used a Kanban system in which there were distributed lunchtimes and people assigned themselves to a lunch session.

  • At the end of the first day we did a quick feedback session that we applied to the next day. It included Virginia Satir’s sequence of appreciations, hopes and wishes, and complaints with recommendations. We made a starfish diagram for the next day, with lists of what we should stop, start, do less of, do more of, or keep just the same way.

You can get a sense of the conference from the website, and by taking a look at the proceedings. Each session used easels with flipcharts and sticky notes to create their own notes. We later photographed the flipcharts from each session and uploaded the pictures to Flickr — instant proceedings! You’re more than welcome to take a look.

Open Space at NWEA

Thursday, November 15th, 2012

I spent the afternoon with NWEA. They are a portland company that builds adaptive tests for children in public schools. They ran an open space conference where they had their whole software engineering team (~70 people) from 1p – 5p.

At high level, we came together in a circle, then people announced session topics that they wanted to lead (questions, ideas, …), and then we broke into small groups and talked about their work. At the end of the day, we came back together to reflect on what had happened.

I wanted to convey the outcomes not in my words, but theirs. So I wrote down as much as I could of the discussion at the end of the day. People seemed energized, surprised, and looking forward to what happens next.

What Happened?

[I was writing quickly, so any typos are my fault]

“A lot of venting got out that was necessary”

“I heard a theme across several sessions – someone would say, ‘this ought to be taken care of’ … and then over the course of the session that person figured out that they are the person that needs to do it [because no one else will]”

“I realized we are using the same term to mean very different things … [talking about these ideas brought] clarity”

“We are now more focused on achieving common vision + goals”

“It’s remarkable how much knowledge we have as a team …”

“The amount of visibility that came out of today sheds light on the lack of visibility we have normally … and I thought, why didn’t I already know that?”

“I heard, as a developer, not only should I be designing for efficiency, but I should also design for marketing, training, and releasing … I hadn’t ever thought about that”

“There is a great desire to fix things … let’s just get together + fix it”

“Environments isn’t ‘that team’s’ job … next action is a cross functional team w/ senior leader so that we an break through false assumptions + make progress … to be better than the sum of our parts”

“We’re moving away from ‘this is how we always do it’ mentality”

“From my angle, this is amazing … this is really in our hands, we can make this happen … it makes me want to cry” – the executive sponsor

So what?

What I saw as an outsider is that in a 1/2 day of conversation, they achieved a tremendous amount of understanding across teams, functions and silos. They built relationships. And they recognized problems, opportunities, and successes.

How much does your company get done in a 1/2 day?

What if your company spent 1 day every quarter breaking down silos, and collectively solving problems and building relationships using Open Space Technology ?

How do you start a Startup Weekend company?

Wednesday, May 4th, 2011

My friend Jennifer Cabala asked me a while ago what tools a fledgling startup could use that Startup Weekend could help provide. I was at a loss, because most of my toolset is free / opensource.

But it turns out that there are a LOT of things that I do when I start a Startup Weekend company. I watched myself do them over Madrona Startup Weekend and now in the days afterward. Seems like maybe that is a list worth sharing.

So, in roughly chronological order :

During the weekend:

It’s a lot of steps but shouldn’t take you too long once you’ve done it a couple times. This whole list took me 1 1/2 hours on Saturday morning before I came in.

  • Get a list of everyone’s email

  • Decide on a name (it really doesn’t matter so much, just pick something that has a .com available)

  • Get a dropbox folder and share it
  • Buy the .com
  • Sign up for twitter
    • put twitter user/pass in [dropbox folder]/accounts/twitter.txt


      (we had a rails project)
  • create a heroku project
    • add custom domain plugin
    • add zerigo addin (dns config)

  • move nameservers to heroku

  • create a google apps account for the domain name
  • get a google analytics account, add it to the layout of your rails app

After the Weekend

Have the “morning after” conversation

* who has interest in going on?
* what availability do people have?
* what’s the goal? exit? become funded? bootstrap?
* how do people get compensated for their time?
* …

Assuming people want to continue, there’s more stuff to do :

  • Create a google group [mydomain]@googlegroups.com
  • Create a google docs folder that’s shared with the google group
  • Give everyone on the team an e-mail on google apps
    • I set it up to forward to my main e-mail, and my main email to be able to send as [email protected], I give it a custom sig too
  • Create a Tracker project for tactical stuff
  • Create a Maptini or CardMapping site for more long range planning (these are both my startups, so I’m biased, but please use something that let’s you see the big picture)

Your mileage may vary. And while these are all great tools, they’re just tools. They support your people – it’s the people that are important.

Sharing Lean & Agile with Startup Weekend…

Saturday, October 2nd, 2010

I am fortunate enough to be hanging out with Startup Weekend Organizers and Startup Digest Curators from around the world this weekend. It’s called the SO Summit, and there’s a lot of energy in the room!

I just gave a talk on Lean & Agile and what they might look like at a startup weekend.

We did a couple mind maps of what makes a startup team successful or not. Feel free to add to them!

Here’s a link to the presentation.

Self Healing Systems

Wednesday, September 8th, 2010

My 5 roommates and I spent 4 1/2 years coming up with a system for keeping our house clean that works. And we did! More importantly, we think we know how it works.

Our chore chart is a self healing system, and it shares characteristics with other self healing systems. It:

  • uses simple rules
  • expects & tolerates faults
  • visualizes work
  • encourages forgiveness
  • discourages heroes
  • is gameable

Perhaps the same traits that are keeping my house clean can ensure you deliver value to your customers.

Watch a lightning talk I gave about this system at SeaSPIN earlier this evening :

Making Refactoring Sexy…

Friday, July 23rd, 2010

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…

How do YOU handle conflict?

Thursday, July 15th, 2010

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.

What Shape Is Your Backlog?

Wednesday, February 10th, 2010

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

Seattle Lean Coffee

Sunday, January 24th, 2010

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?

Agile Grading

Saturday, December 12th, 2009

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 :
    IMG_0852
    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?