note-2

In Software Project Estimation: Fantasies I said that a budget, estimate or even a plan was not a price.  After the publication of that essay I had a follow up conversation with a close friend. He said that in his organization the word estimate is considered a commitment, or at the very least a target that all his project managers had to pursue. YEOW! He is playing fast and loose with the language and therefore is sending a mixed message.

A commitment is a promise to deliver.  An example of a commitment I heard recently as I was walking through the airport listening to the cell phone conversation of a gentlemen walking next to me was “I promise not leave the sales review until the end of the month.”  A commitment indicates a dedication to an activity or cause.  The person on the cell phone promised to meet the goal he had agreed upon.

What is a target? In an IT department a target is a statement of business objective. An example of a target might be “credit card file maintenance must be updated by January 1st to meet the new federal regulation.” A target defines the objective and defines success.  A target is generally a bar set at a performance level and then pursued.  Another example is “I have a target to review six books for the Software Process and Measurement podcast in 2014.”  Note six is two more than we did in 2013 and represents a stretch goal that hopefully will motivate me to read and review more books.

Simply put, a commitment represents a promise that will be honored and a target is a goal that will be pursued.  An estimate is a prediction based on imperfect information in an uncertain environment.  An estimate, as we have noted before, is best when given as a range. Stating an estimate as a single number and adding the words “we will deliver the project for X (where X is a budget or estimate) converts the estimate into a commitment that must be honored.  Consider for a second . . . if a project is estimated to be $10M – $11M USD and a team finds a way to deliver it for $7M USD, would you expect them to find a way to spend the extra money rather than giving it back so the organization can do something else with the money? Bringing the project in for $3 or $4M less than the estimate would mean they had not met their target or commitment. Turning an estimate into a commitment or target can lead teams toward poor behaviors.  Targets are goals, commitments are a promise to perform and an estimate is a prediction.  Targets, commitments and estimates are three different words with three different definitions that generate three different behaviors.

11260612594_d1715b07ca_b

It is that time of year!  Time to celebrate what worked and what didn’t (and yes I said celebrate what didn’t work – without experimentation there is no growth!) I have compiled the top five essays and top ten interviews from the 2013 ‘ish.  Today we celebrate the essays.  The top five most downloaded essays were:

SPaMCAST 219 – Agile and Risk Management
SPaMCAST 217 – Metrics Minute, Automated Test Cases Passed
SPaMCAST 231 – Metrics Minute, Burden Rate
SPaMCAST 247 – Sprint Reviews and Demonstrations
SPaMCAST 255 – Project Management Is Dead, Pries – Checklists

 

Click on the link to listen to any that may have missed.

The trend I see in these five essays is an interest in advice that can be immediately applied by teams and change agents.

Three of the essays that I got the most out writing that did not make the top five were:

SPaMCAST 263 – Transactional Analysis
SPaMCAST 239 – Commitment
SPaMCAST 251 – Commitment, Revisited

 

These essays were about building base knowledge about how work is done.  These essays were less tactical and more strategic in nature.  Both the tactical and the strategic are needed for a complete picture that benefits teams and change agents.

We are currently counting down the top ten interviews and will provide SPaMCAST listeners and readers with a complete list on 1 January 2013.  I hope your holiday season is meeting your expectations.

Notes:  I complied download statistics for podcast released between 1 December 2012 and 30 November 2013.  SPaMCAST specials, for example the downloadable copy of the SNAP Counting Manual, were not included.

Marine Corps Marathon 10k

Marine Corps Marathon 10k

Motivational Sunday

Here’s an interlude from our re-read of the The Seven Habits of Highly Effective People for the festivities around the Marine Corp Marathon 10K and a reflection on the difference between commitment and habit.

Commitment and habits can be positively interrelated. Commitment is being dedicated to a cause or activity.  Habits reflect a more or less fixed routine. The combination of commitment and habit is beneficial if the commitment is to a positive goal and habit does not become obsession. Once it is established, the combination can go into autopilot. In my world, running reflects a positive combination of commitment and habit.

