Agile ways of working are perfectly suited for uncertain working environments. Implementing them correctly, however, isn’t easy. There have been multiple instances where Agile adoptions have resulted in confusion, with one significant factor often being overlooked: the impact of rewards on an individual's motivation. To execute a successful Agile implementation, you should look at these motivational aspects of the transformation as well.
We work for rewards
What type of rewards do we get from our work? Most of the time, it’s salary, monetary incentives and bonuses, and safety of regular employment. But we also get motivated by the feeling of accomplishment when we finish something we can be proud of. We feel good when we get positive feedback on our work - from both our peers and customers.
Does Agile impact motivation and rewards?
Agile methodologies focus heavily on processes that may actually hinder some of the process' benefits, which is why you should take note of the following rules of thumb if you want to streamline the process:
- Work should be split into smaller chunks, typically for 3-5 days.
- Your backlog should be the only single source for work.
- Team members should volunteer for tasks. Nobody should assign them.
Feeling defeated by the outcome
In my opinion, Agile 'rules' may impact the feeling of reward. Splitting work into small, testable chunks can leave the end result feeling incomplete. However, it helps maintain productivity while delivering quality results. But, smaller goals may not give a sense of pride to the accomplishment.
This work-splitting practice may also be the reason for the strong resentment some people with designer backgrounds have expressed toward Agile methods and Scrum in particular. Small work chunks and selecting top-priority items in sprint planning lead to developing solutions that may be effective but not flawless. Designers may not always find them ideal.
Running everything through the Backlog can reduce satisfaction
Having your backlog serve as the single source of work can also impact motivation by removing the possibility to ad-hoc help people with their problems. A common occurrence for dev teams is that people, internal or external to the team, come to them when asking for help on problems. Helping others can be rewarding, both in terms of doing good and feeling good. Prohibiting such activities may reduce the reward for team members.
No more thanks from the boss
The third important factor that I'd like to mention is transitioning from assigned to voluntary tasks. Assignments from a team lead or project lead offered an opportunity for your boss to evaluate your work and offer appreciation for a job well done. Good bosses took every chance to express gratitude for completed tasks.
One of the challenges that can emerge in Agile approaches is a lack of recognition when teams volunteer for tasks. Since nobody is assigning these tasks, nobody may feel responsible for telling others that their tasks are completed. Ideally, the team or Product Owner would show appreciation for a job well done, but in practice, this doesn't always happen. With teams already juggling various responsibilities and dealing with stress, it can become easy to forget to acknowledge the good work done by your teammates.
Ideas that can help overcome the above problems
Here are my ideas on how you can avoid the negative impact of Agile on rewards:
Pervasive use of small epics
You should continue to split work into smaller chunks. But I would also recommend you focus on using epics as a hierarchy of work. See these small chunks of work (stories or tasks) as building blocks and celebrate epic-level achievements.
To make the most of your efforts, it's important to keep your epics small. You should look to finish an epic within 2-3 sprints for a successful outcome. Avoid lengthy epics that take half a year or more to complete, and keep the epic work-in-progress manageable to ensure smooth progress.
Small epics provide a sense of accomplishment when completed - even if an individual small user story doesn't provide the same exaltation. With the epic goal always within a few weeks, making progress, even with the small building blocks, will always feel rewarding.
Rules of engagement for helping others
Helping others needs to happen, but we must also respect the ideal of a single source for work. So what ideas could we introduce that achieve both? Here are some suggestions I had in mind:
If you come across a situation where others require your help, take a moment to think about the bigger picture. How could they have helped themselves without seeking assistance? Perhaps there is scope for improvement in coding and documentation, like architecture documentation and intranet how-to guides. Identifying areas for improvement like this can help reduce unnecessary requests for help in the future.
One way to help others is by carving out time in your schedule. A good idea might be to set a rule saying that it's acceptable to respond to help requests under 15 minutes in length. Anything longer can be run via the backlog. Keep in mind that interruptions may become an issue. So if that happens, consider setting "call times" for receiving and investigating problems or "do not disturb" times with no interruptions allowed.
To prioritize helping tasks more effectively, categorize them into three groups: urgent, semi-urgent, and not urgent. Urgent tasks demand immediate attention, while semi-urgent tasks can wait 1-5 days. Not urgent tasks can follow the normal backlog management system. Using this task categorization, teams can handle urgent and semi-urgent tasks efficiently while also maintaining peace of mind.
Learn and agree to thank each other
To create a positive workplace culture, it's important for the team, Product Owner, and Scrum Master to recognize and appreciate good work. One way to achieve this is by discussing it during team events like retrospectives. Developing policies on reacting to completed work can also be helpful in improving team morale and productivity. This could mean such things as
- Encourage your teammates with smileys or messages when they complete a task.
- Create a team agreement to always provide feedback whenever a task is completed.
- Establish a workflow step for "in review" on your team's Kanban board.
- Establish a protocol for situations when no feedback is received, such as repeating the signal or asking for feedback from specific team members.
- Set expectations for response times, such as reacting within a working day.
Agile methods can truly be a game-changer for teams, providing better acknowledgment of achievements, enabling the act of helping others, and implementing the rules to drive success. With the pervasive use of epics, they become more fun and motivating too.
Published: Jun 27, 2023
