How not to paint a fence

This summer I spent a weekend staining the fence in my back yard with the kind help of my mother and father. Manual labor frees the mind to think and I started thinking about the application of the Theory of Constraints and Lean to the task of painting a fence...yes, I was in the sun too long.

The Work

My fence is a typical 4 ft cedar fence. It has 4x4 posts every 6 to 8 feet. Connecting the posts are a pair of 2x4s. One 6 inches above the ground the other is level with the post. The fencing is made of cedar planks that are drilled into the spanning 2x4s with a couple inch gap between each plank.
There are two types of work when painting a fence. One type is the large brush (or painting pad) work to cover the the large wood planks. The second type is the trim work. The trim work on the outside of the fence is painless. A couple inches between each plank and the edges of each plank. The inside of the fence is another story. The trim work inside the fence includes the two 2x4s that span between the posts and the sections of the plank above and below those spanners.

Estimating

Before we started, I decided to time how long it took us to do the length of the outside of one side of the fence. I would use this sample duration to get a rough estimate on how long it would take to completed the entire fence. We’ll see how that worked out later...

The Flow

My father and I both started by worked on the large plank work. It took 30-45 minutes for my father and I to finish painting the large planks of the first side of the fence, however my poor mother was still finishing the trim work from the first 5 foot section. My Theory of Constraints brain kicked in and I started to think about the 5 Focusing Steps.

The Theory of Constraints (ToC) defines the 5 Focusing Steps:

1. Identify the constraint 
2. Exploit the constraint 
3. Subordinate everything else to the constraint 
4. Elevate the constraint 
5. Repeat 

It was obvious the trim work was the constraint in our system (step 1). When ToC talks about “Exploiting the constraint” it means to squeeze all the capacity out of the constraint that you can. Don’t allow the constraint to do anything activity that isn’t the constrained activity. In this case my mom was fully exploited. She wasn’t being distracted by the children or asked to grab drinks. She was just painting trim. My mom was fully exploited...from a ToC standpoint.

What we should have done to subordinate everything else to trim work (step 3) is to have the large brush work only paint area where the trim work was done, but I knew it would be difficult to convince my dad. Having everyone do trim work wouldn’t “feel” like we were getting much done. I chose a compromise. I had a quick talk with my father to develop a new plan. He would continue to use the painting pad, but he should do as much of the trim work as possible. I would switch to a 2” brush and help my mother with the trim work.

The Big Backside

The outside of a fence is much easier to paint since it is mainly large panels. The structure inside the fence contains the top and bottom 2x4s that span between the posts. This side of the fence requires more trim work. The top, bottom and side of each of the 2x4s plus the sections above and below the spanners that aren’t large enough to get with the large paint pad.

While working on the outside of fence, my father painted the front of the panel, the top and each of the half inch sides. On the backside of the fence, he was able to get the top and middle sections, but not the bottom section. He also did the spanners, but knew the “trimmers” would finish up the work.

This division of labor caused a few problems:

• Buildup of Work in Progress (WIP) 
• Invalid estimates based on the duration of unfinished work 
• Quality 

Splitting the task into specializations of large brush work and trimming we created a large amount of work in progress (WIP). Nothing was “done”. Each section of fence required somebody to go back and “rework” the unfinished plank and trim.

We could visualize how much work was left, but we needed to calculate the duration. We need to know that we had enough daylight to complete the work. Basing our duration estimates on how long it took us to partially complete a fixed length of fence didn’t give me much confidence.

The final issue that was created by the division of labor was a lack of quality focus. Since my dad knew that I would be following him to do the detail trim work, he wasn’t too concerned about completing each plank. He was concerned about applying paint to the fence planks as fast as possible.

While I was doing the large brush work, I had the same motivation. Getting the largest amount of square footage covered with paint meant the job was closer to being done. However, the job’s duration wasn’t strictly a function of square footage. It was a function of the duration to complete the trim work plus the duration to complete the large brush work.