Once upon a time I started running to cope with life as a road warrior.  It began as form of exercise. When you begin to confuse a french fry with a vegetable, an eye exam and exercise are necessities. That was approximately fifteen years, sixty pairs of running shoes ago and many blisters ago.  Over time the initial commitment developed into a habit and I had become a runner.  My formula:

  1. Start small and build – I began running the distance between two telephone poles then walking. Overtime time that became run two, walk one then walk three, walk one then suddenly it became 13.1 miles.
  2. Repeat again and again – Simply put, I run nearly every morning.
  3. Don’t let the day get in the way – I run first thing every day at approximately 4 AM.
  4. Rewards and feedback – The races have become my reward and feedback mechanism.  Starting a race with a few thousand of your newest and closest friends is stirring.
  5. Commit to yourself – The only person that will be able to hold you accountable is you.  Give yourself permission to hold you accountable by committing to yourself to achieve your goal.

The downside? I woke at 2:30 AM this morning in anticipation of running the 2013 Marine Corp Marathon 10K. I was keyed up. My commitment and habit has combined and become something more – passion. Even on the days when it is wet and chilly, even when the morning comes way too early. Over the years I have found that the most powerful commitments are those you make to yourself and then find a way to engage the human version of autopilot, habit.

Commitment, Motivation, Results and Trust, An Equation.

Commitment, Motivation, Results and Trust, An Equation.

 

Teams and the behavior of teams are critical to delivery of any project. Successful methodologies or frameworks direct activities in order to reinforce behaviors that generate trust in the team’s ability to deliver value. Having teams plan and commit to the work they can deliver generates motivation that will yield results, which will build trust. This is the chain reaction that will deliver value and customer satisfaction.

When a team is able to commit to work in small increments, as in Agile,  it is more apt to understand how to actually deliver. When teams commit and deliver using short cadences (for example, delivering every two weeks) the team can use its own performance to fine tune their future promises. The ability to use performance information in order to do that fine tuning helps the team to deliver on its commitment and make more accurate commitments in the future. So the virtuous cycle continues.

The ability to commit to specific pieces of work with a good chance of being able to deliver it generates motivation. Agile techniques and frameworks provide teams with the mechanism to say what they will deliver. When they then deliver against that commitment, it creates a feedback loop that helps the team build motivation.

A motivated team, with a good understanding of the functionality they have committed to, will have a much higher probability of delivering the results that the organization needs. Organizations fund projects for one reason and one reason alone – results. Process, techniques, methods and frameworks need facilitate the team’s ability to deliver results.

The whole process of a team committing to work, delivering results against that commitment and learning from feedback generated by performance, builds an environment where the organization can trust the team do what they say. Any technique, framework or methodology should be engineered to build motivation, results and trust.  All of these attributes begin with the team being able to understand and commit to the work and then to be able to refine that commitment based performance and results.  In the end, we do projects to deliver results. Therefore our processes need to facilitate the delivery of results.

Getting to graduation reflects commitment and learning.

Getting to graduation reflects commitment and learning.

Every project is a learning activity, whether the project is a simple maintenance activity or the most complex development project. In every case we are looking for a means of solving a business problem. Alistair Cockburn in his keynote at the Scrum Gathering in Las Vegas, 2013 rephrased the oft repeated Agile and lean start-up catch phrase, “fail early, fail fast” as “learn early, learn fast.” Agile attacks the concept of learning early by breaking work into small components and having the team commit to tackling those components a piece at a time. The benefit is derived by getting to functionality early rather than waiting until late in a project to know whether the right functionality has been developed, or even, if it can be developed. The earlier we answer the questions we have about how and what we are doing the better. The Agile techniques of breaking work into small components, then tackling them in a manner that returns the greatest amount of early learning is a risk reduction mechanism.

In Learn Early, Learn Often” Takes Us Beyond Risk Reduction[1], Alistair Cockburn suggests that all projects seek to answer four questions.

  • How can we learn to build what is desired?
  • How can we learn how much it will cost (time, money, people)?
  • How can we accelerate the team learning how to work together?
  • How soon can we correct the mistaken assumptions in the design?

