How to Measure Technical Debt

So one of the biggest challenges I’ve repeatedly heard about technical debt is that although the delivery team knows it exists, there is no easy way to measure the actual cost of technical debt.  However, there are ways to help bridge the unspecific to the specific. With technical debt, using a financial analysis of comparing

Engagement Ceremony

If there is ever an art to delivering technology, it’s about knowing when and how to prioritize events as they unfold.  Some events are small and may only need an email.  Others, a simple test or instant message may do.  At higher levels of modality are direct phone ​calls with screen sharing, Skype, or even face to face

Types of Technical Debt

There are three primary types of Technical Debt: Naïve technical debt Unavoidable technical debt Strategic technical debt Naïve technical debt is common where a specific best practice is not followed due to being unaware of the best design pattern, unfamiliar with naming convention, documentation guidelines or even coding guidelines such as following abstraction in development

Technical Debt Explained

This will be first in a series of blogs. Technical debt is an interesting term that has been formed in the IT industry in order to have non technical businesses understand the cost of building code in a manner that causes higher maintenance and increased barriers to changing. Technical debt is intended to have a

Weatherman and Forecaster

Good project managers (and Scrum Masters) consider themselves like project “weathermen” — they report the current project conditions and forecast the future as accurately as possible. One important aspect of a weatherman (or weatherwoman) is to escalate quickly and effectively.  The project manager should have a “sixth sense” or intuition when a project is going down

Does Empathy Matter in the Workplace?

It’s very common in software engineering to recognize there is a right way to do things and then there is everything else.  Often, that “everything else” is the wrong way to do it. For instance, using no design pattern or an incorrect design pattern (i.e. a behavior pattern for a concurrency problem) would be “everything

User Stories Expanded

This is a continuation of my July 16th blog on User Stories. User stories in the simplest form is documentation for Agile delivery.  However, User stories are not necessarily requirements.  There is a fine line between a user story and a requirement and difficult to often distinguish. A user story is different than the “must

The Importance of Visibility

At one of my former employers, they were implementing a huge engineering project (estimated costs in the billions) and brought me in to lead the IT project oversight for the adoption of software to support the Reliability and Maintenance (R&M) of specialized oil tankers once placed into commission.​ At the onset, the overall R&M Project Manager believed this extra level

Building Good User Stories

In developing accurate requirements and derive accurate estimates from client engagements, user stories are increasingly becoming the de facto standard for documenting. Simple in concept, but difficult to master, user stories have this basic format: As a <actor/user>, I can/want <what> so that <why> The “how” is kept out, since that is what the delivery

Teams Today and In the Past

Modern day development teams can learn a lot from our history.  For instance, the Three (or Four) Musketeers:  One for all and all for one! ​This brings the scrum model of a unified team into principle that everyone is here together and the team in indivisible, i.e. together in one unit.  Teams should practice “gemba” or swarming when