Moving Motivators – Exercise

Here is a new exercise which allows people to reflect on their motivation, and how this is being affected by organizational change. Check out the following description, and see if you like it…

Ten Intrinsic Desires

The Moving Motivators exercise is based on the 10 intrinsic desires which I derived from the works of Daniel Pink, Steven Reiss, and Deci/Ryan. In order to play the Moving Motivators exercise you need to download this PDF, print the results on sturdy paper, and cut out the cards.

1st Step: Important to You

In the first part of the exercise you determine which motivators are most important to you. You do this by ordering the cards from the left (least important) to the right (most important).

It appears that the results vary strongly among players. For example, Freedom turns out to be the most important motivator for me, and Order is the least important. But for my friends the results turned out to be quite different.

2nd Step: Effects of Change

In the second part of the exercise you consider a change in your work life, such as an Agile transformation, a relocation, a new project, or a new job. You then determine how that change affects your motivators. If the change is positive, you move the card up. If the change is negative, you move the card down.

You will probably see that organizational changes have a different impact on different motivators. Perhaps the Agile transformation of your team makes your Curiosity card go up, but your Competence card may (temporarily) go down. Or the new job you applied for will increase your Status while at the same time it may decrease your Relatedness.

3rd Step: Reflection on Motivation

The Moving Motivators exercise reveals the effect of an organizational change on your motivators. When most of the important motivators go down, or when only the least important ones go up, you may realize that you have some work to do on your own motivation.

The exercise is particularly interesting for team managers (possibly to be performed with people in private one-on-one situations). It allows managers to find out what motivates their team members, and how an organizational change is affecting them. The exercise may give better insights than a regular conversation.

And it’s more fun too!



What is “Velocity” for your team

Know Exactly What Velocity Means to Your Scrum Team

When talking about it informally, I define velocity as simply a measure of how fast a team is going. And for most purposes, this definition works quite well. However, it creates confusion on some of the finer points of what should count in calculating a team’s velocity. This confusion comes about because there are really two more precise ways of defining velocity. Let’s see what they are.

1) Velocity measures how much functionality a team delivers in a sprint.
2) Velocity measures a team’s ability to turns ideas into new functionality in a sprint.

Those may sound the same. They are subtly different. To see how, suppose you hop in a river and begin swimming. After an hour, you measure how far you’ve traveled, and you are 2 kilometers from where you began. In agile terms, we might want to call this your velocity and say you swim 2 kilometers per hour or per sprint, if a swimming sprint is an hour long.

But, what if the river had been flowing at the rate of one kilometer per hour against you while you swam? In that case, you really swam 3 kilometers. Measured against the banks of the river, you’ve only moved two kilometers of physical distance. But while going forward two kilometers, you overcame being pushed backward one kilometer by the river.

So, is your velocity two or three? If we use our first definition—velocity is how much a team delivers in a sprint—then velocity is two. This swimmer delivered 2 kilometers of progress.

If we use our second definition—velocity is the ability to turn ideas into new functionality—then velocity is three. This swimmer has the ability to deliver 3 kilometers of progress per sprint, and we’d see that he was swimming in a lake with no current instead of a river.

To see how this applies to an agile project, consider the issue of whether a team should earn velocity credit for fixing bugs during a sprint. A team that uses velocity to measure how much functionality is delivered in a sprint will not claim credit for bug fixes. No new functionality has been delivered. So no points are earned.

A team using defining velocity as the ability to turn ideas into functionality, on the other hand, will claim credit for bug fixes. Their logic is that the time spent on bug fixing could have been spend adding new functionality except the product owner prioritized different work for them.

For many teams, the two definitions will yield the same value. Values will differ most for teams doing work for which they are not taking velocity credit–usually teams doing things like a lot of bug fixing or doing large amounts of refactoring.

Neither of these subtle differences in the definition of velocity is always better than the other. The one you use should largely depend on what you hope to learn by measuring it and by your expectations about the future.

If you expect the future to be just like today—that is, the team will spend the same amount of time doing bug fixing, refactoring and the like as they do now, then using velocity as a measure of how much forward progress is made will be the right answer for you.

