Getting Fig for Docker Working with Centos7

This is a fix for the following error when running fig up on Centos 7:

Look at the Docker documentation under basics:

Edit /etc/sysconfig/docker

change from


Restart Docker

Fig will work.



Sample Vision Statement for Scaling Scrum at the Enterprise Level

While a lot of implementing scrum happens at the micro level, you need a clear macro-level message to enlist the help of your partners and users to solidify scrum across the organization.

Here’s a sample vision document I’m using to get leadership on the same page for scaling scrum to the enterprise level. It intentionally omits some details, but it’s purpose is to get all parties to agree on some central organizing concepts.

Vision Statement – Enterprise Scrum Adoption


  • org teams that deliver software products and work on technical projects,
  • people serving in the roles of product owners, project managers, quality assurance, infrastructure and UI/UX,


  • have stakeholders and customers,
  • have 3 or more team members (not including scrum masters and product owners),
  • would like to provide better transparency on short-range and long-range plans,
  • need to manage requirements,
  • need to estimate and plan work,
  • need to create teams around products OR projects,
  • struggle because they have taken on too much work,
  • struggle to manage service requests and emergencies while executing on planned work,

A good solution…

acknowledges the current realities

  • management wants a consistent view of release plans and quarterly priorities for everyone, but org currently lacks a common reporting mechanism
  • 100+ scrum backlogs have been created in org — the genie is out of the bottle — teams are using scrum, but vary greatly in their scrum skills and effectiveness
  • teams running no process or poorly implemented process suffer from:
    • high context switching
    • team members feeling overloaded
    • too many meetings and too many people in them
    • inability to commit to specific delivery goals and/or failure to deliver what was planned
    • lack of clarity regarding high level goals of a product
    • poor alignment with stakeholders
    • no mechanism for measuring the effectiveness of their development process
  • teams face infrastructural challenges that impede adoption, but providing accommodations such as ‘hardening sprints’ allows these teams to realize significant benefits

takes a multi-pronged approach to managing change

  • set expectations, model behaviors, provide education and tactical consulting services for teams that are using scrum right now
  • build examples of success through deep coaching engagements in targeted areas

educates leaders that

  • are at the manager, director, executive and senior executive level
  • acknowledge and communicate that ‘scrum’ is not an officially standardized specification, but a practice, and that processes such as release planning and roadmap planning must be tailored to the organization and taught to be effective
  • recognize education as essential to effective process and tool use, clearing their staff schedules enough to complete tool and process training within a quarter
  • model the right behaviors to develop those behaviors in others
    • only exercise direct authority as a last resort
    • take a values-based approach to influencing behavior – communicating company values not just by what you say, but by what you do
    • attend all training classes, regardless of their role, so they’re highly confident in their understanding of org scrum
    • elect to use scrum in situations that meet the criteria (team size, type of work) in their area of influence
    • communicate the difference between ‘low value’ and ‘high value’ discussions, recognizes training as something that increases the value of dialog
    • understand the concept of ‘pigs’ and ‘chickens’, and seeks to create pigs by communicating clear objectives that invest everyone in a successful outcome

provides the right team structure

  • understand the ‘multi-disciplinary scrum team’ concept, and work with teams, upper management, and process architecture to guide teams into the correct structure as problems are encountered
  • facilitates team structure discussions in education and consultation
  • feeds product and project work into integrated technology, product ownership, project management, UI/UX teams
  • defines ‘rules of engagement’ for teams that must operate as shared services with scrum teams (QA in some cases, Infrastructure)

standardizes the following terms

  • team
    • multi-disciplinary
    • acts against one or more backlogs
    • wants high focus and low context switching on one or more products or projects
    • has a velocity
  • yearly product roadmap
  • quarterly product roadmap
  • release planning
  • sprint planning
  • product
    • is an ongoing concern
  • project
    • has a start and an end
    • may require work from multiple teams
  • requirements
    • vision
    • themes
    • stories

defines a process architecture team that

  • encourages and facilitates deep investment and contribution to process evolution from all stakeholders,
  • manages scrum process & tool requirements for all user groups,
  • maintains balance and integration between process groups, raises flags on items that degrade effectiveness of the overall software delivery value chain,
  • provides tools to facilitate process,
  • provides documentation & education in process and tools

has clearly communicated expectations of org teams that elect to use the scrum process

  • team & stakeholders attend education for their roles
  • teams will communicate their release plans and quarterly release roadmaps within the framework defined by PMO in collaboration with process architecture
  • teams realize they have access to process architecture/scrum coaches within 1 week for consultation and coaching
  • scrum masters (on behalf of their teams) have the right to escalate to PMO when work is demanded of them that greatly exceeds their velocity
  • teams have the right to review, estimate and approve yearly, quarterly plans for work being asked of them, and may reject plans (via PMO)

provides a voice to user groups

  • bi-weekly retrospectives for scrum masters, product owners, developers, quality assurance
  • feed retrospective items into prioritized process architecture backlog (process architecture and others may be assigned work)

provides transparency to management on scrum adoption progress

  • PMO: weekly theme & release reports
  • Product: quarterly theme-level roadmap reports
  • Process architecture: regular progress reports to management on training attendance, scrum team process quality

measures success via

  • satisfaction surveys with teams, stakeholders, and customers
  • # of people attending education sessions
  • # of products & projects included in PMO and Product reports
  • face to face interviews with users, stakeholders, customers


Large Scale Scrum: Employ a Product Mindset for Better Multi-Team Collaboration

Author’s Notes: The Lean Product concept is hot right now – but it primarily focuses on getting the customer-product fit right. This article has a different focus — application of ¬†product concepts to scale scrum.

