Motivation, Performance and Career Growth in Scrum/Agile

By Tanya Ivanova, VP of Delivery at Waverley Software. Tanya has been managing IT projects in various business domains for 10+ years. Well-versed in the latest tech and top PM practices, she builds and coaches mature engineering teams.

Teams using Scrum on regular basis can get bored. This is especially true of higher-performing teams. The smoother the process, the easier it is for team members to start feeling they’re working in a factory: demos and retros become mechanical, all failures are in the rear-view mirror, all disputes are resolved, top-management is happy and the team is held up as a model for less mature teams. You’d imagine such a team would live happily ever after but…

Experience has shown that a team that has attained such a high-performing state requires extra attention from its project manager. Yes, let’s assume this team has a manager looking after each member’s career path and keeping them motivated to do a great job. And at some point this manager starts to notice signs of boredom: the discussion of the project lacks enthusiasm, creativity is thin on the ground, and challenges are met with a shrug. This is the right time to do something differently.

Certain professions observe the tradition of hanging diplomas and certificates on an office wall for clients and patients to see. These symbols, some might call them trophies, indicate competence, success in one’s training or work, excellence, professionalism.

Consider a similar approach to designate that someone did great during a Sprint. This can be a “star badge” (for example) given to an engineer during the Sprint’s retrospective meeting by the rest of the team. It can be for anything the team wants to appreciate about that person.

Scrum talks about team commitment, team performance and team responsibility on deliverables. And this is all good when things are going fine and no problems occur. On the other hand when a team fails a Sprint, it’s often hard to pinpoint a weak link. Team members will tell the project manager that all of them are “good guys” working hard against incomplete requirements, unexpected difficulties in deployment etc., and if possible they will blame anyone outside of the team for the failure: managers, the product owner (especially if the product owner is customer-side). It’s a pretty rare case that a team will admit failing a Sprint delivery due to their own overestimation of their competence, wasted time during the Sprint, lack of discipline, miscommunication and/or not escalating issues early enough to other team members or the Scrum Master.

And here starts the person-by-person performance analysis, work review etc in order to try to separating well-performing team members from, em, ballast. A little humor goes a long way towards lightening the mood here. During sprint retrospective meetings the Team can decide which members (if any) deserve a “Zombie” badge for their meh performance, lack of feedback, blocking work of other team members, etc.

Here’s another reason this personalized, trophy-based approach is useful. Teams often consist of developers of unequal experience and seniority and line managers need to do performance reviews for each engineer as a member of one or more Scrum teams. While these reviews constitute important feedback in each engineer’s career plan you’ll be hard-pressed, as a line manager, to get negative feedback from the other members of that engineer’s Scrum team. Handed out at regular intervals, the trophies are fun but also serious: something simple and agile allowing the tracking of each team member’s successes and failures without taking lots of time from PMs, Scrum Masters (or whomever is doing this job in your company).

Here is the simplest evaluation system: have a table that’s shared with all the team members, then assign an excellence mark in front of each team member name using the following rules:

• Assign 3 if the team member performed extra work or took something to a higher level on-time and with good quality.
• Assign 2 if the team member did good work and accomplished all the tasks assigned in time and with good quality.
• Assign 1 if the quality was not so great, leaving some bugs for future Sprints.
• Assign 0 if tasks were left incomplete without a valid reason.

Then, in a brief discussion with Team Members grant the Stars and Zombie Badges if any are deserved.

The idea is to use a developer’s total score to rank his/her performance over an extended period of time. Calculations are simple: people with top scores and more Star badges are the first to get salary raises, bonuses, days off, go to a conference at company cost… anything you use in your company as positive motivation. On the other hand if for some reason your project budget gets cut you know which of the current team members you can release without remorse. And your choice will be supported by these simple metrics.

Finally, I have already described the importance of having FUN while working. Add some gamification to your Retrospective meetings and I promise you wouldn’t get bored during Planning nor during the Sprints.