However, if you expect the future to be different—perhaps the large refactoring and time spent fixing bugs will soon be over—then you may want to define velocity as the team’s ability to turn ideas into functionality, and would then add to velocity the points given to those activities.

The most important thing is to clarify with everyone on the team, including the product owner and ScrumMaster, is exactly what your team means when they use the term “velocity.” Having a precise definition makes it very easy to answer questions that come up around what should be counted when measuring velocity.



Agile Project Manager – Secret Sauce for Development Projects

According to the out-of-the-box Scrum framework, there is no Agile Project Manager (Agile PM) role. There are other Agile methodologies, such as Feature Driven Development (FDD), that rely on the role of a Project Manager (PM), but still, the PM role is reduced to someone responsible for the administrative aspects of the project, and not necessarily helping to coordinate the development team and their activities or dealing with resource issues (and also far from the complete traditional PM described in the Project Management Body of Knowledge). For example, according to FDD (Feature Driven Development), these are responsibilities of the Development Manager, not necessarily the PM. An Agile PM goes above the tactical PM role, entering into project coordination and strategy. The Agile PM takes the multidisciplinary skills of the traditional PM, and brings a unique familiarity with the fast-paced, change-embracing context of Agile projects and frameworks.

The Agile PM can be better understood as a unique professional with a very particular set of skills that allows him/her to own part the responsibilities of two or more roles at the same time, as needed. Considering the Scrum framework, these roles can include client Product Owner (PO) and Scrum Master, i.e. in one project the Agile PM can act more as a Scrum Master and switch to a stronger PO role in the next engagement, according to each project’s needs, not fully replacing, but instead complementing the job of the Scrum Master or PO. The Agile PM uses project management expertise to assist both sides (client PO and Scrum Master plus development team), filling in the gaps while always aiming for the best outcome for the project and walking the extra mile.

During the course of an Agile software project, the Scrum Master is typically viewed as the ”Agile Process Owner,” making sure that the team is using the Scrum and Agile frameworks correctly. Yet when considering nearshore projects, the leadership role is most beneficial when it is held by more than one person because most of the time the development team and PO are based in different countries, and working with leaders in each location can ensure the parties stay on track to meet the project’s goals. For example, a Scrum Master and an Agile PM can work collaboratively to lead a project and direct the geographically distant teams, with the Agile PM taking ownership of some of the tasks that are typically owned by the business partner to ensure the project moves along smoothly when the client is not physically present to meet with the development team. By taking on these responsibilities on behalf of the client, the job of the Agile PM becomes critical in ensuring the progress and success of a near-shore development project. The presence of an Agile PM also works well with collocated groups. However, because distributed teams do not always benefit from ”osmotic communication”, since not everyone is sitting in the same room, having the Agile PM helping to fill in this communication gap is crucial for the success of the initiative.

Tasks that the Agile PM can be responsible for include (but are not limited to): allocating team members (staffing), providing mentoring and coaching, coordinating the development of the product backlog with the PO and the sprint backlog creation process with the project team, developing, executing and monitoring the project’s schedule cost/budget, project cash flow/invoicing, communications and risk response plans and procurement management.

Specifically on the PO side, the Agile PM can be responsible for holding the kickoff meetings and also for scheduling and facilitating other project meetings as needed. In this situation, the Agile PM will take charge of preparing and communicating written and verbal status reports for the team members and stakeholders, as well as for updating and archiving the project documentation as needed (e.g. if a company’s PMO requires certain documents to be generated for the project to be compliant, there will be stories in the backlog for creating such documents).

The Agile PM is capable of assisting the client PO in properly conveying the client vision to the development team (e.g. by creating/maintaining a prioritized product backlog using Value Engineering techniques), while helping the Scrum Master ensure that the project has someone playing the appropriate Project Owner role, and that the Agile process is being followed on the client side, and not only within the development team.

An Agile Project Manager at Work

To fully understand the job of the Agile PM, consider a recent project for a Fortune 50 pharmaceutical company. The company undertook a software development and migration initiative with a nearshore development team consisting of a Scrum Master and the team responsible for burning the backlog items towards the sprint goals. The team included three programmers with different backgrounds (strong coding, strong web designing, strong database knowledge, etc.), one tester and one software architect. In addition to the remote development team, the Product Owner and the Agile PM, both onsite, were also part of the ”core project team”. The project lasted 66 days and consisted of five cycles.