Agile provides us with a set of mechanisms to develop answers to these four questions early in the project. Story writing and backlog grooming takes larger components and breaks them into pieces of work that can be taken into a sprint and completed. This supports getting to done and then to feedback as a tool for learning.  The act of committing to the work, saying what you are going to do and then doing what you said, provides both transparency and a feedback mechanism. Transparency lets stakeholders understand how the team is attacking the work to solve the business problem and at the same time how the team is progressing. The act of delivering and demonstrating/reviewing work at the end of every sprint generates feedback which can be translated into knowledge and learning.

Agile supports a culture where commitment and learning not only can co-exist but actually work best if they do co-exist. If we view every project as a potential risk that can only be mitigated when the right business value is delivered, then each project represents a set of decision points where feedback is required to guide the work towards value. The impact to overall project risk reduction based on learning early in the project what will work and what won’t work or what the real business needs are, will increase the potential for the project to succeed. Committing to deliver complete units of work at the end of every sprint puts the team and the stakeholders in position to understand unknowns that cannot be exposed without hands-on exploration. The combination of commitment and learning early lowers the risk of delivering and then being surprised.


[1] How “Learn Early, Learn Often” Takes Us Beyond Risk Reduction , July 3, 2013, http://alistair.cockburn.us/Disciplined+Learning

Punishment after poor behavior does not keep kids off the cliff!

Punishment after poor behavior does not keep kids off the cliff!

Feedback is a tool to help teams stay on track not only in terms of functionality, but also in terms of meeting organizational expectations of quality and delivery rate. Rewards, as discussed in Daily Process Thoughts, July 1, 2013 can enhance commitment. When rewards are discussed, or used, someone will voice the idea of punishments as a mechanism to enforce commitments. Punishment and its cousin, blame, create a team environment where making commitments is at best dangerous.

Agile teams make commitments based on the needs of the Product Owner (prioritized backlog) and their capabilities. All teams will occasionally miss a commitment because “things” do happen, but “things” should only happen occasionally. When teams fail to deliver on their commitment more than occasionally or missing their commitments becomes the norm, something is broken. Consistently missing commitments reflects a team problem (people, capabilities or process), or an organizational issue (for example, a mandate versus a commitment). A well-oiled Agile team will tackle team-related issues either during their periodic retrospective or in an impromptu retrospective, however a well-oiled Agile team will not fail to meet their commitments on a regular basis. Punishing a team for missing a commitment does not help them solve the problem, but rather puts pressure on the team to react by finding someone or something to blame. Enter  the Agile coach. When teams can’t help themselves, an outsider can be very helpful to get the team back on track.

Many IT organizations have had a history of fixing the triple constraints, i.e. dates, scope and resources, then dictating or “negotiating” with IT to meet those dates. The act of dictating the date and scope draws a hard line that teams can be measured against and performance judged. When teams feels that the pressure is artificial, team motivation and commitment is damaged. Even where the triple constraint is “negotiated” the negotiation is often subject to power mismatches (for example consider the organizational power of a project manager and a business executive or CIO) or based negotiation biases (such as anchor bias, I will tell you when I want it and then we will negotiate). Regardless of good intentions commitments in these environments are much closer to mandates than they reflect team capabilities. By stepping away from commitments based on capabilities, teams become more inclined to sweep problems under the rug while desperately trying to makeup time until they can no longer hide from impending doom. Once the cliff becomes clearly visible, negotiation starts followed by the official act of pointing fingers in a vain attempt to avoid punishment. An Agile coach (external in this case) is generally needed to help the organization recognize and find solutions for the systemic problems that cause teams to consistently miss their commitments.

Drs. Larson and LaFasto[1] found that the many of the characteristics of highly effective teams revolved around being goal and principle driven. As we have noted in previous Daily Process Thoughts commitment, motivation and teamwork are highly inter-related. The fear of of punishment generally does not improve a team’s performance in meeting their commitments, but can generate a number of negative behaviors that include: sweeping problems under the carpet, trying to negotiate away the commitment or spreading the blame. None of these behaviors delivers more value to the organization. Punishing teams  has drawbacks, whereas rewarding good behavior provides reinforcement. When needed coaching teams and organizations through bad behaviors gets teams delivering value faster and more consistently.


[1] Larson, C., E., LaFasto, F., M., Teamwork: what must go right / what can go wrong, Sage Publications, 1989

Public recognition provides motivation.

Public recognition enhances commitment.

