Daniel Markham

From Info-Ops
Revision as of 00:38, 7 December 2020 by Daniel (talk | contribs)
Jump to navigation Jump to search
Daniel Markham in 2020

Early Life

Daniel B. Markham was born on 5 May 1965 in rural Southwestern Virginia. He was given up for adoption at birth and was adopted when he was six weeks old by Gordon B. and Margaret Tess Markham. He spent his early years growing up in Vinton, Virginia, studying piano, exploring photography, building model-railroads, and playing AD&D.

College and the Marines

Markham was in the United States Marine Corps from 1984-1986. He was trained as a TOW missile gunner.

He attended a small local technical college in 1983 for programming. After the service he attended a community college in 1987 for Business Administration. He stopped attending college when computer programming projects started taking up all of his time.

Early Programming Career

Markham wrote his first program at age 16, a space invaders-like game called "Kill Roland" on the Commodore PET. He wrote his first contract program at age 18, an accounting program for a local bookkeeper. No matter what else he was doing, from clerking in a shipping department to being a manager at Domino's Pizza, he always ended up automating the work by writing computer programs.

Deciding to go into business for himself, he spent his mid-20s working in rural Southwestern Virginia doing odd computer work for whoever needed it. Some projects were:

  • Managing a small IT shop consisting of a DEC VAX, a dozen IBM PCs, while creating a QC system for a local custom nuclear pipe-fitting business.
  • Creating a program to manage a local comic-book store.
  • Setting up, learning, and teaching the use of a small Mac/AppleTalk network for a local publisher.
  • Creating a set of linked Visicalc spreadsheets to handle the operations of a local pizza chain
  • Creating a suite of programs to handle operations of a privately-owned truck fleet
  • Filling in for a 2-man tech support team in a nearby city while they attended a conference.

Career as a Programming Consultant

In the mid-90s, desiring to move from mom-and-pop technology projects to "real" consulting, Markham started advertising and seeking full-time consulting work online. His first client was a large health insurer in Sacramento, California.

He continued this work for over a decade. Some of his notable clients included:

  • Pitney Bowes
  • Ford Motor Company
  • Trilogy Software
  • Charles Schwab
  • Immigration and Naturalization Service (now ICE)
  • Federal Reserve BOG (The Federal Reserve HQ located in downtown DC)
  • Defense Commissary Agency

Career as a Technical Coach

In early 2000s, he moved from being a technical lead on several teams to coaching teams across an organization in how to succeed faster. This included understanding and applying several cutting-edge processes: JAD, RAD, FCT, RUP, MDD, XP, and finally Agile. Clients included:

  • State Farm Insurance
  • Alcatel Lucent
  • Thales Communications
  • Charles Schwab
  • Modea
  • NTTi3
  • J.Crew
A software development program self-evaluates their status using the MAT (2005)


As Daniel moved from Technical Lead/Architect to Technical Coach, developers continued to ask him to explain techniques in programming terms. What do we mean when we say the design is emergent? How can outsiders to a team have a reasonable and standardized conversation about performance aspects of a meta nature?

In 2004, he created the Markham Assessment Tool to begin answering those questions. The MAT would take any set of practices described as goals and combine them with various standardized lists of reasons why goals could not be achieved. By asking all of the people involved to assess themselves using the MAT, a standardized language of problems each team was facing was created that could then be compared with other teams across the organization. In addition, over time, various patterns of goals and obstacles could be associated with various performance problems and chances of successful interventions. It didn't tell whether a team was bad or good. Instead, it allowed all teams to talk using the same language about the things they thought they needed to improve the most


No matter which technical skills he taught, he found that teams almost universally were given untestable backlogs. This was at the root of many of their problems (story splitting, estimation, TDD, ATDD, code reviews, and so forth.

Because of that, he created several courses around creating and consuming better backlogs; backlogs that were simple to use and understand and that would not get in the way of work. This led to several backlogs books and videos.

Eary backlogs book

Later Career