The project began with a four-day warm up that the team referred to as ”Sprint 0.” During this phase, the team reviewed the requirements created by the client and established the estimated timeline while the application’s infrastructure was discussed and outlined. One goal of Sprint 0 was to include the client in discussions to clarify questions associated with the business rules so that the client, the Agile PM and the development team were on the same page.

While working through the 16-day sprints, the Agile PM played the critical role of facilitating constant communications, including arranging daily meetings with the team, morning meetings with the client and checking the backlog to ensure on-time completion of the project segments at the ”theme” level, while also coaching the Scrum Master to try to anticipate unknown roadblocks. Traditional Scrum practitioners believe that the development team is capable of tracking the backlog and bringing tasks to completion. However, this nearshore team has learned from experience that with geographical distance separating the client and team, the process is better streamlined with a manager in place to track all tasks .

It’s important to mention that the Agile PM did not have to take on specific task assignment during the project, as the development the team was self-organized enough to handle that. For example, some of the backlog tasks were very complex and the developers alone did not feel comfortable handling these activities, and they requested the software architect’s assistance themselves. Also, even though the developers were performing additional tasks besides coding, such as unit tests and system and regression tests (testing each other’s code), they were always assisted by the tester who was naturally requested to work on these activities. This scenario strengthened the ”buy in” of the team members and reinforces the ”power to the edge,” which is aimed at achieving organizational agility.

The first day of each sprint included planning sessions, during which the development team worked on the breakdown of the user stories (from the Product Backlog) into tasks, estimated them into hours and assigned team members to each task (creation of the Sprint Backlog). The client worked with the Agile PM and development team to discuss and define each sprint goal, which was then written on the whiteboard in the room where the development team worked.

During the next 14 days, the development team moved forward with implementation and participation in daily, 15-minute morning stand-up Scrum meetings. During these meetings, the Agile PM, through a web cam, participated with the team in the review of what was done the day before, what was going to be done that day and communicated any impediments to the sprint goal. The Agile PM also participated in a separate daily, 30-minute call with the PO to discuss any impediments discussed in the daily meeting and to find solutions. The last day of each sprint was marked by a one-hour demonstration session. The development team presented the working functionalities developed during the sprint to the client and any other stakeholders within the organization.

Bridging Geographical Boundaries & Enabling Communication

With the development team and client in different geographies (in this case, the development team was in Brazil while the PO was located in New Jersey), final responsibility for each sprint fell to the Agile PM. It’s worthwhile to note that the Agile PM’s job was made easier during this project because the development team was in a nearshore location, only one time zone away from the client, as opposed to the eight-plus hour time difference often associated with offshore projects. To better facilitate communication, the teams set up several Live Meeting and GoToMeeting sessions, as well as utilized a 1-800 conference number provided by the client organization.

The constant communication facilitated by the Agile PM complemented the work style of the development team. A high-performance team, the developers placed priority on regular communication with the client, ensuring both parties were focused on the most current business goals throughout the duration of the project. Combining the communication priorities of the high-performance team and the strong presence of the Agile PM as the go-between for the two parties, the nearshore team was able to stay on track through sprints, delivering projects on time and within desired specifications.

Learning from Past Sprints & Building Reputations

Throughout the project, the team held retrospective sessions at the end of each sprint, led by the Agile PM, who was in charge of coaching the Scrum Master and the development team. The goal of these sessions was to uncover ways that they could work better together, with a focus on what specifically went right and wrong during the sprint. In the Scrum framework, learning from the project is just as important as delivering the final product.

As a result of these sessions, the development team solidified its reputation with the client, providing a framework for exemplary work processes and serving as a benchmark for other teams that were working with the client on other software development initiatives. In addition, due to the constant retrospective views into each sprint, the development team needed less time to prove its case to the client prior to making a decision, which led to less overhead – and reducing overhead is critical in a highly competitive development market.

As the development team built its reputation with the client, it also built team morale, which is very important for Agile and high-performance teams. The team began to feel more confident in its work and ability to try new ways to perform certain tasks, including suggesting improvement in the business processes related to building the software.