Ultimately we completed painting the fence. I would like to say that we had enough daylight left on Sunday to enjoy an ice cold lemonade on the deck and enjoy our work. I can’t. The sun was setting and we rushed to get everything done.

Next Time...

Next time I will start with a quality focus and limit the work in progress be removing the division of labor. We will have a two person team working each side of a section of fence. Both the trim and large brush work will be completed before moving to the next section. This simple change will allow us to estimate the remaining duration, reduce rework and improve quality.

Continuous Feedback

The Agile Manifesto states that we value “Individuals and interactions over processes and tools”; however we rarely discuss methods to improve the individuals on the team or their inter-personal soft skills. We need more practices that help develop the people on the team to increase the performance of the team. Improve the people and the process will take care if itself. For this reason, I want to introduce a practice I named “Continuous Feedback”.

Continuous Feedback is a practice where the team provides praise and criticisms to other team members to allow them to understand how their performance or behavior is being perceived by other members of the team.

Differentiation
The idea is based on Jack Welch’s concept of “Differentiation”. His concept is to split the organization into 3 segments: the top 20%, the middle 70% and the bottom 10%.

The top 20% of the workforce are the stars of your organization. Lavish them with rewards and bonuses. They are smart, they get things done and they are your leaders. Reward, challenge and develop them or else someone else will!

The middle 70% will require the most attention. Do not diminish the importance of the middle 70%. They are the heart and soul of your organization. The top performers in this segment will need to be developed to move into the top 20%. The people on the lower end of the 70% will need to know where they stand. People react differently when challenged. Some will “step up” others will “step down”. Either way, it is each person’s responsibility to make those decisions based on honest feedback and by knowing exactly where they stand.

Finally, cut the bottom 10% out. By cutting out, I’m not talking about firing people unexpectedly. Let these people know where they stand. By knowing they are in the bottom 10% they may leave on there own. Nobody like to be were they are not wanted. Inversely, they might know where they stand and by understanding exactly where they stand they may be able to move into the 70% or higher!

I know the idea of eliminating the bottom 10% sounds harsh, but most companies/teams never purge the weakest performers and this builds resentment within the other team members.

We all know who these people are and we never provide feedback to let them know where they stand. It’s easier to avoid the situation than to confront them. Nobody wants to be “mean”. However, when layoffs happen they are surprised to find out they are first to be let go. Isn’t it fairer to let the weak performers know exactly where they stand? If you didn’t provide that feedback, aren’t you part of reason they were let go?

Over time, cutting the bottom 10% becomes extremely difficult. Think about it. You can probably think of a few people on your team or in your department you wouldn’t mind if they were “released”. Now image if you had to go through a couple more rounds of cuts. The bottom 10% quickly becomes very qualified people! Your middle 70% doesn’t consist of people “hiding out” in the organization, waiting to collect a pension, those people are long gone. Your organization’s middle 70% are the best people in the industry!

The Game
At the end of every iteration we hold a Retrospective meeting we, as a team, we discuss what went well, what we could improve on and how we could make the process better. As a part of this meeting, each member of the team must select the people who they believe to be in the bottom 10%. On our team 10% is one person. We do not publicly discuss why they were chosen. But they are encouraged to meet with the person to get feedback during the next iteration. After the exchange of the bottom 10%, each person must select the top 20% and during the meeting explain why they picked them as a top performer.

We publicly select the top 20% and the bottom 10%, and publicly state why top performers are in the top 20%. We allow each member to privately receive feedback from members so they can improve and know where they stand within the team. Giving and receiving constructive criticism are important soft skills that now get practiced regularly.

My Windows (with git) RVM

I was disappointed to learn that RVM (Ruby Version Manager) doesn't work on Windows, however I wasn't surprised. Windows and Ruby don't always play well with each other.

I'm also a fan of Homebrew on my Mac. Homebrew is a command line package manager that downloads applications and creates symlinks so they are always on your path.

