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!
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.
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.
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.