Agile puts people and teams at the center of the development activities. Putting people at the center of the development means that commitment, motivation and teamwork are important characteristics for team effectiveness. Organizations often use rewards to reinforce commitment. Commitment, motivation and teamwork are highly interrelated and if you positively impact one all three will be impacted. Organizations typically embrace a wide range of reward structures ranging from money (e.g. cash and bonuses), giveaways (e.g. dinners, lunches or iPads) to public recognition (internally and externally).

Money is the motivational tool of choice for many organizations. The delivery mechanisms include additions to salary or bonuses. It is popular because it is generally the easiest reward to deploy. However, the problem is that it is not one of the most effective mechanisms to generate commitment or motivation for IT personnel. In a 1981 study, Dr. Barry Boehm published a ranking of the top ten motivational factor for software developers[1]. They were:

  • Achievement
  • Possibility for growth
  • Work itself
  • Recognition
  • Advancement
  • Technical supervision
  • Responsibility
  • Relations with peers
  • Relations with subordinates
  • Salary

While arguably bonuses or salary changes do have a motivational impact, the mechanisms for delivery are generally secret which reduces the potential positive benefits of recognition. For example, giving a bonus to someone might provide some personnel recognition, but if the bonus is not public there is little reinforcement of that recognition. When given a normal course of business, bonuses and salary adjustments tend to be viewed as entitlements. Also, when bonuses are competitive, they can pull teams apart as team members compete against each other. The motivation becomes to get the money, rather than than to the value that the team delivers. Some organizations try to temper the potential downside by granting the same bonus or salary increment to the whole team. I personally have never seen this tactic drive long-term motivation .

Another typical and easy reward mechanism, similar to the bonus, is the giveaway or gift. The organization grants a team dinner, lunch (paid for by the company) or the team or individual members might be given a gift certificate for a night out (it can be very effective to include enough for the spouse or significant other). This technique has the advantage of being easy to deliver and easy to make public, it allows the organization to invoke the benefit of public recognition. A twist on the dinner or lunch reward is to have the project sponsor, or another relevant senior leader, act as the master of ceremonies. The senior-level participation increases the recognition component of this activity. As a side benefit, involving the families or significant others of team members can also increase team bonding. For example, I still remember warmly an event several years ago where a senior business stakeholder “threw” a picnic for the team and all family members one Friday afternoon. It was the day I learned how to play cricket. The team recognition from the sponsor was heartfelt and not perfunctory. The team would have done nearly anything for that sponsor. Gift cards for a local eatery would not have had the same impact.

In Boehm’s hierarchy of motivators, achievement, doing cool things and recognition ranked at or near the top of the list. Almost any of the motivators is improved by recognition. To be effective, recognition needs to be for a real achievement. In the business world, not everyone gets a blue ribbon for just playing, and rarely do achievements like perfect attendance rate public recognition. Consistently delivering business value and high customer satisfaction are  worth recognition. Like before, a twist that makes recognition even more powerful is having that recognition delivered by the business sponsor or relevant senior executive. Recognition works on many levels building self-esteem (TA or Transactional Analysis is on the list topics for the Daily Process Thoughts), team esprit de corps (recognition reinforces the value of team behaviors) and trust (delivering on commitments is important for building trust).

Organizations use a wide range of rewards to reinforce commitment with varied results. The results of rewards on commitment and motivation are rarely measured. And in many cases, the techniques that are used are not the most effective, but rather the most expeditious. On Maslow’s Hierarchy of Needs, most IT practitioners and teams would be closer to the top of the hierarchy (self-actualization), than to the bottom (physiological needs – food and shelter). This suggests that rewards that focus on self-esteem, recognition and achievement will have a larger and longer term impact on team’s commitment and motivation and teamwork.


[1] Boehm B. W., Software Engineering Economics, Prentice Hall, 1981

Commitment makes decisions stickier!

Commitment makes decisions stickier!

On January 1, 2013 I began an experiment. I committed to writing and publishing a significant blog entry coupled with a picture every day for a year. Today is June 30th, pretty close to the middle of the year (day 181 of 365) and I thought it would be interesting to reflect on the power of making a commitment and following through on that commitment.

