Tuesday, July 31, 2012

Lead Time vs Cycle Time

1. Lead Time and Cycle Time don't have the same unit although their names are both "Time." Lead Time is measured by elapsed time (minutes, hours, etc.), whereas Cycle Time is measured by the amount of time per unit (minutes/customer, hours/part, etc.). It does not make any sense to add one to, or subtract one from, another.
2. Cycle Time is actually a measure of Throughput (units per period of time), which is the reciprocal of Cycle Time. This relationship is analogous to Takt Time (amount of time per unit), which is the reciprocal of customer demand rate (units per period of time). Note that by definition, Cycle Time (or Takt Time) is an average value.
3. Lead Time and Cycle Time are related by Work-in-progress (WIP) in the entire process, in a relationship described by the Little's Law:
Lead Time = Cycle Time * WIP
Lead Time = WIP/Throughput
4. The Cycle Time above must be the process cycle time, which is determined by the bottleneck. Cycle Times of individual steps cannot be used alone to calculate the process Lead Time without knowing the WIP.

Wednesday, July 25, 2012


  • Simple config management
  • No server
  • No daemons
  • Uses ssh and simple scripting language for:
    • (1) Configure
    • (2) Deploy
    • (3) Ad-Hoc Tasks

Tuesday, July 24, 2012

Kanban from the horse's mouth

DevOps Cafe Episode 30

A great podcast interview with David Anderson and Dominica DeGrandis about the roots of Kanban and how to use it to introduce process improvement in an organisation.


  • Kanban = culture of evolution
  • Original Kanban experiement at Microsoft was digital (ticketing system with database triggers)
  • Toyota let people see their processes because they know by the time they've copied it Toyota will have evolved further and they know that culture is much harder to copy especially for western cultures at a neuropshycological level
  • Guiding principles
    • Start where you are now
    • Agree to pursue change
    • Respect the current situation
  • Drum-buffer-rope analogy from "The Goal"
  • Blog article: Understanding process of knowledge discovery
  • Value Stream Mapping? 
    • Metaphor breaks down
    • Stream = water flow
    • Water can't flow uphill - IT releases involve rework that's hard to map
    • Better: "Workflow mapping"
    • Go around objections
  • Create environment where people can experiment and come up with own unique processes
    • Don't create new process for people - create a culture where they can evolve their own process & understand individual changes. 
    • Make many small adjustments over the long haul - evolving with each change
    • Snowball effect
    • Evolution gets you there faster
    • Like switching to Mac - can't explain it until you experience it
  • Pull
    • Toyota don't do a pure pull system
    • Users don't always know what they want
      • Eg jaguar asked jaguar owners to describe what they want in the new jaguar design - they designed the same car - can't imagine
  • "But we're a scrum/agile shop"
    • Tribal reaction - emotional response
    • Resistance to change
    • Can't have logical discussion about devops
    • Suggest a "super tribe"
  • Lessons agile mgmt

Introduction to Chef


Monday, July 16, 2012

Installing RVM on Ubuntu

Install RVM instead of Installing Ruby. 


bash < <(curl -sk https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer)
echo '[[ -s "$HOME/.rvm/scripts/rvm" ]] && . "$HOME/.rvm/scripts/rvm"' >> ~/.bashrc
source ~/.bashrc

Sunday, July 15, 2012


Testing REST with BDD
Brian Sletten 

The move to a good REST API yields an explosive combination of options due to content-negotiation and arbitrary workflows. At the same time, the uniform interface you project (representations, how you respond to verbs, response codes, etc.) becomes your contract with your clients. The API itself becomes a completely transportable, reusable bit of organizational knowledge when done well. Testing it sufficiently will give you a safety net but may drive you crazy unless you do it right. We will walk through the use of Behavior-Driven Development (BDD) to test these kinds of APIs.

We will highlight the problems of sufficiently testing REST APIs while providing a rich and relatively straight-forward solution to the problem. We will use a Behavior-Driven Development (BDD) tool like Cucumber to establish reusable steps and comprehensive, but lightweight testing strategies for testing REST APIs.

How to sell BDD to the business
Dan North

Presentation: http://skillsmatter.com/podcast/soa-rest/how-to-sell-bdd-to-the-business
Slides: http://skillsmatter.com/custom/presentations/sellingbddtothebusiness_bdd.pdf

I don't care how you do it - I just want it better, faster and cheaper and I don't want you to keep bugging me

How do you present the benefits case of BDD to a sceptical, time-starved, budget-focused business sponsor? When we talk about Writing software that matters it is from the perspective of the business as much as anybody else.

Software delivery shouldn't be a zero sum game where you have to choose between writing quality software, showing bottom line results and having fun. In this talk, Dan shares his experiences of introducing BDD and Agile principles to senior stakeholders and business executives. Download the slides here: http://skillsmatter.com/custom/presentations/sellingbddtothebusiness_bdd.pdf

Blog: BDD for secure REST APIs using cucumber, pickle, and rack-test

Wednesday, July 11, 2012

How to show Maven classpaths

Add this under <build><plugins> in your pom, then run it with  mvn compile :

                                <property name="compile_classpath" refid="maven.compile.classpath"/>
                                <property name="runtime_classpath" refid="maven.runtime.classpath"/>
                                <property name="test_classpath" refid="maven.test.classpath"/>
                                <property name="plugin_classpath" refid="maven.plugin.classpath"/>

                                <echo message="compile classpath: ${compile_classpath}"/>
                                <echo message="runtime classpath: ${runtime_classpath}"/>
                                <echo message="test classpath:    ${test_classpath}"/>
                                <echo message="plugin classpath:  ${plugin_classpath}"/>