Category Archives: Agile

How do you Run A Good Retrospective Meeting?

I’ve written before about some techniques that I think help to run a good meeting[1].

Recently, I made the decision to delegate[2] the running of most of our team meetings to my reports. Typically, we have daily five[3]-minute standups, bi-weekly Sprint Planning, the occasional brainstorm, and a weekly meeting with stakeholders.

We now do a rotation, with each member of the team (including the interns) running the daily standups and bi-weekly Sprint Planning meetings in turn.

I’ve had to learn some things about delegating, but that’s a story for another post.

For today, I wanted to talk about some of my observations about how to run (what I think is) a good retrospective.

Normally, our retrospective is sandwiched in the middle of our Sprint Planning meeting thus:

1) Adjust any tickets which have changed status since the daily standup[4]
2) Close the Sprint
3) Retrospective
4) Choose a name for the new Sprint (Generally the most difficult[5] part)
5) Add items to the new sprint, prioritizing and estimating as we go[6]

It wasn’t until I watched others running a Retrospective that I understood a lot of the small things that I do that make a difference.

The (way I see) steps to a Retrospective are as follows:

1) The Facilitator draws the visualization[7] to start people thinking:

The facilitator writes something akin[8] to the following diagram on the board:

  
  Went Well       Not So Well
*---------------*----------------*
|               |                |
|               |                |  In Our Control
|               |                |
*---------------*----------------*
|               |                |
|               |                |  Not In Our Control
|               |                |
*---------------*----------------*

The point of this is to help the group think about and distinguish things that are in their direct control and out of their direct control. Many groups will come up with a definition for this after their first argument, often placing the line of ‘direct control’ at the edge of the group in the meeting/team in question. There are also many ways to write ‘Not So Well’, which I won’t get into, except to say that I prefer the hopeful phrasing. 🙂

Overall, you can think of your group process as bringing issues from ‘Not So Well/Not In Our Control’ to ‘In Our Control’, then ‘Went Well’, then noting new issues and starting the cycle again. We had one retrospective a while back where basically everything was ‘Went Well/In Our Control’, or ‘Not So Well/Not In Our Control’, so we ended up brainstorming ways to get things under our control, or at least influence, so we could fix them.

It’s not necessarily the worst thing in the world if most items are in the ‘Went Well/In Our Control’ category, but this may also mean that there are underlying issues that you may need to ferret out in your one-on-ones (You *are* having one-on-ones with your team, right?). One such issue came up recently in a one-on-one, and when it was brought up in the Retro., I hijacked the meeting for half an hour to have a specific brainstorm on that topic, to make sure it was covered in depth.

2) The facilitator asks the team to write things went well or did not go well on sticky notes and to put them on the board:

Each member of the team writes happenings from the past two weeks on sticky notes and posts them on the diagram. We use standard-sized sticky notes, and sharpies, so that the notes can be (mostly) read from across the room. My understanding of why this is done with sticky notes is so that people feel some measure of safety and anonymity, and therefore are more likely to express what they really think.

When running this part, I ask people to think along process lines. It’s helpful (and sometimes nice!) to talk about the fact that a particular project went well or poorly, but it’s often more helpful to talk about the parts of our process or other teams’ process that affected the outcome. Identifying process issues and fixing them is what really makes the difference here.

3) The facilitator clarifies each of the posts:

In some order, the facilitator goes through each (group of) post(s) and invites the author to clarify anything ambiguous, such that the whole group understands what each post means (often caused by my handwriting… :/ ). This should only take a few minutes. As they go, the facilitator will often do step 4). Along the way, some problems may be resolved simply by bringing them up, but some may require more thought/brainstorming. Those conversations are shelved until a later step by the facilitator.

As far as ordering, we generally talk about what went well first, probably for psychological safety reasons.

4) The facilitator de-duplicates the posts:

This is more of an art than a science. In some serious brainstorms, the facilitator will call a break at this stage, because it is non-trivial to get correct, while being quite important.

The goal is to group the posts into groups that are likely to have similar solutions. I don’t have good advice here, but it is often a good call for the facilitator to ask the group if two things go together, if they seem to sound similar. More insight on this will come with experience[9].

5) The facilitator decides whether to continue:

The facilitator decides whether any of the posts require a more in-depth conversation. This will likely have become obvious in step 3). You can always check in with the group, if you’re unsure.

6) The facilitator invites dot voting to determine the order for further discussion:

