Watch your step when setting goals!

Watch your step when setting goals!

Setting goals is important for deciding what you want to achieve in a specific period. Goal setting provides value by forcing a degree of introspection, acting as a filter to separate the important from the irrelevant and as a guide to channel behavior. Like many things in life the journey is often as important as the goal destination, however, setting goals is complex. There are many processes and frameworks to provide structure for setting goals; however, even with a framework, goal setting sometimes gets off track. Several systematic problems observed when setting goals include:


Warning: Ejection Seat

You have to plan where you’re going so you end up in the right seat.

“The new year stands before us, like a chapter in a book, waiting to be written. We can help write that story by setting goals.” – Melody Beattie 

Setting goals is an important ritual that marks the end of one year and the beginning of the next. It is an avenue for introspection, a filter to sort out the irrelevant, and to influence behavior. A goal is a statement of a person’s, team’s or organization’s ambition.  A goal can be strategic or tactical depending on how a goal is stated.  You can use a framework to consistently develop goals. A consistent framework can help you not to forget some key considerations that are useful for translating an idea into action. Such as ensuring goals are tangible enough to be measured. There are a huge number of frameworks, including SMART, PASTIE, and BHAG to name a few. (more…)


What is on your to-do list?

I was recently standing in a line waiting to get on an airplane and overhead a child talking with an adult.  The part of the conversation I heard began, “When I grow up I want to be. . .” Whether the child knew it or not, he was espousing a goal based on his vision of the future. In the run-up to the New Year, it is important to remember the benefits of goal setting. Setting goals is important for deciding what you want to achieve in a specific period, whether a day, month, quarter, year or lifetime. Goal setting provides value by forcing a degree of introspection, acting as a filter to separate the important from the irrelevant and as a guide to channel behavior.

Introspection is the act of calmly reviewing one’s thoughts, sorting through the clutter of day-to-day living. Techniques like retrospectives are a structured approach to introspection at a group and personal level. Meditation is also a valuable technique for individual introspection. The act of stepping back and thinking about the future is an excellent first step in the process of goal setting by providing the quiet space to consider what has been accomplished and to consider aspirations. You need to first agree upon a vision of the future to pursue so that you can set  goals to help to achieve that vision.

Increasing business value is the single most important reason for any significant organizational change.

Increasing business value is the single most important reason for any significant organizational change.

Over the past few years the concept DevOps has developed and become an important framework for structuring work in the IT organizations. The “newness” of the concept has led to a wide range of definitions of DevOps. The lack of an industry standard definition has led organizations pursue DevOps as a tool to address a wide range of goals. If we embrace the definition of DevOps as the exercise of combining operations and development personnel who participate together across the entire life cycle, from analysis to production support, leveraging Agile principles and techniques there are three macro goals for embracing and implementing DevOps. DevOps supports three overall goals.

  1. Increasing Business Value
  2. Changing Organizational Culture
  3. Optimizing Delivery

Reaching any of these goals can have many benefits. (Note: it is easy to conflate benefits and goals, however benefits are the result of attaining a goal rather than the other way around.)

Increasing business value is the single most important reason for any significant organizational change. Business value is term that encompasses a wide range of concepts including increased revenue, lowering costs, improving quality, reducing time-to-market and increasing customer, employee and stakeholder satisfaction. All of these can be potential benefits of implementing DevOps when perusing a goal increasing business value.

Changing organizational culture breaks down entrenched behaviors within an organization. Implementing DevOps integrates development, technical operations and testing personnel which erases barriers between organization silos. Benefits include increased collaboration, collaboration and reducing conflict.

Optimizing delivery is often the goal most organizations cite for implementing DevOps. DevOps can lead to fewer mistakes in the process of delivery, increasing the amount of functionality delivered and reducing the number of hand-offs.

All three of the high-level goals for implementing DevOps have some degree of overlap. For example, changing organizational culture by adopting DevOps will also increase employee satisfaction (increased business value) and improve collaboration (optimizing delivery). Optimizing delivery often leads to reduced costs which increases business value. Overlaps allow organizations to focus on one goal while getting some of the benefits of another.

