Fire drill, followed by "Why isn't this done?"

The Problem

Interruptions in your work are very costly. They usually come in the form of an expedited request to satisfy the craving of some stakeholder. If the craving is local to that stakeholder, there is a significant cost to the overall system when the interruption is serviced.

We call these interruptions by many names. Here are a few you probably recognize:

• Fire drill
• Context switch
• Shoulder tap
• Urgent request
• Pet project of the CxO

Once the fire drill is over, the stakeholder offers up this question, "Where is my top priority feature?"

"You mean the one we had to put on hold to put our your fire?" you reply.

You've been there before, I know you have. Here is what I'm currently trying.

The Solution

Make the interruption as visible as possible on your information radiator and show how it prevented other work in progress from getting your attention.

I use Trello currently, and I've started adding the image below as a custom sticker to Trello cards that are deemed "fire drills."

It makes the card on the Trello board really come to life! Here is a static image of a card with the sticker.

At the end of your iterations, you can quickly see which items were fire drills. If you track metrics, such as, "How many fire drills did we have this week?" or "How many items were compromised due to fire drills this week?" you begin to write a story to stakeholders about the cost of their expedited request.

Exhibit A

We just experienced one such fire drill on one of our teams. The stakeholder imposed a request on the team and the team serviced the request. When the fire drill was over, the team lead sent this response:

Dear Stakeholder, 

We had to drop everything we were working on yesterday for your fire drill issue and missed our internal code delivery deadline for your other priorities. Because we follow two-week sprints and release cycles, this means we have to delay the release your prior "top priority" feature until two weeks later. 

Ever your humble servant, 

The Team Lead

Tell me when my cukes are done

So your test suite takes a few minutes to run. That is valuable time to go check Twitter. Of course, you don't want to get sucked too far into the Twitterverse and want to only read tweets while rake is running your suite.

Let iTerm tell you when your tests are done! iTerm will let you define a trigger and then perform an action when your trigger is set off.

Let's assume that rake will spit out some text when your cukes are all done:

Took 65.38276 seconds

Convert that to a regular expression and use it as your iTerm trigger:

^Took \d+.\d+ seconds

Now, let's define the trigger. When your iTerm matches that regular expression, iTerm will execute a the /usr/bin/say command on the Mac to convert some text to speech.

Open your iTerm preferences.

Click the "Edit" button in the Triggers section and use your regular expression to define the trigger:

Now, when your iTerm encounters text like "Took 65.1234 seconds" your Mac will say "Your tests are done."

JBoss Command-line Deploy/Undeploy

I was creating a Chef cookbook to deploy a .war file to JBoss AS 7.1. One iteration of refactoring had me using the command-line tools provided with JBoss to do the deploy/undeploy. Ultimately, I didn't use this method, but wanted to document it in case I change my mind later.

I am using Bryan Berry's JBoss cookbook to configure my base JBoss install, which installs JBoss to /usr/local/jboss. I am also using the full-ha profile for the standalone JBoss configuration.

Variables

• CONTROLLER: the IP address bound to JBoss. I used Vagrant in this example, so the IP is an arbitrary static IP address that I chose, e.g. 33.33.33.11
• USER: the user to connect to the JBoss controller (you set this up with the add-user.sh script in JBOSS_HOME/bin)
• PASSWORD: the password to connect to the JBoss controller with

Deploy

The jboss-cli.sh script allows you to run in non-interactive mode. You must pass the JBoss commands along the command line as an argument, but if you have spaces in your command, then you have to put your commands in a file and use the --file switch to indicate the file containing your commands.

Here is a sample file, e.g. /tmp/jboss-deploy-command (should be one command per line):

/deployment=MyWebApp.war:add(runtime-name="MyWebApp.war",content=[{"path"=>"/path/to/MyWebApp.war","archive"=>false}],enabled=true)

In my example, I'm deploying an expanded archive as a directory, so the "archive" => false attribute must be present.

The command to execute for deploying MyWebApp.war is:

$ /usr/local/jboss/default/bin/jboss-cli.sh --controller=${CONTROLLER}:9999 --connect --user=${USER} --password=${PASSWORD} --file=/tmp/jboss-deploy-command

If all goes well, you will see this output:

{"outcome" => "success"}

Undeploy

Removing the web app is simple:

$ /usr/local/jboss/default/bin/jboss-cli.sh --controller=${CONTROLLER}:9999 --connect --user=${USER} --password=${PASSWORD} --command=/deployment=MyWebApp.war:remove

See also: https://community.jboss.org/message/630853.

Why I Love Go