If you’ve been Scrumming for a while in a large organization, chances are you’re asking yourself:

How do I manage interdependencies between Scrum Teams?

This can be a problem – large organizations with strong in-house technical capabilities will have interrelated service oriented architectures, layered architectures, infrastructure groups, all relying on each other to deliver the end solution.

If you look at the Scrum community’s response on how to manage delivery between these teams, there’s typically one answer: Scrum of Scrums. This is, in my opinion, punting on the problem. It doesn’t even begin to address this complex issue in a repeatable and structured fashion.

Applying a product mindset to technical teams can help.

Let’s paint a scenario.

Acme Widgets is a large organization. Producing their beloved widgets involves the following teams:


  • Web Team A
  • Web Team B
  • Web Team C
  • Web Team D

Shared Services

  • App Platform Team A (Shared Service)
  • Infrastructure Team A (Shared Service)

Note the web teams rely heavily on capabilities provided by shared services groups. This shared services model is typical of most complex tech shops.

If we go with a simple approach to managing this complexity, the shared services leads might conduct scrums of scrums with the consumer team leads. This certainly helps, but there are still issues to be addressed:

  • Do consumer or shared services backlogs contain the stories?
  • How do shared services teams think about their velocity?

While we can arrive at rules on how we export or import stories from one team to another, the problems of work tracking and interdependencies between consumers and producers here are tough to solve – establishing process rules and having a scrum of scrums doesn’t make it all better.

Let’s introduce the product concept.

Early in my software career, there were tons and tons of opportunities to work on custom software development projects – the web software domain was still immature – it hadn’t ¬†codified and packaged solutions for problem domains. Nice thing about this – the cost of custom software development was high — we made money — but the cost to the customer was high as well.

As the software industry matured, more and more productized solutions emerged. Businesses favor productized solutions because they are significantly cheaper than a custom solution. Once you invest the effort in packaging a product and enter mass-production mode, your overall cost per unit drops, and keeps dropping the more units you sell. The other big benefit here is the entanglement between the customer and the producer is greatly simplified — you know your customer’s needs, and you provide a configurable product/solution to meet their needs without full-blown requirements & analysis phases, construction efforts, QA phases, etc.

Let’s go into a little detail on applying a product mindset to the Acme Widgets scenario.


  • Consumer teams are customers.
  • Shared services teams produce products.

Steps for Applying a Product Focus:

Understand your customer types.

Think about your product, and your customer types. What categories do they fall into? Examples: Small, Medium, Large? High Security Risk, Low Security Risk?

Streamline your requirements process.

Create a systematic requirements gathering process that starts with identifying the customer type of the requestor, then offering them the minimal product set that meets their needs, and avoids unstructured analysis. Better yet, make it self service and template-based.

Provide delivery and support SLAs.

With a constrained set of variables to consider, your confidence in your ability to estimate service levels around product delivery and support will increase. Customers appreciate this, and it lets you do better demand and expectation management.

Standardize your change and deployment process.

Standardizing your product has other benefits that the customer won’t directly see: because your product has less moving parts, the change management and review process can be simplified, perhaps even pre-approved. This eliminates wasteful gates, and speeds delivery even further. (For the ITIL heads in the room – think of incentivizing your teams by allowing those with the right product focus to move from Normal to Standard Change protocols).

At this point, lets go back to our original problem, and talk about how the product-centric approach can help scrum teams.

Scrum Teams without Product Focus

  • Tight coupling and deep integration of work efforts between teams
  • Detailed work planning between collaborating groups
  • Stories and technical tasks are imported and exported across backlogs to coordinate efforts
  • Cross-team velocity rules/calculations are complex, cumbersome
Scrum Teams with Product Focus
  • Looser coupling, better encapsulation of internal work efforts
  • Communication via standardized interfaces (standard requirements templates, estimates, SLAs)
  • Consumer teams rely on ever-more-reliable SLAs for delivery forecasting
  • Product team stories around external commitments become simplified, standardized, with smaller point values
  • Product team does less and less custom work, and/or can flag work as custom and cover under different service class models
Managing interdependencies between scrum teams in  environments will always remain complex Рbut employing a product mindset can help reduce the amount of variables you need simultaneously consider.


Default Route Ping and Failover Script [Solaris/Ruby]

Wrote this for my squid boxes. They’re built with lots of redundancy – I can fail over to a different NIC/IP address in the event of a connectivity failure.

Written and tested on Solaris, runs as a Ruby daemon.

Oracle Database Create Script, In Ruby

You can find this script anywhere written in bash. I decided to bang one out in Ruby. Most importantly, it’ll show a way to invoke sqlplus and pass in SQL as an argument.



Very Basic REST and the Google Provisioning API In Ruby

In this post, I’m walking the user through an app that talks to Google via their Provisioning API.

I’ll be talking about the following:

– Ruby/Rails
– HTTP Basic Authorization
– Google GData and Google Provisioning API

This article is a work in progress.



Bombproofing: “Bonding” Multiple NICs to One Network Interface

Concept: Two network cards backing one IP address. One card fails, you’re still up.

linux channel bonding
linux channel bonding

Example will show bonding of 2 network cards to one IP address (macs and IPs changed to protect the innocent).

Step 1: Create /etc/modprobe.conf entries

Step 2: Create ifcfg-bond0 file in /etc/sysconfig/network-scripts

Step 3: Modify existing ifcfg-eth0 and ifcfg-eth1 files in /etc/sysconfig/network-scripts



Step 4: Re-initialize network