Realizing Success

Beyond satisfying the client, the development team also achieved internal successes. Through utilizing Scrum and following the lead of the Agile PM, the team spent less time ”behind the curtains” developing, and getting faster feedback on its work. It was also able to focus on the most important elements of the project, placing priority on delivering the parts that brought business value. With the short, daily interactions, the client knew what was going to be delivered and when and knew that the result would provide value. The Agile PM also assisted the PO in preparing executive reports for upper management, to communicate the project value.

Looking back at this project, the development team realized that its success would likely have not been possible without the Agile PM to lead the process. Without constant communication, there could have been a greater cost to the project because issues would have not been detected immediately, leading to larger problems, rework and project delays. Without the Agile PM ensuring that the development team and client were focused on the same business goals, the two parties could have ended up on divergent paths, leading to the team delivering a less-effective product that did not meet customer needs.

Above all, the use of Scrum and the presence of the Agile PM ensured transparency during the project. The stakeholders were able to track the project on a daily basis and valued the ability of the team to rapidly react to necessary changes to circumvent potentially impassible impediments. The transparency served to increase the confidence of the client in the development team. This combination of a high-performance team and Agile PM instilled confidence and produced a truly value-generating product for the client.




7-Steps Agenda for an Efective Retrospective

Agenda structure:

1. Setting the context

Setting the context at the beginning of any meeting is the first step you can take to ensure that the meeting is effective. Participants need to understand what the focus of the meeting is.

You can start the meeting either with a pre-defined context, or you can define it real-time with the participants (“So, what is the context for this retrospective?”).

Below are some sample contexts:

  • “This retrospective is a bi-weekly recurring Scrum retrospective for the ABC team.  We are on Sprint 12 out of 30.”
  • “In 14 days, our artifact should reach the main production stage.”
  • “Feature XYZ exploded in production, bringing the servers down for 2 hours until sys-admin could bring the older version back up.”
  • “This team will work together in a new project starting today.”
  • “We have worked together in the past year. We will be working together for another year to come.”

2. Prime Directive

In Project Retrospectives, Kerth introduced the “Prime Directive”; a statement intended to help set the stage for the retrospective. The Prime Directive states: ‘Regardless of what we discover, we understand and truly believe that everyone did the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand.’ The statement is invaluable to set the tone for the meeting.

3. Energizer

The Energizer is an optional activity that can be run to “warm up” the team and promote group interaction. It is a good meeting starter for any team meeting, and is especially valuable for early stages of team building.

You should select an icebreaker activity to best suit your team’s dynamics. When building teams, we recommend activities that focus on sharing information, such as names and hobbies. Icebreakers can also be used before any meeting, to invigorate the participants and make them feel more engaged.

This kind of activity helps to create a friendly environment and makes people more comfortable to participate in the activities that will follow.

Check out some suggestions for Energizer activities.

4. Check-in

Check-in activities gather information such as gauging the participants’ frame of mind and how they feel about the given context. It is a good next step after setting the context and reading the prime directive, especially as it narrows down the themes that will be discussed later.

Another benefit of doing a check-in is that it helps people to put aside their concerns and then focus on the meeting at hand. Depending on the activity, it also helps if participants put aside their judgments – at least for the duration of the meeting. These are usually short activities. Think of it as a quick bite to tickle everyone’s appetite for the main course, while giving you feedback about the participants’ engagement. Check out further Check-in Activities here

5. Main course

The main course is the core of a meeting that seeks to foster continuous improvement. It is composed of one or more activities, and is also the time for the team to discuss their notes.

The main course activities are used to gather data, check on the team’s morale, talk about the positive stuff, recognize people, and seek improvements. They drive the team to reflect about the given context, reinforce a shared vision and generate insights. The main course is the time for team members to feel heard. Each and every individual note is acknowledged and is visible to the whole team.

Teams that have retrospectives as a recurring meeting will typically look for main course alternatives. By varying the activity, the team can look at different angles and perspectives, therefore generating new insights.

Choose your main course wisely, with the participants and purpose in mind. This is the main activity of your meeting, and in all likelihood, the information gathered and discussed will set the tone for continuous improvement.

6. Filtering

