Collaboration 8

In January of 2012, we at LeanDog were honored to host Jurgen Appelo for his first Management 3.0 course in the US. If you've not read Jurgen's book on "Leading Agile Developers, Developing Agile Leaders", I recommend it. The book is full of good advice and simple techniques for improving the way you manage. Among the items Jurgen shares in his class, I was intrigued by The Seven Levels of Authority and his Delegation Poker game.

Delegation 7

Jurgen's Delegation Poker cards were introduced to several members of the LeanDog family at Codemash and conversation ensued. Within a matter of hours, the phrase "Delegation 7" had become a short-hand reference to the cards and the concepts behind them. Delegation 7 seemed a great tool to help us with some of our own challenges. There were a number of items in the Studio and at LeanDog in general that were failing to get forward motion. Everyone had an opinion, but nobody was taking action. As a self-directed team, we had a clear short-coming; plenty of people were steering and nobody was rowing. The leadership team at LeanDog decided to give Delegation 7 a try. We took on a difficult task; running areas of the business. We set up a simple chart:

Yeah, but…

Who is going to delegate these responsibilities? An individual to assign levels of responsibility wasn't what we needed. We instead needed to agree on our levels of responsibility within each area. So we made a small adjustment to the concept and each of us placed our names on the chart, indicating the level of authority we felt was appropriate given our roles and experience.

This isn't going to work

We sat back and looked at the board. After a couple of seconds somebody announced, "This isn't going to work." They were right. We had conflicts all over the place. Anywhere one person wants to Tell, Sell, or Consult, we can't also have an Agree. And "Barney" sees himself as a decision maker in all aspects of the business, providing nobody else true autonomy.

But we can make it work

We talked through each of the areas and why each of us placed our names in certain columns. After some discussion and adjustments, we came up with a more workable arrangement.

Collaboration 7

This variation on the technique worked for us quite well. Delegation was not the right word; this was Collaboration. When I introduced the concept in our studio, we called it Delegation 7, but explained it as a collaborative exercise. The phrasing and the chart were incongruent with the explanation of the exercise. Thankfully, Angela Harms took a little time and came up with a variation on the board. We renamed it Collaboration 7.

And then there were 8

Jon Stahl made an early suggestion (back in the Delegation 7 days) that we add a Joker Card. The joker is intended to be used when somebody violates the agreements. Say, for example, Robin is a 3 (Consult) and everyone else is a 5 (Advise) or further to the right. Robin makes a decision and Barney refuses to abide by it because it is not the call he would have made. Robin would play the joker card; reminding Barney of his commitment to the group.

We use Collaboration 8 as a regular part of our toolset at LeanDog. From simple tasks to corporate strategy, we use Collaboration 8 as a fast and simple means of identifying who should be involved in the decisions, to create operating agreements, and to make whom is involved in what activities publicly visible.

Roman Numeral Kata

While working on the Roman Numeral Kata, I was bothered by the existence of special pairs in my numerals hash.

class Converter
    NUMERALS = { 50 => "L", 40 => "XL", 10 => "X", 9 => "IX", 5 => "V", 4 => "IV", 1 => "I" }
    def convert(number)
        return NUMERALS[number] if NUMERALS[number]
        to_roman(number) 
    end

    private

    def to_roman(number)
        result = ""
        NUMERALS.each do |value, numeral|
            while number >= value
                result += numeral
                number -= value
            end 
        end
        result
    end
end

Notice the 40, 9, and 4. These aren't unique numerals, rather they are pairs that represent special subtraction rules. Doing this gets my tests to pass and solves the problem, but I wanted to see if I could come up with a way that better represented how roman numerals work.

Looking for inspiration, I asked twitter and google for some help, but everything I found either used this technique or did some magic number substitution (YUCK). So I set out to find my own solution. Notice I am not professing I set out to find a better solution, only my own, alternative solution.

I won't be showing all of the tests as we go along, but the entire solution was test driven with RSpec. You can review the history and see the tests on github.

SCNA 2011 Apprenticeship Panel

This year, at SCNA 2011, I had the honor of moderating a panel on apprenticeship. I was lucky enough to get participation commitments from an impressive list of individuals. I feared I would not be able to get a decent panel together and instead, I had to pare the panel from a list of eleven amazing people down to just six.

I want to thank all of the folks who agreed to participate; Shay Arnett, Ken Auer, David Crosby, Zach Dennis, Justin Ghetland, Corey Haines, Dave Hoover, Micah Martin, Robert Martin, Don Mullen, and Matt Yoho. Your commitment to furthering our profession is inspirational.

Audience Participation

We wanted to make sure we got participation from the audience, but also wanted to keep the discussion moving as quickly as possible. We decided to have the audience tweet questions with the #scnapanel hash tag rather than deal with the logistics of getting microphones to the audience or having to repeat every question asked.

