Time-boxes, goals and realizing outcomes

Goal is defined as:

the end toward which effort is directed” or “the object of a person’s ambition or effort; an aim or desired result.

I don’t understand the debate over the Sprint Goal.

I also don’t understand how a teams can function and focus without goals (be they implicit or explicit although I would suggest that there is a danger in not making goals explicit).

If a team carves out a fixed set of time (a time-box) to do some work, they already have, albeit implicitly, established a goal i.e. completing a certain amount of work in a certain amount of time.  I don’t consider this type of a goal to be a best goal we could come up with because it’s output focused and you know I favor outcomes over outputs.  I will concede however, that this type of goal is probably better than no goal at all.

From the Scrum Guide, the Sprint Goal is:

an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.

Seems pretty straightforward to me with a lot of latitude for the Scrum team to create their goal.  What do you think?

If your time-boxed work period has no goals, no aims, no objectives, no desired end what exactly is your team doing?  Where are you headed?

(I’m pretty sure some folks reading this are thinking to themselves that time-boxing is an archaic practice and should be dropped altogether.  Stay tuned for my next post).

And while this post has focused up till this point on teams working with time-boxes, I will go even further to suggest that any team that is developing and delivering software in support of a broader organizational vision – yes I’m looking at all the teams that say they are using Kanban out there –  that doesn’t have time-bound (see Agile Manifesto Principle #3)  goals is operating irresponsibly.

Goal are very useful.  Use them wisely.  Use them well.

Advertisements

Agile Is Not The Goal

Or is it?

Ok, it isn’t but I’m tired of reading posts or comments via various outlets that try to remind us that business agility  (or whatever) is THE goal and Agile is not.  While there is truth in that, I believe that such statements lead to the proverbial baby being thrown out with the bath water and we end up with faux Agile – afterall it isn’t THE goal is it?

I play the piano.  I’m in the middle of learning a jazz arrangement of “Georgia” and I have THE goal of peforming the piece by the end of the year.  Let me repeat, THE goal is to be able to perform the piece by the end of the year. In order to achieve THE goal, I actually came up with a goal of practicing the piece daily.  (This goal has basically led me to get up at 4am for the past couple of days to practice).  If I don’t meet the goal of practicing daily, THE goal of playing “Georgia” by year end is in jeopardy. Practicing daily is a goal I have to meet if I want to achieve THE goal. It’s that simple.  Now it’s really easy to making practicing daily THE goal and lose sight of the original goal.  If I do that, I probably won’t be performing “Georgia” at the end of the year as well.  So I recognize that “practicing daily” is a goal I set to help me achieve THE goal of performing the piece at the end of year and ensure that my daily practices help me get closer to THE goal.

If you believe Agile (as in Agile Manifesto Agile) will help you achieve THE goal (whatever your goals are), then employ Agile (as a goal) such that it helps you achieve THE goal.  If you don’t think it will help you achieve THE goal, don’t use it.  It’s that simple.

Or is it?

A Town Called Commitment

In honor of Doctor Who being back on, I thought we should talk about a town called commitment.  This is a town where everyone goes around making commitments to one another.  One day, Madame Mayor called for a town meeting.  At the beginning to the meeting, she said, “I commit that we will get through all the agenda items we have today…”.  Just as she finished speaking a blue telephone box with the words Police Box began to materialize in the middle room…..

Tardis Tour Wales 2013 (2)

Recently, I suggested that estimates are not commitments and advised that when teams are asked for estimates, they should make an effort to understand if they are truly being asked for a commitment. Simple, right?  Well, not so fast my friends.  Commitments are an interesting thing with implications and ramifications on both individual and team behavior.

I once heard the story of a man who made the commitment to his dying wife that he would never remarry because he loved her so much.  Years later, he met someone he feel madly in love with.  What do you think happened to his commitment?  If you make a commitment to attend a friends wedding, you are pledging to be at that friends wedding.  You have made a promise (yes a promise) that you will do whatever you can do to be at your friends wedding.  That’s a commitment.  When we make commitments, we are implying that we have a lot of control over the final outcome.  Some of you reading this are probably thinking that I’m taking this commitment thing a bit too far. Um, I don’t think so.  My experience in life would suggest to me that when people say they are making a commitment to something, those who hear the commitment are largely interpreting it as a promise for the individual to do what they have said. This is why there is disappointment and frustration when commitments are not met.

Others may read this and say that anyone who sees a commitment as a promise (or something similar) is making a mistake and shouldn’t. But why shouldn’t they? Isn’t that at the end of the day what a commitment really is?  Why would we attempt to redefine commitment in certain contexts?

Commitments inherently runs the risk of not being met.  That is just a fact of life.  Inclement weather can hit your town grounding all the flights and making it impossible to get to your best friends wedding.  You can meet someone you fall madly in love with and remarry.  What you thought would be a few lines of code changes turns out to be something much more involved.  Things happen.  Things happen every day. It’s important to realize that the more people that are involved in making a shared commitment, the larger the risk of it not being met. (This is another reason for small(er) teams in software development but I digress).  After playing team sports for most of my life at a pretty competitive level, I learned that lesson the hard way.  This is why you’ll rarely see a coach commit to wining a game (outcome) and most players would hedge on doing so.  I mean we all saw how it ended for LeBron and Heat after promising “…not one, not two, not three…”.

Commitments also come in conflict with one another.  Making a commitment to one thing very often impacts commitments to something else. Daily, I have to excuse myself from one meeting I committed to in order to attend another.  Its not uncommon to ask a team to be committed to quality but then also ask them to commit to delivering X number of stories in an iteration – which commitment do you expect them to honor when there is conflict (and there will be a conflict)? The quality commitment or the number of stories commitment?

Commitments made too early can also lock us into a solution prematurely and prevent us from exercising other options that we may have had.  We see this when teams make a wholesale investment in a particular solution to a problem making impossible to leverage any of the other options on the table. (Yes enterprise/solution architects, I am talking to us).

This is the very reason why we should be careful what we make commitments on and when we make those commitments.  In knowledge work (and software development in particular), I suggest considering the following when thinking/talking about commitments:

  • Do not make goals, commitments
  • Have (and understand your) options
  • When (and if) you have to make commitments, make them at the last responsible moment
  • Choose commitments to behaviors and causes over commitments to particular outcomes
  • Consult people before committing them to a cause or outcome
  • Don’t make a commitment  you don’t think you can keep
  • When you make commitments, do your best to honor them

I had started this blog post before I read http://commitment-thebook.com/ but I would encourage anyone who hasn’t read the book to do so.  Some insightful nuggets are contained within it.

Commitments are valuable and precious, use them wisely.  Now that sounds like something the good Doctor would say.

 

Credits:

Photo of Tardis: By Rept0n1x (Own work) [CC-BY-SA-3.0 (http://creativecommons.org/licenses/by-sa/3.0)%5D, via Wikimedia Commons”

 

Buyer Beware: Targets May Be Harmful

In knowledge work, we love metrics.  Everyone wants to capture them, managers want reports via shiny dashboards.  We say we need them to make decisions or better yet, influence behavior.  They are the basis of target setting.  If you have no targets, it really doesn’t make sense to have metrics.  Yet your targets may be hurting you in ways that you cannot even imagine.  As Eli Goldratt said:

Tell me how you measure me and I will tell you how I will behave.

Whenever we give people targets for them to meet, we are invariably sharing with them their performance unit of measure. When they understand what is being used to measure their performance, behaviors are modified as a result but the wrong behavioral modifications can adversely affect an organizations ability to succeed.  In fact, the wrong behaviors can be devastating.  There is so much information on this that its quite disconcerting that managers are still being tricked into doing the wrong thing.  Check out the work of Deming, Ackoff, Goldratt and Seddon for starters.

If you’re in the software development space, this next story may resonate with you.  We had a drive where we wanted to get our bug count down and so teams (and individuals) were tasked with closing a certain number of bugs daily.  The metric was “bugs closed per day”.  At the end of the exercise however, we determined that although we met the goal of bugs to be closed, we had introduced a brand new set of bugs that were just as bad (or in other cases worse) than the ones that had been previously closed.  Because we were so focused on closing bugs, we did not pay attention to new ones we were introducing.

But the example above does not just apply to product development.  We find targets (and the related metric) that alter behavior in all walks of life.  Asking doctors to see a certain number of patients a day, telling police officers to give a certain number of tickets a month, setting targets for auditors to perform a certain number of audits a day, challenging developers to bang out a certain number of lines of code an hour inevitably leads to these individuals modifying their behaviors as a result of the target.

Deming’s System of Profound Knowledge (SoPK) challenges leaders to have some understanding of psychology.  We need to know what influences peoples behavior and motivates them.  It’s been said that the best motivator is the manager who is not demotivating.  Yet we find many of targets that we set end up demotivating because they take the joy out of the work.  This happens because of one of the following occurs:

  • Targets are met but desired outcome is not. Like in the example above, the bug count went down but quality did not improve.
  • Targets are not met, let the blame games begin.  When we cannot meet our targets, our natural instinct is to look for someone else to blame.  I’m sure the “system does not work” resonates with a few of my product development friends.  Someone else is always to blame.
  • Targets are flat out unreasonable.  There is no way they could be meet under the current circumstances and setting them was unrealistic.

So are targets (and metrics) completely evil?  I don’t think so.  But the wrong target can be completely debilitating.  So here are some guidelines on setting targets (if you must).

  1. Choose the right target.  The outcome that is desired has to be explicit and made known to everyone.  In sports, the outcome for any team is to win their league.  For a software development team, it may be to have a quality product.  For a police department it may be to reduce the number of accidents on the freeway.  There are always outcomes that for which that entity exists and must meet continue to meet for the entity to remain viable.  The relationship between a target and desired outcomes should be direct and not inferred.  If a certain amount of money must be brought in weekly for a business to stay afloat, that number should be available to everyone who can influence it.
  2. Engage the team in target setting.  When the team fully understands what the outcome needs to be, they will be able to provide suggestions regarding what the targets should be given the constraints. When they are engaged, then they are invested and then there really cannot be excuses.  Don’t insult your workers by hiding this information from them.  If you think they are not capable of processing it, then you need to leave because you hired them in the first place.  But if you hired good people, trust them to help you set the proper targets.
  3. Revise targets when needed.  No condition is permanent.  As the landscape changes and the organization learns and evolves, targets may need to be revised (or even changed).  Don’t fall in love with your targets.  They are not an end in themselves.

Take a look at the targets and metrics your organization has created.  Are they meaningful?  Are they encouraging the right behavior?  Are they motivating the workers?  Are they creating organizational success?  If they are not, toss them out.  It’s time to revisit the drawing board.

I’ll leave you with this….

Strategy review – are your goals still in sight?

Organizations have goals – some are questionable – but are goals nonetheless.  Once goals have been identified, a strategy (or some would say a plan)  for reaching the goals is established and put in place.  Most goals are not met accidentally.

Goals tend to have permanency associated with them.  Goals generally do not change till the goal itself is met.  When an organization changes it goals, it’s changing its purpose for existing.  This may be a good thing, but I have not seen this occur a lot.  This is not to say that goals never change, its to say that goals generally remain static.

Strategy for meeting goals is defined based on current context.  It’s highly dependent on the information available to the strategist at the time of strategy definition. While history can be taken into consideration, the future is unknown and any information based on the future is speculation at best.

A simple example for this is this: If I want to  have a goal to visit a friend that lives on the other side of town, figuring out how I will get to his place, is defining the strategy.  I can check the weather, get on Google maps and look at traffic, call him to find out if he’s at home, review the traffic incident rate on the route, see how much gas is in my car etc etc.  These pieces of discrete information are the variables that help me define a strategy for driving across the metro to see my friend.

Interestingly enough, unlike goals, even the best of strategies exhibit big time volatility. This is because the variables that influenced the strategy are volatile.  These parameters that influence strategy are subject to change due to external change agents. New information invalidates old information all the time.  Strategy does not live in a vacuum, it is influenced by changes happening all around.  But this is not new to anyone, in our daily lives, we see this all the time.  We plan for something based on information we had but as things play out, we see that the information changes.  As a friend of mine once said, no wedding goes as originally planned.

In spite of this reoccurring phenomenon, we still find organizations wedded to a particular strategy and the one-time snapshot of information that influenced such strategy.  Dare I say, that the field of “project management” as practiced by many is focused on keeping to the original plan regardless of what changes are going on around us. (Sorry my PM friends).

For some spaces, this approach may be legitimate – and I’d love to know which areas you’ve seen this make sense.  But for many organizations something more dynamic is needed.  Instead of project management (or governance as some organizations refer to it) and the insistence on conforming to a plan,  strategy management (I don’t like the word management in of itself and need to find a better word) is needed.  Strategy management focuses on reviewing the new information an organization has and determining how this new information impacts the defined strategy (plan) and ultimately the goal.

Strategy management accepts that fact that our environments are complex and hence are full of uncertainty.  Based on this, we need to focus less on long-term plans and focus more on frequent planning.  To quote President Eisenhower:

In preparing for battle, I have always found that plans are useless but planning is indispensable

This becomes quite interesting when applied to the use of technology as a business accelerator within an organization.  It’s unfortunate that many organizations have no way of quantifying how technological innovations impact organizational goals.  The technology strategy of an organization needs to be reviewed often to ensure that it is still in line to aid in meeting the outlined goals and that the best investments are being made.  A system-wide view needs to be taken to ensure that everything that needs to be considered is serving as input into determining what needs to be developed.  Kanban has a practice referred to “Operations Review” – maybe that is something your organization should consider implementing as a means of reviewing the overall strategy.

Here is the summation of the matter, define your goals and develop a strategy based on what you know.  Continually review the strategy and develop new strategies as changes occur because they will.

Adebayor Goals

via Arsenal Action.

I personally think he’s nowhere close to fulfilling his potential, but I doubt he’ll do it at Arsenal.  If he really wants to leave, they should let him go.