2

As newly assigned manager on an already ongoing agile software development project, one of the objectives is the following.

Motivate team to high performance

This can be done in various ways and might be different for each individual team member. Daniel Pink talks about motivation by:

  • Mastery: The urge to get better skills.
  • Autonomy: Our desire to be self-directed. It increases engagement over compliance.
  • Purpose: The desire to do something that has meaning and is important.

In an article by RisePeople they suggest measuring performance by the following 5 metrics.

  1. Attendance: poor attendance can be a lack of motivation.
  2. Helpfulness: increases productivity.
  3. Efficiency: looking for missed deadlines.
  4. Initiative: a sign of team satisfaction and engagement.
  5. Quality: shows that the team cares what they do.

Most metrics seem difficult to define and measure and I have no experience with it. I would like to hear any ideas or experience on how to approach this and align it with senior management expectations?

| improve this question | |
  • 3
    My suggestion: Ask senior management what they mean by 'high performance'. – Sarov Mar 12 '19 at 17:58
  • 2
    This is an X/Y problem. Why does your management team think the team is unmotivated, and what specific outcomes would they measure to define "high performance?" – Todd A. Jacobs♦ Mar 12 '19 at 21:31
  • 1
    @Sarov Great point. I think the problem, as they see it, is that nearly no new development is made. I would guess they need new features and functionality in the product development. Maybe being more innovative. – Runego Mar 13 '19 at 7:32
  • @ToddA.Jacobs I like the idea of what expected outcomes they would see from a high performance team. I’m not sure I understand “an X/Y problem”. Could you clarify that? – Runego Mar 13 '19 at 7:36
  • meta.stackexchange.com/a/66378 – Sarov Mar 13 '19 at 13:16
0

One of the thing as a scrum master i tried in couple of scrum teams, for team performance improvement was to identify the aspirations of each team member and then align/allocate them the work matching to their aspirations as much as possible.

Our scurm team composition was varied, some of them were junior developers with 2-4 years of experience and some were senior with 5+ years of experience in their skills.
When i spoke with them to understand what motivate them, I got different views.

For example, junior developers were more keen to learn new frameworks. They were very keen in participating in hackethon events or coding challenges etc. 1 of them even said that he is ready to work over time in project work if needed to compensate for an opportunity to participate in hacking challenge event.

For Sr. folks, it was more about participation in estimates, architect the solutions were some of the motivational factors to name a few.

Based on these inputs,it was clear as to what motivate each individual and while executing the project, there was a deliberate focus from project leadership to assign them tasks which are close to their area of interest.

My own observation with this approach was that the individual felt like their voices are heard and hence they took the ownership of deliverables and ensured that the desired quality is met.

| improve this answer | |
  • That is a clever way to engage the team in the motivational aspect. Did you discuss how to measure improvements? – Runego Mar 14 '19 at 6:54
  • yeah, as you can imaging its not easy to "measure" motivation with traditional metrics which we use for say cost. 1 way i used was keeping an eye on number of user stories/tasks completed by the staff and turn around time to finish those. Again, a general trend was, if the task/activity was of interest to him/her, more such tasks were completed faster with better quality and less bugs during Testing/QA.This was a noticeable and measurable too as we saw defect count going down most of the time. – AADProjectManagement Mar 14 '19 at 8:42
1

One of the traditional challenges with both motivation and measurement of software development teams is that we isolate the development team (or even a developer in our thinking). Feom a measurement standpoint, we can't measure the thing we really care about: value creation, because they don't do it alone, so instead we start measuring things that can be measured at an individual level like attendance or code commits, which if we think about it are secondary measures at best. From a motivation standpoint, most software developers start in their career because they love creating things and solving problems, but when you isolate the code-writing part, you take a lot of that away.

A common solution is that you start measuring at a higher level - a level that delivers value. This is why Scrum teams, for example, include all closing, architecture, design, testing and the business decision maker (PO). This means you can take a problem or need to the Scrum team and they can deliver on it. Without getting too in depth, we can see you autonomy, purpose and mastery can be far more present in this model. Measurements also mean something at this level. How well does the team solve customer problems? How reliable are their solutions? How fast do they turn them around?

You do lose individual measurements in this model, but most companies find that when they really adopt it, the team sorts that out themselves. On this point, Yves Morieux has a fairly insightful talk about the problems of individual accountability metrics: https://www.ted.com/talks/yves_morieux_how_too_many_rules_at_work_keep_you_from_getting_things_done?language=en#t-350439

| improve this answer | |
  • I like this perspective. Thank you for sharing it. – Runego Mar 14 '19 at 6:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.