After the main course, you will have a lot of data in front of you. It is important to have well-defined criteria to decide what will be discussed. Given the meeting’s limited time, it is possible that topics will be left out of the discussion.

Some activities might help you to define your filtering criteria. For example, the team may group notes based on similarity and then discuss the identified clusters. Another possibility is to vote, and then focus on the most-voted topics. We’ve listed some more Filtering Activities here.

7. Next steps

The meeting is almost over. The team had a great discussion and generated many insights. Perhaps the activities have resulted in a few actionable items. This list of “next steps” is the last step in our meeting agenda. There are no formulae or specific activities for it. We recommend that the whole group talk openly about what’s next for the team. What will they do with the findings from the meeting?

A few examples are to include new items to the team’s backlog of work, email the meeting notes to the team, schedule (or remind everyone about) the next meeting.



Fun Retrospectives

Lack of inspiration for your retrospective? Here is something that might help:

Scrum Roles and Responsibilities Game

A completed run of the game


Timing: 15 minutes to run, 30 minutes to prepare (once only).


  • 32 Index Cards of one color (I choose blue).
  • 7 Index Cards of another color (I choose pink).
  • A permanent marker pen (i.e. sharpie).
  • Two flip chart pieces of paper (A0 size) or large pieces of butcher’s paper.
  • A very large desk or two desks large enough to hold the two pieces of paper.



This game quickly builds understanding of the subtleties of the Scrum roles and responsibilities. Once you have prepared the cards (in the preparation instructions) you can easily repeat this game at a very low set up cost.



Split each piece of paper into three equal sized sections and label each section: Team, Scrum Master, Product Owner. You will be able to keep and reuse these pieces of paper for numerous instances of the game.


Write out the two sets of index cards

Blue cards (Primary Responsibility)

  • Ensure Quality
  • Attend Sprint Planning
  • Attend Sprint Planning
  • Attend Sprint Planning
  • Attend Sprint Review
  • Attend Sprint Review
  • Attend Sprint Review
  • Attend Daily Standup
  • Attend Daily Standup
  • Attend Sprint Retrospective
  • Attend Sprint Retrospective
  • Attend Backlog Grooming
  • Attend Backlog Grooming
  • Attend Backlog Grooming
  • Design
  • Build
  • Test
  • Integrate software
  • Deploy
  • Improve process
  • Improve technical practices
  • Prioritise Product backlog
  • Talk to stakeholders
  • Track progress of the sprint
  • Make Product Backlog visible to all
  • Create Product backlog items
  • Resolve Technical impediments
  • Resolve organizational impediments
  • Facilitate Scrum events
  • Ensure Scrum rules are followed
  • Coach team
  • Track progress of the release



Pink cards (Secondary Responsibility)

  • Attend Sprint Retrospective
  • Ensure Quality
  • Ensure Quality
  • Attend daily standup
  • Create product backlog items
  • Improve process
  • Improve technical practices



How to run the game

For six to twelve people

Split group into two teams of three to six people each.

Hand each group a set of index cards, asking them to shuffle them and evenly spread them out among the group.

Place one prepared sheet of paper in front of each team.

Ask them to take 2 minutes in silence to place their index cards against the role that is responsible for the items listed on each index card. Explain that there are some duplicated items. Some the duplicated items have Primary(blue) cards and Secondary(pink) cards. Meaning that some the roles carry more/or less responsibility for that item.

After placing the index cards the teams now have 5 minutes to gain consensus as a team about the placement of the cards. They should discuss items that they disagree with within their team.

After the teams are comfortable with their placement (you will be able to tell as the conversation will die off) ask them to swap tables and review the other teams work. When they find any placements that they disagree with they should calmly discuss this with the other team.


Learning Points:

Often the teams will come to appropriate conclusions through the discussions that they hold as they find cards that they disagree with. However as facilitator you should watch out for situations where they jump to incorrect conclusion or where they miss out on misplaced cards.

One of the regular points that come up during this game is that the Scrum Master does not solve all of the team’s problems / fix their process. The team needs to step up and do this, however the Scrum Master is responsible for making it happen.


Do You Encourage People to Bring You Problems?

Here is a nice topic about encouraging people to come to you in time with their problems.