As it turned out, this was a fantastic method. Questions that interested several people were retweeted, pushing them back to the top of the queue and I was able to hunt through the questions looking for common themes. This also allowed us to continue the conversation well beyond the panel. Dave Hoover and Ken Auer took the time to answer questions via twitter later that afternoon.

The Questions

As I mentioned, there were a lot of tweets in a relatively short period of time. We had over 300 tweets on the topic with more than 200 of them coming in during the live session.

There were a few common themes; how to select an apprentice, what makes for a good program, and how to get a program started. I've made the entire apprenticeship panel tweet stream available. The following are a few example questions.

• What are the factors you take into consideration when building your apprenticeship curriculum?
• what is the worst mistake you made as a mentor or in your program ?
• does someone ever stop being an apprentice?
• Any formal milestones in your apprenticeship programs? Complete a project, etc.
• Do you also do apprenticeship with existing employees (developers) that might need more training to reach "the next level"?

Continuing the Conversation

I think apprenticeship is a valuable and important undertaking. If the name "apprentice" does not resonate with you, then call it something else. The assigned label is the least important aspect of growing and nurturing our next generations. I invite you to join the Software Craftsmanship google group and engage in the discussion.

Fighting Entropy

It was 1983 and I was in science class when I first heard the term entropy. I don't recall if we were discussing energy conversion, heat as waste, or some other topic wherein entropy plays a part, but I do recall how profound the concept of entropy seemed to me. The notion that there was a lack of order, a lack of predictability, and a gradual decline into disorder resonated with me deeply.

Entropy is the state of existence

I long attributed the phrase "entropy is the state of existence" to my science teacher. Looking back, I suspect that I either misunderstood him or made it up myself, but in any case, the phrase stuck with me and I use it to this day.

For me, entropy is not a fatalistic notion, rather a reminder that all things need tended.

It requires the application of new energy to keep a system at status quo

Disorder is natural and all systems, left un-tended, eventually fall apart. It requires the application of new energy to keep a system at status quo. Our desire to change nothing in order to keep things as they are is unrequited. We must change in order to stay the same.

Entropy and Process

No matter how well your process works today, I can promise you, left unchecked, it will eventually fail to deliver the results it once did. I believe there to be two primary reasons for this. First is that the process in-deliberately changes over time. Second is that our needs for process change as our project evolves and our team matures.

The process in-deliberately changes over time

How many of you have been on a team with stale stand-ups? The format hasn't changed. The participants haven't changed. And yet the value isn't what it once was. We stick to the process and try to recapture the magic.

How many of you have participated in a process that doesn't seem to make sense anymore? When the team started working together, no one knew the system well and there were lengthy debates over what might be true. The code might be complex or poorly covered. It might not.

Our needs for process change over time

Estimating sessions took forever. So management put a silent estimating process in place. This allowed the team to get through estimating sessions quickly. Six months later, everyone had solid experience with the code and was able to articulate real concerns, but the process didn't allow for it. No worries, the process served them well this far; it must be right.

Inspect and Adapt

As a runner, I train regularly in order to maintain my current level of fitness. I vary my training to ensure balance. It requires effort simply to stay the same. And if I want to improve, I must assess my current status, evaluate where improvement is needed, and adjust my training accordingly. If I need to build strength, I work in more hills. If I need to improve my speed, I focus on track work. I monitor my progress to ensure I'm getting the desired results. Pain, fatigue, faster times, improved strength, and no perceivable change are all valuable pieces of information that help me determine if what I am doing is working and what other adjustments need to be made. Invariably, when I stop paying attention, I end up with an injury.

Enter the Retrospective

Retrospectives are the one practice I feel are an absolute must for teams; agile or otherwise. Remember, entropy is the state of existence. It requires the application of new energy to keep a system at status quo. A regular dialogue about what is working, what is not, and what we plan to change is paramount to simple survival. Without it, entropy wins.

Estimating our Work

I've been thinking quite a bit about estimations and our general obsession with getting them "right". After all, we need to know when the project will be done. And we need accuracy. Knowing the entire project will be done before the end of the third quarter isn't good enough. We need to know that the project will be done this month or this week or perhaps even on this specific day.

Through consistency, we attempt to achieve predictability.

I've watched teams put a great deal of effort into improving their estimates. I've seen teams compare stories from this sprint to stories from prior sprints to try to maintain consistency. I've seen teams use a reference story for a single point. When estimating, they look at the reference story and then estimate all others compared to it. These seem like decent practices. The goal of these practices is consistency. Through consistency, we attempt to achieve predictability.

But one thing I've never understood is the notion of estimates versus actuals. Here we look at the original estimate for a story and we then estimate again once the story is complete. The idea here is that the estimate upon completion is an actual. This provides us a learning opportunity whereby we can improve our estimates going forward. This, to me, is a flawed approach. To illustrate my point, let's look at estimations from a slightly different angle.

Estimating Sudoku