If there are multiple items to address, the facilitator invites the team to come up and ‘dot vote'[10] on which items they think are most important. A good number to choose seems to be 1/3 to 1/2 the number of items to be voted on. If people complain about the number of dots, you can change this, or remind/tell them that they can put multiple dots on items.

7) The facilitator counts the dots and orders the items in dot priority order from highest to lowest

8) The facilitator brainstorms solutions in descending priority order:

Starting with the item which had the most dots:
a) Make sure everyone understands what the issue is. If this is really unclear, you can brainstorm a list of ideas to try to get to the root cause[11].
b) Brainstorm solutions. Some of these will have obvious actions and owners. For things which are not so obvious, you may want to dot vote again.
c) Make sure you clearly write down (and perhaps make into tickets) any actions which arise.

d) Continue until no items with dot votes are left, you run out of time, or your group becomes unengaged.

That’s it! You’ve now run your first Retrospective. Let me know what you think in the comments below!

[1]Wow, I write a *lot* about meetings…

[2]Stay tuned for a post about ‘Power to the Edge’!

[3]Our daily standups are trending to the long side these days, perhaps up to 10 minutes, but people seem to find them useful, specifically the conversations to solve problems that can more easily be initiated when you know people are already interrupted.

[4]It’s always nice when people update their tickets as they’re doing things, but it’s not necessary. We’ve had success with doing it in our daily standup.

[5]I am not joking. Try it with your team and see for yourself. I went to an auction at a gaming convention during my youth, and the item which went for the largest amount of money was a book to assist people in making character names. Making good names is *difficult*.

[6]’Just-in-time’ planning. This also feels like a separate topic for a post.

[7]This is a whole topic. I like this particular visualization, but you could see that many others could work just as well. The following [8] is another.

[8]There are a number of ways to draw this. It’s sometimes good to change it up, to help people think about things differently. Another popular diagram is a ‘speedboat’ diagram, with wind, anchors, obstacles, and goals as the four categories. It’s not an exact mapping to the above, which has it benefits and drawbacks.

[9]I should write about this, too.

[10]’Dot Voting’ is where you give each person a number of ‘dots’ that they can place on the things they’re voting on. In this context, we use it to choose which thing(s) to talk about next. Some people insist on only one dot from each person per topic, some are more flexible.

[11]’Getting to the root’ in a Brainstorm is a really interesting topic. It’s non-trivial, and deserves its own write-up.

Why Life Coaching?

A friend of mine recently posted a few questions about fb about life coaching. I felt that I had more to say than could be conveniently be expressed in a fb comment, so you’re getting it here.

The questions they asked were (mild editing for clarity):

0) ‘I wonder if now’s an opportune time for me to try it’
1) ‘General opinions, and beliefs about its effectiveness in various contexts’
2) ‘What can it do (for you, or more generally), and how does it do that?’
3) ‘How do I find someone really good and really compatible with me and my goals?’

0) ‘I wonder if now’s an opportune time for me to try it’

I’m a firm believer in the idea that the best time to do something is ‘now’. There’s a great story about a famous barbershop coach (Greg Lyne, I think). He was talking with the leadership of a chorus about him giving them some coaching, and they said something like “We’re looking for a five year plan to get better.” His response was “Why wait? Be good now!” Similar to Agile software development practices, you want to test your ideas and theories as soon as possible in as-close-to-real-world-situations, so that you can iterate on them. If you have an idea that might help you improve everything about you and your life, why would you wait to try it out, especially if it might take some time to ramp up?

1) ‘General opinions, and beliefs about its effectiveness in various contexts’

I feel like in our culture (and probably many others), it is considered a sign of weakness to ask for help. And yet, we do this every day. Every time that we exchange money for a good or a service, we are asking for help. You could learn to make your own shoes, or you could perform some task where you have more of a competitive advantage, receive money for that, and then exchange that money for shoes. By specializing[1] like that, we make our modern civilization possible. A Life Coach is a specialist in helping you achieve your potential, whatever that might be.

So, what is Life Coaching? I see it as:

– Helping you achieve clarity on your goals
– Helping you figure out how you are ‘getting in your own way'[2] of achieving those goals
– Helping you work through yourself to make progress and eventually achieve your goals

I’ve personally found it useful for ‘getting unstuck’ in job and career, for helping me unlock my love of writing, and for helping me set boundaries in various parts of my life. But I think the clarity it can bring is the key, and the foundation upon which all other things are built. If you know exactly what you want, and why, you can be so much more focused and effective.