I was just reflecting a bit on why I like Go (from ThoughtWorks Studios). I had previously been using Jenkins (which I love), and while I still love Jenkins and would happily use it again, here are some of the reasons why Go wins in my book for trying to do continuous delivery.

Recently, Dan Gilmer spoke at ChefConf about how Ancestry.com uses Go and Chef for continuous delivery. Prior to leaving Ancestry.com, I helped pioneer the early use of Go and Chef as an Agile coach for the development teams. Here is Dan's talk:

What I Love About Go

Workflow visualization. I love the idea of separating build pipelines from deploy pipelines, each with their mini-workflows. When I was coaching teams at Ancestry, I always taught them to identify their own business process and then document that as a pipeline and value stream map. The "pipeline" entity in Go is powerful for communicating to developers and product owners the business process they are using. I love the transparency. The caveat though, is that you have to mature as a team to find out the appropriate boundary of what belongs in your build scripts (ant, maven, etc.) versus the tasks of your pipeline stages.

Pipeline groups. I don't use these at Premier Fitness Camp because I'm using the community edition. However, at Ancestry, I loved being able to group pipelines per team and put security on them. Plus, in harmony with my statements above, the group of pipelines represents a boundary around all the business processes a team must use to release its software.

Environments. We didn't mature at Ancestry to my vision of using Environments before I left, but I did really like how the Environments view let you see what version was deployed via a given pipeline. I thought that was very powerful. With the use of configuration management (like Chef) knowledge about environment configuration, including application version, may not be as useful in Go. However, go makes it very transparent which version is in an environment. As long as you model your pipeline label template correctly, and put the right agents in the right place, this could be cool.

If I had the enterprise edition, plus a few remote agents, I'd probably use the Environments view a lot. Currently, I have modeled my deploy pipeline so that it triggers Chef to do the deployment on my remote servers. The pipeline version number matches the produced artifact number and Chef fetches the artifact from Go, so I know from looking at my pipeline group what version is out on a server, even without the Environments view.

Replay a version in the past or replay a failed stage. I love the ability to replay a failed stage in the middle of a pipeline without starting over. I know you can do this with Jenkins because you can just play a job. With Jenkins though, I get the feeling that I'm starting something from scratch rather than picking up the context of the overall pipeline.

What I Miss from Jenkins

Code coverage charts. Jenkins had a plugin for visualizing historical code coverage. In Go, I have to produce these on my own (since a plugin community/capability exists yet) and embed them in as an artifact and a custom tab.

Unit test trending charts. Same as code coverage charts above.

Maturing from Done to Ready

This isn't a new topic. It's been talked about for a few years now. I had a team lead ask me this week about maturing from getting your stories "done done" to getting them "ready." The source of his question was from an team assessment/test that a team completes each sprint. The test gives the team retrospective talking points that will allow them to Scrum the Scrum (as Sutherland would say).

On our assessment we ask this question (the questioned are listed in order of maturity, most mature being listed last):


What are the team's standards for assessing "done" (completeness)?

• Team has no Definition of Done
• Team has a Definition of Done that doesn't include testing
• Team has a Definition of Done which produces potentially shippable software
• Definition of Done is augmented for each story with acceptance criteria
• Team has a Definition of Ready

This team lead's was confused that "ready" was most mature. I explained to him that the intent behind this question is really to gauge a team's ability to flow value. Immature teams don't finish stories within a sprint, i.e. not "DONE." Once teams learn to get stories done within a sprint they start to flow value more consistently. When a team reaches that point, the next level is to make sure that every story that is planned for a sprint is adequately prepared so that the team has an even better chance to complete that story, and potentially flow more value.

This article by Sutherland and Jakobsen is a must read (and Jakobsen presented it at Agile 2009): Scrum and CMMI: Going from Good to Great.

Ready stories:

• Have been discussed by the product owner and team (maybe there are some wireframes, or mockups as part of the conversation)
• Are clear to the team as to what is involved
• Have clear acceptance criteria (maybe more than 1) to signal to the team when they have met the expectation of the product owner
• Are estimated (estimation can only really be done when you have acceptance criteria)

By the time a team and the product owner scrub and groom the backlog, the stories should match the above description to consider them ready. If a team only plans a sprint of ready stories then they are less likely to create waste in the sprint going back and forth getting clarification from the product owner.

Windows Registry-based Idempotence Check with Chef

Problem

You are using Chef with Windows (that is a problem in itself!) and are using powershell to install programs using a specific user account with winrm.

How do you ensure idempotence?

Solution

There are many possibilities, like using the windows cookbook from Opscode, but that doesn't handle installing and package as a specific user.