Effective organizational transformation is not merely the pursuit of benefits, but rather a pursuit of goals in support of a greater vision. Understanding the goal or goals of a DevOps transformation is important. However goals are a reflection of the future established when an organization embraces a vision based on their sense of urgency. A vision represents a picture of a state of being at some point in the future, and it acts as an anchor that establishes the goal of the transformation. Attaining goals yields benefits, which provide feedback on progress toward goals and vision. The relationship between benefits, goals and vision establishes a virtuous cycle.


CMMI, ITIL, Six Sigma, Agile, waterfall, software development life cycle and eXtreme Programming . . .what do all of these terms have in common?  They are models.  In a perfect world, models are abstractions that we find useful to explain the world around us.  Models work by rendering complex ideas more simply.  For example, both a road map and picture rendered in Google Earth are models.  Two very different types of models: an abstraction of a set roads, buildings, parks and plants that exhibit can provide more information than rendering.  Real life is complex, Google Earth is less complex and the road maps are the least complex.  Simplifying a concept to a point allows understanding, while too much simplification renders the concept as a pale reflection.  Oversimplification can lead to misunderstandings or misconceptions, for example the conception that Agile methods are undisciplined or that waterfall methods are bureaucratic.  Both of these are misconceptions (individual implementations are another story).  According to Kenji Haranabe, software development is a form of communication game.  Communication requires that groups understand a concept so that it can be implemented.  Communication and understanding requires finding a level where common understanding based on common words can occur.  Words provide the simplification of real life into a form of model.

Unfortunately it is difficult to determine when enough simplification is enough.  Oversimplification of ideas can allow trouble to creep in.  Oversimplification can water down a concept to the point that it can not provide useful information to be used operationally.  An example of a very simple model is the five maturity levels commonly connected to the CMMI.  The maturity levels build awareness, but provide little operational information.  I do not know how many times I have heard people talk about an individual maturity level as if the name given to that level was all you needed to know about a maturity level.   The less simplified version with process areas, goals and practices provides substantial operational information.  ‘Operationalizing’ an overly simplified model will yield unanticipated results and that is not what we want from a model.  I once built a model of the battleship Missouri that had horrible directions (directions are a model of a model), I used three firecrackers to remodel the thing I ended up with (which was not a very good model).

Models abound in the world of information technology.  If we don’t have a model for it, we at least have TLA (three letter acronym) for it and are working on a model that will incorporate it.  The models that have lasting power provide structure, discipline and control.  They’re also used as a tool to guide work (tightly or loosely depends on the organization) and as a scaffold to define improvements in a structured manner.  Models are powerful; molding, bending and guiding legions of IT practitioners.  The dark side of this power is that the choice of models can be definitional statement for a group or organization.  Selecting a model can elicit all of the passions of politics or religion.  Just consider the emotions you feel when describing Six Sigma, CMMI, eXtreme Programming, waterfall or Agile.  One of those words will probably be a hot button.  The power of models can become seductive and entrenched so as to reduce your ability to change and adapt as circumstances demand.  A model is never a goal!  Define what your expectations are for the model or models that you are you using in business terms.  Examples of goals I would expect are of increased customer satisfaction, improved quality or faster time-to-market, rather than attaining CMMI Maturity Level 2 or implementing daily builds.  Know what you want to accomplish then integrate the models and tactics to achieve those goals.  Do not let the tool be the goal.

Models are powerful, useful tools to ensure understanding, they provide structure and discipline.  Perform a health check.  Questions to ask about the models in your organization begin with:

  1. Is there is a deep enough understanding of the model being used? – With knowledge comes the background to operationalize the model.
  2. What are your expectations of value from the model? – Knowing what you want from a model helps ensure that the model does not become the goal and that you retain the ability to be flexible.