2) ‘What can it do (for you, or more generally), and how does it do that?’

I think I’ve answered much of this under question 1), but I’ll go a little more into the ‘how’.

First, you want to figure out what your goals actually are. From my experience, this often includes some individuation and separation of your ‘social self’ (what others want from you) and your ‘essential self’ (what you actually want on the inside).

Next, you want to figure out how you are preventing yourself from doing these things. You may be plagued by self-doubts brought on by years of exposure to certain types of people, you may be a perfectionist who never starts anything because it will never be good enough, you may be spending all of your time trying to please others, and never taking any time for yourself. This seems to me like a very personal and individual process, involving a number of exercises designed to help you to better understand yourself and your interactions/experiences.

Then, now that you know your goals and how you’re preventing yourself from achieving them, you make plans and start to work towards these goals.

It’s an iterative and very personal process, but it can be tremendously helpful. As I mentioned above, I’ve personally found it useful for ‘getting unstuck’ in job and career, for helping me unlock my love of writing, and for helping me set boundaries in various parts of my life.

3) ‘How do I find someone really good and really compatible with me and my goals?’

Like finding a job or a life partner, good fit with a life coach is very important. I don’t have any easy rules to follow here. Ultimately, you’re at the mercy of your ability to judge people (and more importantly, how you feel around those people).

I would treat it as an interview, the type where you are interviewing them in the same way that they are interviewing you. See if the types of questions they’re asking might help you achieve clarity. See if they are expressing realistic expectations about what a life coach can and cannot do (you yourself need to be engaged, and it can take months). But perhaps most of all, see if you trust the person you’re talking to[3]. Do you feel comfortable talking with them[4]?

With all of the questions above, you can always just simply ask them of a prospective life coach, and see how they answer. You can glean a lot of how and whether they share your values, and how they will approach things. Read their website. Read any testimonials they may have.

If you trust your gut[5], and make sure it feels right, you should be okay.

I’m currently seeing Gorett Reis for life coaching, and she’s fantastic.

[1]And mass production, and whole host of other things. I understand this example is somewhat flip, but appropriate for the circumstances of this post.

[2]My Life Coach, my old singing instructor, and my Inner Game-reading performance coach used this same analogy. I think it’s a good one.

[3]I was lucky enough to have known my Life Coach for a number of years beforehand.

[4]Or, if you are not comfortable talking with people, do you at least feel more comfortable talking with them than other people you’ve just met?

[5]My first post in this blog talked about this concept, and I believe that learning to better trust and understand yourself is probably the best thing you can ever do.

Interview Questions: Behavioural and Situational

Balancing factors. Persuading people.

Yesterday, I talked about three types of interview questions:

‘Behavioural’ questions ask ‘Describe a time when you encountered a problem like this’.

‘Situational’ questions ask ‘Given this situation, how would you solve it?’

‘Technical’ questions ask ‘Solve this defined problem for me.’

Today, I want to talk about the ‘Behavioural’ and ‘Situational’ questions.

First, how are these questions similar?

Both of these are asking you to describe a solution to a problem, a problem from a surprisingly narrow set of options.

Two (or more) factors that you need to balance[1].

Helping people work together when they disagree[2].

The two factors might be technical, like how you would balance ‘Reliability’ and ‘Performance’, or they might be human, like Legal disagreeing with Marketing. Already, you can see these options blurring together. Really, these questions are really asking about how you balance things and make decisions.

The follow-up is often ‘So, once you made this decision, how did you implement it? How did you convince people that this was the correct route?’

Balancing factors. Persuading people.

So, how are these questions different?

‘Behavioural’ questions ask ‘Describe a time when you encountered a problem like this’.

‘Situational’ questions ask ‘Given this situation, how would you solve it?’

‘Behavioural’ questions ask you to tell a story about something you’ve done. You want to look at all the things you’ve done (especially everything you put on your resume), and think about what kinds of problems each of them were. What factors were you balancing there? How did you persuade people to work together and solve the problem?

An interviewer may ask you this question from a number of different directions. It’s up to you to fit one of your stories into the narrative question they’ve created (or to rephrase it such that your story fits).

‘Situational’ questions ask you how you would solve a hypothetical situation. An interviewer would present a situation with multiple factors to balance, where people disagree, and you would need to mediate, make a decision, get buy-in for your decision.

In this case, it again can be calling on your experience, but be careful that you’re actually trying to solve the problem presented, not a different problem that you’ve encountered before[3].

Summing up:

