What do we mean when we talk about commitment? It can be applied to a number of different activities of a team. Commitment ranges from the team accepting work into a sprint and promising to complete it during that sprint, to being asked to deliver a specific scope at a specific date for a specific price. Some of these activities are at the heart of a team being Agile and some are at the heart of having Agile done to the team. If we take these two examples as the ends of a continuum, one end is Agile and the other is anti-Agile. Making and keeping commitments are core components of professional behavior. The simple definition of a commitment is a promise to perform. Common sayings like “my word is my bond” and “a handshake is worth more than a signed contract” reflect just how seriously we take commitments. Whether Agile or Waterfall, commitments are used to manage software projects by driving team behavior.
Making a commitment creates a set of expectations, which if not met have ramifications. For example, if an Agile team commits to a performance level that they consistently miss; can the organization plan for the product releases? Even if the team has a release plan, no one will trust their word, and that lack of trust will generate the need for more management control. In the long run, a commitment is a lien on reputation of the committer that can only be paid through performance.
Commitment Cycle
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 on-time, high satisfaction projects. However, this cycle can exist in small groups or specific teams within weaker organizations.
The cycle, illustrated above, follows the pattern that team members commit to the team, and then the team commits to the project and finally the project forms a feedback loop to re-influence the commitment of the person. A committed team is defined as a group of individuals that have developed relationships based around a commitment to attain a set of common goals. The strength of the bonds generated by the commitments between the team, people and the project 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 the classic model of an atom. Industry data suggest that the strength of commitment is strongly correlated to perceived level of value of the project.
A weak or broken link in the commitment cycle will reduce the likelihood that a project will achieve its maximum value and/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.” Hewitt Associates, the US provider of human capital and management consulting, researched engagement and growth with Michael Treacy, author of Double-Digit Growth. Clearly the effort required to create an environment where commitment can flourish pays off in growth.
The cycle of commitment links projects, teams and individuals. When the goals of a 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 achieve customer satisfaction.
Individual Commitment
When discussing the role of 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, the individuals play 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 hard 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 their code of ethics: “We take responsibility for and fulfill the commitments that we undertake – we do what we say we will do.”
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, “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.” While teams are generally required for achieving results in software development, individuals are never optional.
Public Commitment
A feature of both Scrum and xP planning is a public commitment from both the team and the individual, after they understand the needs of the Product Owner and develop a plan to tackle the work. Public commitment is a part of the planning game that tends to be avoided, overlooked or done privately. The team’s failure to publicly commit creates ambiguity. Not making a public commitment robs the planning activities of a significant power to influence delivery by creating an anchored goal for the team. Teams abandon public commitment because they want to avoid responsibility and because the act seems superfluous. However, the act of committing serves as a hook for the team and publicly shares expectations with the entire organization. The pressure to live up to the expectation set by the public commitment provides motivation based on a fear of public failure. Transparency, when combined with goal-driven behaviors, acts as a powerful tool to motivate and guide development teams. Transparent, goal-driven behavior is an integral component of all software development techniques, particularly when applying Agile techniques. Public, observable commitments are one form of transparent goal-driven behavior.
For example, the process of team members reporting and planning work during the stand-up meeting is an important example of public commitment and transparency. In a well-oiled Agile team, each member of the team accepts work for the day; “taking” the work that is the highest priority or swarming to tasks where help is needed. Everyone knows what everyone else is doing and is free to help guide the process. The act of “taking” the work in public is a tactical form of commitment that brings to bear pressure to perform and support the team. Failure of an individual team member to do what they promised will injure their reputation within the team.
Failure due to lack of commitment is doubly injurious. A failure to commit anywhere in the cycle of commitment can stimulate a variety of bad behaviors including passive aggressive behaviors and sapped motivation. A break in the cycle reduces productivity, quality and speed to market, which translates to higher costs and lower customer satisfaction. Public commitment is small price to pay to bolster commitment.
Non-Agile project management techniques do not foster the same level of public commitment that the Scrum stand-up technique creates. Techniques that foster stronger commitment to the task at hand will increase the likelihood that a team will deliver what they promise. This will enhance the reputation of the individual, the team, and in the long run, the whole IT department. Publicly “taking” work during a stand-up combines transparency and commitment, goal-driven behavior to create motivation.
Fostering an Environment of Commitment
Commitment is a simple concept, just doing what we say we are going to do. Unfortunately that simple concept requires a complex set of behaviors to achieve. Getting teams and organizations involved maximizes the possibility of meeting the commitments we make, which requires an interlocking cycle and environmental support. It might not be easy, but if we believe the data that commitment and growth are linked, the result is worth the effort.
Creating an environment that supports and facilitates keeping commitments increases value. Agile practices draw on the commitment of individuals and the team in many ways, for example the commitments from the sprint planning or the commitments made during the daily stand-up. Without the team continually committing to the work, Agile would just be iterative Waterfall. Additionally, the commitment of team members to work together is a critical factor in formation of teams and their ultimate success.
Commitment is impacted by many factors.
- Mission: Knowing that the work supports or fits into the organization’s overall strategy provides a goal for the team to pursue.
- Value: Knowing that the team is valued provides an anchor that supports individuals working together as a group.
- Challenge: Providing a goal and trusting the team to rise to the situation.
- Empowerment: Giving the team the authority to solve the business problem defined in the project.
Knitting mission, value, challenge and empowerment together creates an environment where a group can develop a solution and commit to achieving that goal, because they know that their performance will be valued. The environment that supports commitment is a core component for high performance teams.
Building Motivation and Trust
Commitment that builds motivation and trust is a fundamental part of the Agile framework that encourages us to “learn early and learn often.” Like any other behavior, there is some mix of reward and punishment that organizations can use to encourage appropriate commitment by teams. Whether Agile or Waterfall, commitments are used to manage software projects by driving the behavior of teams.
Successful methodologies reinforce behaviors that generate trust in the team’s ability to deliver value. Having teams commit to the work they can deliver generates motivation that will yield results, which in turn will build trust. 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 to fine-tune their behavior helps the team to deliver on its commitment. This is the chain reaction of behaviors, beginning with commitment, that will deliver value and customer satisfaction.
Sprint planning is one of the core activities of Scrum. In the planning process, the Product Owner indicates the work he or she wishes to have completed during the sprint. The team reviews the prioritized backlog, plans based on the teams capacity and velocity and then commits to the work that can be completed (which may not be the same as was requested by the Product Owner). The activities of planning and committing to the work the team believes can be completed are important psychologically to the team. As noted before, commitment and acting on the commitment builds motivation and trust. Commitment, motivation and trust support Agile values and principles and are very much pro-Agile.
At the other end of the continuum, a team or organization is asked to deliver a specific scope, on a specific date, for a specific price and agrees. That “agreement” may well be in the form of an accepted assignment for an internal IT team or a response to an RFP for an organization that provides services to others. In either case, the “agreement”, no matter how it is extracted, is a promise to perform. Almost every death march of a project I have seen has begun with this type of a commitment. The practice is exactly not Agile. Unfortunately, as with many other poor engineering disciplines, many teams and organizations still feel this behavior is required for business purposes or simply as a survival mechanism for office politics. Over the life of a project, this type of "commitment" causes undue pressure and performance fear as the team attempts to find a path through a set of fixed constraints. Pressure and fear lead to behaviors that reduce real commitment, foster shortcuts that increase technical debt, makes hiding mistakes a rational behavior. In the end, it reduces trust between both team members and the business. Committing to work because the commitment is demanded flies in the face of more than a few of the Agile values and principles.
Committing to work is neither Agile or anti-Agile in its own right. The process of commitment used in the Scrum planning exercise occurs in an environment that supports the four Agile values and ten Agile principles. Telling a team or organization what is required and treating acceptance as commitment is not Agile. The wrong kind of commitment creates a rotten base from which to begin a project. Commitment used through the filter of Agile values and principles leads to motivation and trust. These positive behaviors lead to customer satisfaction, and are decidedly Agile.
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." Simply put, Agile supports a culture where learning and commitment work together.
In “How “Learn Early, Learn Often” Takes Us Beyond Risk Reduction”, 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 take 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.
Rewards
Agile puts people and teams at the center of development. Embracing the Agile principles means that commitment, motivation and teamwork are important characteristics for team effectiveness. Commitment, motivation and teamwork are highly interrelated and it is expected that if you positively impact one all three will be impacted. Organizations often use rewards to reinforce commitment. 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 factors for software developers. They are:
- Achievement
- Possibility for growth
- Work itself
- Recognition
- Advancement
- Technical supervision
- Responsibility
- Relations with peers
- Relations with subordinates
- Salary (Boehm B. W., Software Engineering Economics, Prentice Hall, 1981)
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 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. Involving 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.
Punishment
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 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 found that the many of the characteristics of highly effective teams revolved around being goal and principle driven (Larson, C., E., LaFasto, F., M., Teamwork: what must go right/what can go wrong, Sage Publications, 1989). Commitment, motivation and teamwork are highly inter-related. The fear 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.
Self-organizing and self-managing teams cannot truly exist without trust between the team members and the trust of the organization. Trust is built when teams are allowed to make and keep their own commitments. Agile teams make commitments based on the needs of the business and their capabilities. Teams delivering against the commitment they make that ultimately deliver business value and that is what software development is all about.
About the Authors
Mr. Cagley is the Vice President of Consulting for The David Consulting Group. He is an authority in guiding organizations through the process of continuous process improvement. His areas of expertise encompass management experience in a wide variety of methods and metrics: Lean software development, Agile software development, quality integration, quality assurance and the application of the Software Engineering Institute’s Capability Maturity Model® Integration (CMMI) to achieve process improvements. Mr. Cagley is an active member of the International Function Point Users Group and is a Certified Function Point Specialist. He is also the editor of the Software Process and Measurement Podcast - SPaMCAST and blogs here. He can be reach at t.cagley@davidconsultinggroup.com
Meghan Cagley is a communications and global health professional with experience in new business development and writing for a global audience. As a program manager, Ms. Cagley is at the forefront of using innovative software and mobile applications for health promotion in low-resource settings worldwide. Meghan can be reached at megcagley@gmail.com