There are many other questions you can ask on your heath check, however if you can’t answer these questions well stop and reassess, re-evaluate, re-train and re-plan your effort.

CMMI, ITIL, Six Sigma, Agile, waterfall, software development life cycle and eXtreme Programming. . . powerful tools or a straight jacket. Which is it for you?

A good fruit salad requires balance.

A good fruit salad requires balance.

In the Software Process and Measurement Cast 308, author Michael West describes a scenario in which a cellphone manufacturer decided that quality was their ultimate goal. The handset that resulted did not wow their customers. The functionally wasn’t what was expected and the price was prohibitive. The morale of the story was that quality really should not have be the ultimate goal of the project. At the time I recorded the interview I did not think the message Mr. West was suggesting was controversial. Recently I got a call on Skype. The caller had listened to the podcast and read Project Success: A Balancing Act and wanted to discuss why his department’s clients were up in arms about the slow rate of delivery and the high cost of projects. Heated arguments had erupted at steering committee meetings and it was rumored that someone had suggested that if the business wanted cheaper products that IT would just stop testing. Clearly focusing on the goal of zero defects (which was equated to quality) was eliciting unproductive behavior. Our discussion lead to an agreement that a more balanced goal for software development, enhancement or maintenance projects is the delivery of maximum value to whoever requested the project.

When a sponsor funds and sells a project they communicate a set of expectations. Those exceptions typically encompass a project will deliver:

  1. The functionality needed to meet their needs,
  2. The budget they will spend to acquire that functionality,
  3. When want the functionality, and
  4. The level of quality required to support their needs.

Each expectation is part of the definition of value. A project that is delivered with zero defects two years after it is need is less valuable than a project delivered when needed that may have some latent minor defects. A project that costs too much uses resources that might be better used to do another project or potentially causes an organization products to be priced out of the market. Successful projects find a balance between all expectations in order to maximize the value that is delivered.

Quality is not the ultimate goal of any software development, enhancement or maintenance project but neither is cost, schedule or even functionality. Value is the goal all project should pursue. Finding and maintaining equilibrium between the competing goals of cost, schedule and functionality is needed to maximize the ultimate value of a project. Each project will have their own balance based on the context of the project. Focusing on one goal to the exclusion of all others represents an opportunity cost. Every time we face a decision that promotes one goal over another, we should ask ourselves whether that choice is worth giving focus over another goal. Projects that focus on value create an environment in which teams, sponsors and organizations confront the trade-offs goals like zero-defects or perfect quality can cause.

Goals are the carrots that keep teams motivated.

Goals are the carrots that keep teams motivated.

Teams are a critical tool to deliver work in IT organizations. There are several common attributes of effective teams. A simple search of the internet or the books on your shelves will yield myriad lists that identify attributes of effective teams. Nearly every list is topped by shared team goals. In order to be effective, goals must be aspirational, lead activity and agreed upon.

Goals by definition need to be aspirational. Goals guide teams to improve how they perform.  In order for a goal to be aspirational, a goal must be set beyond what typical performance levels would deliver BUT be both attainable and be perceived as important to helping the broader organization meet it mission.  Goals that are not attainable or not perceived to be important will not inspire or motivate teams. Team members elevate their performance because they can make a difference.

Goals provide teams with an objective. In order to meet their objectives teams use the goals as a tool in the planning process. For example, in Agile projects each sprint will reflect both goals of the release plan (high-level goals) and stories selected by the product owner that are required to generate the tasks needed to deliver value. Without goals to focus on planning teams will be apt to wander.

Goals work best when teams participate in setting their goals rather than having goals imposed. Earlier in my career I was a marketing statistician for a women’s garment manufacturer. It was one of the most top-down organizations I have ever worked for in my career (and it no longer exists). At the beginning of every sales period I would lead the sales department in setting quotas for the sales force based on historical data and market intelligence. These quotas were then assigned to the sales force. I spent time in meetings (and bars) with the sales people, and to a person I learned that the quotas motivated no one (each sales person was driven, but not by quotas). Had we involved them in setting the quotas required to meet the company goals, it is very possible that the sales people would have been motivated by the process.