I have enjoyed writing since high school. I co-authored a book and have published many articles. For the past ten years I have even gone so far as to have a daily writing assignment as a task on my Outlook calendar. I checked the box most of the days and I was able to complete an essay on a fairly regular basis. The public commitment to deliver a whole idea on a daily basis was a major step outside of my comfort zone and reflected a real decision. The commitment was to a goal without the possibility of failure. A real decision to make this goal happen. It has not been easy. I traveled to China earlier this year; WordPress is partially blocked in China. There have been several days when it would easier not stay up until 11:50 PM desperately typing or looking for just the right picture. Making a real decision to commit and then to follow through has power. Committing to delivering complete, shippable product makes the commitment even more powerful by defining the hurdle.

The act of delivering a blog entry every day has led to a number of innovations. The idea of Motivational Sunday and Hand Drawn Chart Saturday appeared sometime in February. Weekly topic arcs appeared after a discussion in a coffee shop in Rosslyn, Virginia a few months ago.  Making commitments, delivering frequently and gathering feedback — Agile is not just for building software.

note

Great projects are generally the end result of three types of commitment from three basic sets of actors: individual team members, teams and projects. This cycle of commitment is strongest in great organizations, which is why some organizations are better at delivering projects on-time, high satisfaction projects. However, this cycle can exist in weaker organizations.

The cycle, illustrated above, follows the pattern that team members commit to the team, the team commits to the project and the project influences the commitment of the person. A committed team is defined as a group of individuals who have developed relationships based around a commitment to attain a set of common goals. The strength of the bonds generated by the commitments is influenced by the relative importance of the goal that the project supports. Projects that support strategic goals tend to attract the strongest commitment, which keeps the various actors revolving around each other like a classic model of an atom. Industry data suggest that the strength of commitment is strongly correlated to perceived level of value of the project[1][2].

A weak or broken link in the commitment cycle will reduce the likelihood of a project achieving its maximum value or customer satisfaction. Commitment helps the team and individual focus on producing quality work. “The Hewitt Associates research finds that double-digit growth companies have 39% more highly committed employees and 45% fewer highly disengaged employees than single-digit growth companies.”[3]

The cycle of commitment links projects, teams and individuals. When the goals of the project don’t build toward the more strategic/organizational goals, commitment will be lower. Commitment, anywhere in the cycle, is a precursor to the ability to deliver projects that are of high value and customer satisfaction.


[1] A Study about Employee Commitment and its impact on Sustained Productivity in Indian Auto-Component Industry http://www.ejbss.com/Data/Sites/1/septemberissue/ejbss-12-1147-astudyaboutemployeecommitment.pdf

[2] Positive Impact on Employee Commitment and Engagement http://workplaceflexibility.bc.edu/need/need_employers_impact

Commitment

When talking about commitment in Agile, it is easy to focus on teams and techniques, such as the planning game and stand-up meetings, to the exclusion of the individual. It can feel like Agile is promoting collectivism. I actually had an especially philosophical student jump up in class and shout, “this is communism!” While most IT projects are team-based endeavors, teams developed from individuals plays a central role in making Agile techniques work. Committed individuals are the building blocks that create committed teams.

Individual commitment is a willingness to dedicate one’s self to a goal, and then to work as hard as possible to attain the goal. Commitment is so important that the Scrum Alliance (the entity that certifies Scrum masters, Scrum professionals and trainers) includes commitment in their code of ethics. To quote the code of ethics from the Scrum Alliance

“We take responsibility for and fulfill the commitments that we undertake – we do what we say we will do[1].”

When individual commitment exists then team commitment is possible.  Harnessing the assembled team of committed individuals becomes a coordination activity. Organization or project goals act as a guide to bring committed individuals together into committed teams.

Jeff Sutherland, one of the co-developers of Scrum says that “it is only when individuals and teams are committed that they feel accountable for delivering high value, which is the bottom line for software development teams[2].” Committed individuals are the building blocks for building committed teams. While teams are generally required for achieving results in software development, individuals are never optional.


 

[1] http://www.scrumalliance.org/pages/code_of_ethics

 

[1] Agile Principles and Values, by Jeff Sutherland, http://msdn.microsoft.com/en-us/library/dd997578(v=vs.100).aspx. 5/15/2013

 
Design a site like this with WordPress.com
Get started