‘Behavioural’ questions ask ‘Describe a time when you encountered a problem like this’.
‘Situational’ questions ask ‘Given this situation, how would you solve it?’

In both of these:

Balance factors.
Persuade people.

To answer:

‘Behavioural’, fit a story from your past into the question.
‘Situational’, put yourself into their story, and tell them how you would resolve it.

Next time, we’ll look at the more ‘technical’ side of interviews. Stay tuned!

[1]If you didn’t need to balance between two things, you would just choose one of them, and really, no decision is required.

[2]If people are in agreement, what decision is required?

[3]Or something from your childhood, natch.

New Job, New Flows, New Structures

So you’re moving to a new organization. You know that what you will be doing will be different, you may even have read up on it.

But there are going to be all kinds of unexpected differences, and they’re likely going to come from the most unexpected directions.

Each organization has its own flows (I’m going to talk about software, as those are the flows I know best).

When an organization is writing software, there is generally some sort of version control-coding-testing-release pipeline. However, there are many different pieces of helper software for each of these steps.

There’s the flow of information as clients are using software. Information supplied by the clients, information supplied by your organization, and these all have to work together smoothly to solve whatever the client’s problem is.

The way that feedback from clients is turned into actionable items can be vastly different between organizations.

On the transition line between flow and structure, the way that teams are divided often reflect historical decisions made in antiquity, often the division of labour of the first few people writing the code for the first iteration of the product.

Information will be flowing through this system while the software is running, effectively handing off from team to team.

There will be structured and unstructured information flows in the organization. Many people are at their most effective when they receive all of their new information before it arrives through official channels.

Even the structured flow of information can be very different, for example in a very flat organization such as Valve.

So, be mindful, and watch for the different flows. You may be surprised at how different each organization is (or how similar).

What do Numerical Software Development Estimates Actually Mean?

What do numerical software development estimates actually mean?

What do they mean for you?

(I’m talking especially about team-based estimation, such as that in ‘planning poker‘, but I’m guessing whatever conclusions we may have would hold for other methodologies.)

I see the general objective here as coming up with a number for each task, and a number for how much your team can typically do in an amount of time, such that these numbers are reasonably fungible.

Traditionally, estimates would be given in ‘programmer days’, or ‘wall clock time’, depending on whether you had read ‘The Mythical Man-Month‘ or not[1].

More recently, there has been a back-and-forth between ‘amounts of time’ and some sort of dimensionless unit called ‘complexity points’.

Various teams that I had been a part of struggled with ‘complexity points’. In their strictest definition, something which was simple and repetitive would be worth few ‘complexity points’, even though it would take many hours of some attention or nursemaiding to finish the task.

Strict ‘amounts of time’ are no better, because each person does each task at a different rate.

We had the most success with ‘relative complexity’, or taking some small and large tasks, assigning them numbers, then rating each of the other tasks with respect to these goalposts.

Even this has its limitiations, though. Fundamentally, they question you’re asking when you’re deciding to put something into a sprint is ‘can we still accomplish everything if we include this?’. Because of limiting reagents (specific people who are bottlenecks for many tasks) and interdependence between tasks, this can be problematic. The standard way of getting around this is to insist that all tasks are independent and small.

This worked reasonably well, it’s just that sometimes you need to rewrite or refactor an entire application.

What are your experiences? How have you dealt with this question? How many points would it be worth to research and present on this topic?

(This post came out of a fb conversation with D about what estimation numbers mean, and have meant at various times.)

[1]One of the upshots of this is an observation made by someone at work (I think F) which was that Gantt Charts are excellent for deriving dependencies, but terrible for estimation.

New Divisions of Five Management Roles

Yesterday, we talked about five management roles:

Performance Manager (Worker Evaluation)
Estimatrix (Estimator)
Product Owner (Prioritization)
Scrum Master (Removing Obstacles)
(People) Development Manager (Development Conversations)

In a traditional corporate structure, these five roles are combined in one person (your boss).

However, there are many ways to divide these roles, and many reasons to do so (the simplest being that different people are good at different things).

Valve famously has an incredibly flat structure, where each person has a set of peers (the rest of the company) who handle performance management, and all of the rest of the roles are performed by each person themselves. As they say, occasionally teams will form with people splitting off into roles, but that’s all dynamically allocated by the people involved.