Goals that are out or reach or inflicted on a team will sap them of critical motivation and can cause poor behavior. Teams that do not believe in the goals they are asked to pursue can and do reject those goals, and then under-perform or end up not delivering what the business needs. Goals are important tools to provide teams with a vision of what they need to accomplish and then provide reinforcing motivation.

You do not have to be a superman to map your metrics to your organizations goals!

You do not have to be a superman to map your metrics to your organizations goals!

Jason Yip (@jchyip) commented on my post, Why Measure, pointing out the problems with many of measures that are used, and therefore the unintended behavior they cause because the wrong question is being asked. Asking the wrong question (or seeking the wrong answer) is exacerbated when measures and metrics are not linked to organizational goals. Measures and metrics that are not closely linked to the organization’s commitments cause the wrong behavior. The only way to truly know if your measures and metrics are linked to the organization goals is to map them back to the goals. There are several techniques for determining whether linkages exist.  We begin simply with a mapping/matrix approach using a spreadsheet.

Here is the Spreadsheet-Based Metrics Mapping Process:

  1. Identify the organizational goals and objectives. While this should be as simple as asking the first person you run into, generally collecting the goals and objectives is more problematic and can generate quite a bit of conversation (a benefit in its own right). If you have to mine for the objectives, review the annual report or interview senior managers. As a general rule you are looking for the overall organization’s goals rather than those for a department. However, if you are serving an autonomous division within a conglomerate, your sights might be lower.
  2. List the organizational goals across the top of the spreadsheet.
  3. Inventory all the metrics and any measures that are in a standalone mode (A measure is a concrete or objective attribute that can be directly measured.  Metrics are the combination of two or more measures or metrics, such as miles per hour).
  4. List the metrics and measures down the slide of the spreadsheet.  The resulting matrix will look something like this:Matrix
  5. Convene a cross-functional team of approximately 5 -7 people (include management, team members, product owners and other IT stakeholders) and fill in the matrix.  This is generally a two-pass process.
  • Pass 1: Walk through each measure and develop a consensus of whether it directly incentivizes behavior that supports the goal and strength of the support that is generated. Use blanks and Harvey Balls to indicate degree of support visually.  A blank represents no support and a fully closed in Harvey Ball as strong support. Time box this step to no more than 2 minutes per metric (average), because you want initial reactions.
  • Pass 2: Challenge the team to walk through each metric and measure and to name the behavior they believe the metrics will incent. Then ask them to revisit or refine their initial observations.

Note:  I consider the order important. The first step helps to identify participant’s natural, non-intellectualized view of the metric or measure, and also creates a minor anchor bias. The second step allows the participants to express their intellectual positions and to challenge the potentially more emotional position they may have initially espoused.

The outcome would look like the following:


Updated Metrics Map

  1. Where the linkages between metrics and goals are not strong and specific there are three options:
  • Stop collecting the metric (this is my favorite IF there is no or just a tenuous linkage, or if there are other stronger links. Less is generally more in measurement).
  • Change or refine the metric if you absolutely need the refined metric to cover a specific goal or to incent a specific behavior.
  • Continue despite the lack of linkage and waste everyone’s time (this is usually driven by poor internal politics).

The mapping/matrix approach is easy to deploy and collaborative.  Involving all the stakeholders in the measurement process in the mapping process creates a substantial level of buy-in. The process of refining the links between measurement and goals can generate a lot of information about the organization. For example, the process will expose whether all levels in the organization know what the organizational goals are and then whether they are progressing against them.

Break the rules at your own peril.

Break the rules at your own peril.