I hate working with Windows environment variable since they don't always reload without logging off and back in again.

For all of these reasons I started thinking about how I could configure my laptop to use multiple versions of Ruby without hacking my PATH environment variable.

My solution was to create a C:\Ruby directory and initialized a git repository within that directory.

I downloaded the 1.9.1 7-Zip package from rubyinstaller.org and extracted it into C:\Ruby. Then I added/committed all the files to a branch named 'v191'.

Finally I updated my PATH to include the C:\Ruby\bin directory.

To install a different version of Ruby I created a new branch named "v192", delete all the files and committed the deletion of the files. Here are the commands:


git checkout -b v192


rm -rf *


git add . -u && git commit -m "Cleared directory for next version"

After I have a clean C:\Ruby directory, I extract the new version to C:\Ruby and add/commit them to the git repository.

After installing I can do a git checkout {branchname} to switch my version of Ruby.

Migrating the blog

I don't know if any reads this anymore, but I am moving my blog from http://blogs.giffordconsulting.com/ to http://blog.giffordconsulting.com. Hopefully your reader didn't pick up all these posts as "new". They are not "new". They are, in fact, very, very, very old.

I had lofty aspirations when I started blogging back in 2005: 

1. I would blog frequent
2. I would develop a community of bloggers under the giffordconsulting.com domain.
3. I would contribute to the SubText blogging software project

I didn't do any of those things...I did join Twitter!

The new blog is hosted in the cloud:

1. I don't have to pay anything
2. Upgrade or fix software bugs
3. Worry about bandwidth when I get on Hacker News (Is that another lofty goal?)

Testing Carriage Returns in FitNesse

FitNesse doesn't allow carriage returns in test fixture table. Normally, I replace carriage returns with a comma (or some other sentinel value) and pass it back to FitNesse. I noticed a posting on the FitNesse email group that recommended defining a variable and then using the variable in the table.

An Example:

!define multiLineAddress {Gifford Consulting
Attn: Tim Gifford
123 Main Street
Des Moines, IA 50266}

!|Check Address|
|Address|
|${multiLineAddress}|

Microsoft OPEN.NET

Late last week we learned that Microsoft is de-funding the Iron projects (IronRuby, IronPython). Many have suggested that the community should take over the projects, but without access to the DLR, CLR and the compilers success would be limited.

However if Microsoft opened up the DLR, CLR and compilers for what I'm going to call "Open .NET", we in the community could make some interesting things happen on .NET.

I know it sounds crazy to open source the .NET platform, but I don't understand what competitive advantage Microsoft maintain by keeping it closed.

I want to mention a couple advantages they would gain by opening it up.

Allowing the community to create libraries and offer bug patches to the CLR, DLR and compiler we (the community) would feel involvement in the platform. This involvement would translate to more community created libraries and solutions.

Microsoft wouldn't have to create tools and libraries that already exist (ala MsTest) and focus their efforts on expanding the platform.

I'm not proposing that all products and innovation that is created by Microsoft shall be Open. They can build new technology within and around the open platform and release those changes to the community core projects after the product announcements.

Create native extensions for Windows that increased performance and scalability. Create products that only run on IIS or SharePoint. Microsoft's current "enterprise" customers would continue to use the proprietary and supported versions of the compilers and runtime.

Without an "Open.NET" Platform, projects like IronRuby and IronPython are not feasible outside of Microsoft. This innovation while secondary to Microsoft's corporate strategy is important to many of us in the community.

Scheduled Restart

I haven't been blogging for a while and have missed it. Twitter allows for quick quips and lunch/bar conversations allow for a deep introspection but I've been missing a venue to formalize my thoughts and to improve my writing ability.

Topics I will cover:

• Lean Software Development
• Test Driven Development
• Automated Acceptance Testing
• Technology Reviews
• Book Reviews
• Experience Reports
• ...and random posts when I need more that 140 characters.