Your standard ‘Scrum‘ Agile shop will tend to put the ‘Performance Management’ and ‘Development Management’ into a ‘People Manager’. ‘Estimation’ is done by the team as a whole, the ‘Scrum Master’ or ‘Obstacle Remover’ is traditionally not the people manager, but is a separate role. The ‘Product Owner’ can be the ‘People Manager’, or someone else, sometimes an external product or project manager, but is generally not the same person as the ‘Scrum Master’.

I would argue that this tension between prioritization and removing obstacles is one of the reasons the system works better than many.

There seems to be a growing trend to separate Performance from Development[1], with some companies having separate reviews in different parts of the year for each of these. This can be especially helpful as many people are unlikely to be relaxed enough to think about how to take beneficial risks in the future when they’re tied up in knots about whether their boss wants to fire them.

I think it might make sense to push this to its logical conclusion, and have separate people for these separate roles in a company. The ‘Development’ role feels almost like a traditional HR thing, but I feel like to best serve employees, it would really need to be a separate department, called ’employee growth’ or something similar.

What do you think? What have you heard about how different organizations split these roles? How do you think they should be split?

[1]Development as in ‘where is your career going?’

Deadlines are a Clarity Crutch

I have a love/hate relationship with deadlines. At one point I said that the amount of work I do is proportional only to the number of deadlines I have, not proportional to anything else. (I think this is one of the reasons I favour daily 5-minute standups. They allow a daily reset of expectations, along with a deadline to work towards each day.)

So, deadlines proportional to accomplishment. Daily blogging something to show for your year something something etcetera[1]. But today I wanted to talk about the mental clarity that arrives as you’re approaching a deadline.

You have a task/deed to accomplish, you have a fixed time when it is due. As the time gets closer, the light cone[2] of possible ways to solve the problem shrinks. You push aside a large number of extraneous things[3], choose how solved you can get the problem in the time alloted, and get it done.

There’s the standard ‘good, fast, and cheap…pick two’. It feels like a lot of this clarity comes from having chosen the speed. As the time grows shorter, the number of ways you can now spend your mental focus budget on the task becomes manageable.

So, knowing this, how do we compensate? More frequent deadlines do actually seem to help, but that’s more of a forcing a solution, rather than relaxing into a solution.

What is it about the problem that is making you pause? Is your brain working on it in the background? (Does this mean the fallow time is necessary?) Are there parts you can hive off? Can you draw a large diagram? Can you put it in a spreadsheet or table?

Or perhaps the elephant in the room: If it is so difficult to find mental focus, what do you need to change about your environment?

[1]Until writing this I didn’t know that the ampersand ‘&’ was a ligature of ‘et’, and ‘etcetera’ was often written ‘&c.’

[2]Light Cones are also fascinating. I use them often in my mental model.

[3]In undergrad, we used to say that we enjoyed exam time, because we could push everything else away and focus, and not face opprobrium.

Five Management Roles

I was talking with my best friend earlier today, and we were comparing notes on some different management roles. Traditional hierarchical management theory[1] tends to have all of the management roles embodied in one person. This can be problematic, as very few people are good at all of the management roles.

This has led to a number of different techniques for dividing these roles among people. To start, we’ll talk about five of these roles, using Agile software development language, as that’s what I’m most familiar with:

Performance Manager (Worker Evaluation):

The ‘Performance Manager’ is probably the most traditional of the roles. When someone talks about their ‘boss’, it is generally the person who evaluates their performance, gives them performance reviews, and decides if they should get a bonus, a raise, or be fired[2].

Estimatrix (Estimator):

The ‘Estimatrix[3]’ is in charge of estimating the amount of effort required to perform a task or set of tasks. This role is often spread out over multiple people, even in traditional hierarchies.

Product Owner (Prioritization):

The ‘Product Owner’ is the other half of ‘traditional’ management. They are in charge of prioritization of the work being done, once it has been assigned to a team and estimated.

Scrum Master (Removing Obstacles):

The ‘Scrum Master’ (my favourite) is charged with removing obstacles. Once the team knows what it is working on, things will get in the way. Some of the obstacles are acute issues, associated with work being done, some of the obstacles are chronic issues, which are generally solved by trying to change habits, and many ‘restrospectives’.

(People) Development Manager (Development Conversations):

As a retention technique (and because it’s the right thing to do), many organizations spend time on development of their employees, helping them figure out what they want to do with their careers, and helping to find them ways to develop while doing their job.

Tomorrow, we’ll look at some ways these roles are remixed.

[1]It’s really more of a default.

[2]Like user stories, anytime your description includes the word ‘and’ or ‘or’, it means you can subdivide it further. That is left as an exercise to the reader, if they are so inclined.