I am not really a big rule guy, I would rather think of most structures as a guideline. However, sometimes there are some lines that shouldn’t be crossed.  There are three rules that everyone involved in backlog refinement must remember.  These rules are broken at your peril!

  1. Rule One (originally described in Splitting User Stories: Patterns): Each story must deliver functionality that is potentially implementable. If a story needs to be split or refined, think slice rather than phase or layer. Each story should represent a thin slice of on an onion starting at the outer layer cutting to the core rather than an individual layer.
  2. Rule Two: All formal refinement sessions need to have a clear measurable goal. A goal provides focus for the refinement exercise and provides bounds in much the same manner as an agenda does in a standard meeting. Participants should know the goal for the session (e.g. today we focus on stories supporting the theme for the next sprint) when the session is scheduled so that they can prepare. For example, when I participate in refinement sessions, I try to review the stories that will be discussed so I am not participating to generate questions, but rather participating to generate understanding.
  3. Rule Three: While most Agile exercises include the whole team, participation in a refinement session should be limited. I use the Three Amigos technique to ensure a crosssection that includes a tester, product owner or business analyst and developer. refinement sessions are working sessions focused on making sure stories are understood, properly formed and have initial acceptance criteria. The larger the number of people involved in a meeting, the larger the amount of time that will be spent developing a consensus that will be revisited during sprint planning.

When scheduling a refinement session remember the three rules.  First and foremost, all stories need to deliver value. If a story does not deliver value, consider jettisoning the story. If you are going to schedule a session make sure you have a goal.  Just like the relationship between a meeting and an agenda (no agenda, no meeting), if you don’t have a goal for your session generate a one or reschedule the session. Finally, inviting everyone involved in the project (and a few extra subject matter experts for good measure) is a recipe for death by talking.  Constrain the session to the absolute minimum number of participants. User story refinement is important, don’t mess it up!  If you have to break the rules  . . . well just don’t.

Some meetings are just too large!

Some meetings are just too large!

As I noted in Four Types of Meetings, most denizens of the corporate world spend a substantial portion of their day in meetings. Based on the sheer number of people crammed into conference rooms or huddled around speakerphones, most meetings are not only effective and efficient, but well loved. But, a quick poll of office workers (that did not just partake in cookies) would quickly dissuade you of this thought. Most meetings, regardless of type, fail to follow basic meeting logistics and etiquette.  There are four logistics and etiquette categories that need to be dealt with:

  • Direction:  All meetings need to have a clear, measureable goal. All participants must understand the goal and how they will contribute to meeting the goal. In order to support the goal, all meetings need to have an agenda that provides a path that meets the goal. Finally, to support the direction if pre-work or background is required, it should be distributed to all participants at least a day before the meeting (and everyone should be accountable for doing the pre-work).
  • Meeting Size: With some notable exceptions (presentations and lectures), most meetings should be held to a maximum size of 5 to 9 (same as they typical size maximum for Agile teams) in order to ensure that the people in the meeting can interact without having to break into sub-teams.  The best way to constrain the meeting size is to ensure the right people and only the right people are attending.  The right people are those can affect the goal, have a position (are not bystanders) in the outcome of the meeting and can make decisions about committing their resources.  Finally if the meeting is being held to make a decision a single, clear decision maker must be present.
  • Duration: All meetings need to be time boxed.  The time box should rarely exceed one hour. When planning and executing meetings, you should strive to keep them as short as possible. Short meetings with a crisp goal tend to stay on track. One technique for keeping meetings short is removing the chairs. The Wall Street Journal reported that meetings that are held standing up typically take 1/3 less time than similar meetings where chairs were provided.
  • Follow-up: If action items and follow-ups are generated in a meeting each item needs to indicate what must be done and MUST be a assigned a directly responsible individual (DRI) who will be accountable for follow up.

Effective and efficient meetings require planning to ensure that a clear goal is identified before the meeting invitation is sent.  A clear goal not only helps to focus the meeting but it helps to decide who to send invitations. Once the invitation is sent whomever is facilitating the meeting needs to help make sure the right people participate and that “substitutions” meet the criteria needed to participate. Good meetings require work, but given that, meetings are ubiquitous, the work to make meetings effective will pay off in the long run.