Here is a hack that will use Ruby to check the Windows registry for an installed product and if found, prevent the powershell resource block from executing.

Add this registry_helper.rb to your cookbook's libraries directory:


require 'win32/registry'


module RegistryHelper
  INSTALLER_PRODUCTS = 'Installer\Products'
  def RegistryHelper.is_in_classes_root?(path, product_name)
    found = false
    Win32::Registry::HKEY_CLASSES_ROOT.open(path) do |reg|
      reg.each_key do |key|
        k = reg.open(key)
        if k['ProductName'] =~ /#{Regexp.quote(product_name)}/
          found = true
          break
        end
      end
    end
    return found
  end
end


In your recipe, include this library, and add a not_if block to the powershell resource statement:


class Chef::Recipe
  include RegistryHelper
end



# The name to search for in the registry for idempotence
registry_name = 'Java(TM) SE Development Kit 6 Update 26'

powershell "Install-jdk_6u26" do
  ...
  # ensure idempotence
  not_if do
    RegistryHelper.is_in_classes_root?(RegistryHelper::INSTALLER_PRODUCTS, registry_name)
    end
end

Measuring Partial Points

I measure Scrum teams using a spreadsheet inspired by Scott Downey's RoboScrum. One key indicator I watch for is partial work. To illustrate how this indicator is used, I will tell a story.

Sound Familiar?

A UI team of 6 members begins a sprint hoping to finish 35 story points worth of stories. They swarm effectively and near the end of their 2 week sprint, the team is so close to completing all of their stories. However, the team just knows two "in progress" stories are not going to get done.

The team shows up at the Sprint Review meeting bummed that they didn't get all their planned stories done. "I don't understand why we don't get credit for those stories, we were almost done!" the team complains to their ScrumMaster.

"Remember," the ScrumMaster reminds his team, "you do get credit!"

The ScrumMaster chuckles to himself as he reads the contorted faces of his team. "Velocity is the number we use to show how much we can get completely done. This is an important measurement for our product owner."

"But what about that 8 point story that only has a small amount of testing left? You mean we aren't going to get credit in our velocity for what we completed in that story? We probably only have 1 point left!"

"I understand," the ScrumMaster accepts, "but did we get the story done? No."

The ScrumMaster explains that credit for this partially done story is an important indicator that that team can use in future planning. Together with their velocity, the team can use partial points to determine their total capacity during the sprint as a goal for future sprints.

Therefore, capacity is equal to a team's velocity plus the sum of partial points.

Capacity = Velocity + Partial Points

Why Measure Partial Points?

Not only do partial points allow us to figure out a team's capacity, in story points, but they also help us measure a team's focus factor. Scott Downey described focus factor in this way:

I, as a member of Leadership and not a member of a Scrum Delivery Team 

Need a way to measure how much of each Team's bandwidth results in deployable product, in a cross-team comparable way, 

So that I can actively help sub-optimized teams intelligently allocate resources.

The formula for focus factor is:

Focus Factor = Velocity ÷ Capacity

In summary, focus factor tells how close a team was to finishing 100% of their sprint. Teams that get around 80% in this category make me happy. Why 80%? Consider this statement by W. Edwards Deming:

Attempts to force non-deterministic systems to operate at greater than 80% efficiency will cause short bursts of stabilization followed by extreme periods of destructive and unpredictable variations from that goal.

Besides, a team with a repeated focus factor of 100% tells me they probably need to take a sprint and stretch to new heights. A team consistently less than 80% may be taking on too much, or putting too many stories into progress at once.

How do I Record Partial Points?

Here is a sample from my metrics spreadsheet:

The "Actuals" section contains the results from each sprint (one sprint per row). The "Partial Done" column in the "Actuals" section contains the sum of all partial points from that sprint. This value of partial points automatically feeds into my Summary view to show the team's capacity (velocity + partial) and the team's focus factor.

How do I Determine Partial Points?

Recording them is the easy part! Getting a team to quantify partial points requires more work. During a sprint review, I jump to stories that are not accepted as done and ask the team these questions:

1. What is left to be done with this story?
2. What type of work is required to get the remainder done? Database work? Nagging? Test case verification?
3. What work was completed?
4. What type of work was the completed work? Coding? Automated tests? Design? Nagging?
5. Compared to our reference stories (you have them right?), how would the team estimate the work they completed?
6. Compared to our reference stories, how would the team estimate the remaining work?

Question #5 tells you the number of partial points to capture for each story. The sum of these partial points is what is recorded above in the "Actuals" section.