[3]I really enjoy this suffix.

Running A Sprint Planning Meeting

It’s the little things that sometimes make a difference. When I was teaching standardized test math so many years ago, I noticed as I was drawing problems on the board, all the little habits that I had picked up. Habits which make solving problems easier, habits which reduce the chance for error.

Things like the curve on the leg of the lower-case ‘t’, so that it doesn’t look like a ‘+’. Curving your ‘x’ so it doesn’t look like a ‘*’ sign.

I think some of this (probably sometimes annoying) attention to detail had carried over to Sprint Planning meetings[1].

Planning Poker is a method for a group to converge on a time estimate for a task or group of tasks. There are a number of ways to do this. The ‘canonical’ way we were taught to do this was to use Fibonacci-numbered cards (1,2,3,,5,Eureka!). This involved a discussion of the task(s) to estimate until everyone had a reasonable idea of their complexity, then each person would choose a number estimate, all of which would be revealed simultaneously, to hopefully reduce bias. The discussion before estimation would not include estimates of how long things were estimated to take, to also try to reduce bias.

While we were running our planning meetings, I noticed that we would start to slip away from this ideal, perhaps because certain things were not important, perhaps because we didn’t see that certain things were important. For example:

We moved from cards to apps, and then to fingers. Using apps for estimation is less annoying than finding the cards each time, but fingers are even faster to find. I/we tried to get around the bias effect by having everyone display their fingers at once, and that worked reasonably well. Even making each person think about their estimate before display can help a lot with reducing the impact of what others might think of them.

One thing I tried which never really caught on when other people were running the meeting was saying ‘A,B,C’ instead of ‘1,2,3’, with the idea that it would be less biasing on the numbers people were choosing. (This may have mostly been an impression of mine, as the moving of the estimate from a mental number to a number of fingers may cement it in a slightly different mental state…)

If one is not careful, and perhaps somewhat impatient in meetings[2], one can start suggesting estimates before they are voted on. It can take considerable discipline and practice to not do this.

Another thing I noticed was how difficult JIRA was to use when one is not practiced in it, especially in a room with many people watching. Something that any experienced[3] demo-giver would know like the back of PowerPoint’s hand.

That’s all I have for now. For more minutiae, tune in tomorrow!

[1]For those of you who have not had the pleasure, these are the meetings at the start of an iteration, where the team sits down in a room, estimates a bunch of priority-ranked tasks, and decides (generally by consensus) how many of them they will commit to getting done in the next two weeks. Like all meetings, they can be good or bad, and the meeting chair (I feel) can make a large difference.

[2]I am probably as guilty of this as anyone. I would recommend Randy Pausch’s ‘Time Management‘ for those who feel similarly.

[3]Read: ‘Battle-scarred’

What are your Non-Negotiables?

What are your Non-Negotiables? Most recently, I was talking to someone[1] about my New Year’s resolutions, and we were discussing why I had done one of them, but not the other two. It eventually came out that the resolution that worked (writing every day this year[2]), worked because I had made it a Non-Negotiable[3]. I had resolved that no matter what, every day this year, I would write something. Somehow, every day, I would carve out an hour or two, pushing other things aside so that I could focus and write.

(Incidentally, this practice focusing has done wonders for me, helping me find ‘the zone’, or ‘flow’ much more consciously and easily.)

Sometimes I would push aside a computer game, or facebook, sometimes sleep, but those things didn’t matter compared to the commitment I had made (mostly to myself) to write every day.

Interestingly, the other Non-Negotiable that came to mind today was the 5-minute standup. I was talking to someone about it today, and they started to say ‘5-10 minutes’, and I had to interject, with talk of Non-Negotiables, how if you let something like that slip, pretty soon you’re having daily half-hour sit down ‘stand-up’ meetings.

Interestingly, biking to work every day is not quite a Non-Negotiable. I take probably a couple of weeks off each year, some for snow, some for rain, some for events. It’s pretty close, though, and I’m not so worried, because I’ve been doing it for long enough (14 years, I think), that it’s a pretty deep-seated habit.

So, what are your Non-Negotiables? What is the one thing you want to change this year?

[1]Pretty sure it was G at a life coaching session, but my brain has this annoying tendency to abstract things away, but that’s another post. I also remember it from a speech by the head counselor at music camp many years ago, but that’s another story…

[2]At least so far…

[3]This is a good precis from a life coach on Non-Negotiables.