Project Management

Project Management Central

Please login or join to subscribe to this thread

Topics: Agile
How would you motivate an Agile Scrum Team?
Hello, I've recently joined a company to run their projects using Agile.
During the daily stand-ups I've noticed members of the team giving updates one-by-one and not really engaging with each other. It also looks like the company board hasn’t been updated as when the product owner asks questions the team moves items with statements like “Oh yeah, I did that Friday”.
Looking in JIRA I can see that the team’s velocity goes up and down sprint-by-sprint and last sprint they only completed half of the items they accepted into the sprint. I've also noticed that the burndowns for previous sprints tend to be fairly flat until the last few days of the sprint when items start getting done.
The product owner has pulled me aside and explained that there’s an important milestone coming up and he doesn’t have confidence that the team will deliver all the work that he has planned.
Senior leaders have concerns regarding the product team, what is the best approach to lead the team towards success using Agile?
Sort By:
Page: 1 2 next>
My first recommendation is: Agile is not Scrum. Agile is an approach that can be used with any other life cycle/method than Scrum framework. With that said, your problem is not Scrum. Your problem is the company seems to fall in the trap that by using a method/framework it will be agile. Most of the companies fall in this trap due to not to make an impact analysis on the future state to achieve and then decide what strategy to use to achieve the future state. My recommendation is making the impact analysis to understand the situation based on the current architecture. And the end to use a method/framewok is because a solution will be created.
...
1 reply by Jonathan Doyle
May 08, 2020 2:38 PM
Jonathan Doyle
...
Hi Sergio, I totally agree with you that Scrum is part of Agile and that they are two different things, perhaps I should have worded my initial post better. You raise a really good point regarding the method/framework. The company went through a digital transformation 3 years ago which was supposed to bring them inline with Scrum practises. Perhaps this is the moment for them to take stock of how well this has been going and reaffirming if this is the direction they still want to follow, it does make me think, are they sleep walking away from what they originally wanted to achieve as a business?
Furthermore, considerations around direction from senior managers is important and if that is lacking which will also have bearing on current Vs future state.
Jonathan -

I think you need to understand what is causing these challenges.

Some might be due to a lack of discipline or motivation on the part of the team whereas others might be due to poor management support surrounding the project. For example, if team member availability is not dedicated to a single project then it is quite reasonable that velocity might change sprint-to-sprint.

As far as work items lingering till the end of the sprint that also could be due to many things including team members pulling too much work-in-progress, a definition of done which has some guidelines which can only be met near the end of the sprint (e.g. having to send work items to an external team for review or testing).

If you follow Deming you'll know that most of the time the system is the issue, not the people. Fix the system and the people challenges will go away.

But to do that, you need to determine the root cause for the symptoms you are seeing.

Kiron
...
1 reply by Jonathan Doyle
May 08, 2020 2:42 PM
Jonathan Doyle
...
Hi Kiron, thanks for the great response. I think that I am going to have a closer look at the Scrum ceremonies, basically is everyone getting a chance to participate so they feel that they are part of the same team. I also want to meet with the Scrum team, mid-Sprint, and have an honest conversation with them. It is important try to get to the heart of the matter quickly as I don’t have too much time. My other thought is around, what exactly the Product Owner has in mind for the next Sprint. There might be a part of him that thinks that there is too much work in the Product Backlog lined up for the next Sprint and as the team are plodding along perhaps the team won’t push themselves to deliver. In terms of the system that they follow, perhaps a review is needed. They might prefer Kanban or Extreme Programming, also are the team coming under unnecessary criticism. Management could be the issue here more than any thing else. Excellent point about Velocity by the way, I will check if certain team members are being pulled onto other projects or doing ‘pet projects’ for certain senior members of staff.
As Sergio and Kiron already emphasized it is not about scrum, velocity, agile, etc. it is more about the constraints from outside the team is working in. Are the rules, principles and value understood and also actively supported by the management? Does the team really have a shared understanding about the goals to be achieved and about the way of working to achieve them? In general, people are motivated if the envionment provides them autonomy, purpose and mastery as Dan Pink described in his book Drive. This book and the book of the Heath brothers (Switch) are excellent sources of food for thoughts related to your described scenario. By the way, if the PO does not have trust in the team is already a warning signal that something is essential wrong with the understanding of product refinement and iteration planning in this project.
...
1 reply by Jonathan Doyle
May 08, 2020 2:43 PM
Jonathan Doyle
...
Hi Peter, I totally agree with your analysis. I want to find out if there is an issue here with rules, principles, and value. There might be an element of coaching required. I also want to understand more about the team’s motivations, are they being pushed and pulled in all sorts of directions, for example. Thanks for the recommendations, I had never heard of Dan Pink before but after having a look at his reviews online, Drive looks really useful. I have heard of Switch before but I’ve never read it, I will put that on my book list too!
May 07, 2020 3:08 PM
Replying to Sergio Luis Conte
...
My first recommendation is: Agile is not Scrum. Agile is an approach that can be used with any other life cycle/method than Scrum framework. With that said, your problem is not Scrum. Your problem is the company seems to fall in the trap that by using a method/framework it will be agile. Most of the companies fall in this trap due to not to make an impact analysis on the future state to achieve and then decide what strategy to use to achieve the future state. My recommendation is making the impact analysis to understand the situation based on the current architecture. And the end to use a method/framewok is because a solution will be created.
Hi Sergio, I totally agree with you that Scrum is part of Agile and that they are two different things, perhaps I should have worded my initial post better. You raise a really good point regarding the method/framework. The company went through a digital transformation 3 years ago which was supposed to bring them inline with Scrum practises. Perhaps this is the moment for them to take stock of how well this has been going and reaffirming if this is the direction they still want to follow, it does make me think, are they sleep walking away from what they originally wanted to achieve as a business?
Furthermore, considerations around direction from senior managers is important and if that is lacking which will also have bearing on current Vs future state.
May 07, 2020 3:57 PM
Replying to Kiron Bondale
...
Jonathan -

I think you need to understand what is causing these challenges.

Some might be due to a lack of discipline or motivation on the part of the team whereas others might be due to poor management support surrounding the project. For example, if team member availability is not dedicated to a single project then it is quite reasonable that velocity might change sprint-to-sprint.

As far as work items lingering till the end of the sprint that also could be due to many things including team members pulling too much work-in-progress, a definition of done which has some guidelines which can only be met near the end of the sprint (e.g. having to send work items to an external team for review or testing).

If you follow Deming you'll know that most of the time the system is the issue, not the people. Fix the system and the people challenges will go away.

But to do that, you need to determine the root cause for the symptoms you are seeing.

Kiron
Hi Kiron, thanks for the great response. I think that I am going to have a closer look at the Scrum ceremonies, basically is everyone getting a chance to participate so they feel that they are part of the same team. I also want to meet with the Scrum team, mid-Sprint, and have an honest conversation with them. It is important try to get to the heart of the matter quickly as I don’t have too much time. My other thought is around, what exactly the Product Owner has in mind for the next Sprint. There might be a part of him that thinks that there is too much work in the Product Backlog lined up for the next Sprint and as the team are plodding along perhaps the team won’t push themselves to deliver. In terms of the system that they follow, perhaps a review is needed. They might prefer Kanban or Extreme Programming, also are the team coming under unnecessary criticism. Management could be the issue here more than any thing else. Excellent point about Velocity by the way, I will check if certain team members are being pulled onto other projects or doing ‘pet projects’ for certain senior members of staff.
...
1 reply by Kiron Bondale
May 08, 2020 3:00 PM
Kiron Bondale
...
Jonathan -

With regards to ceremonies, it would help to know how those were originally introduced to the team. Do the team members (including the PO) fully understand the purpose behind them or are they just going through the motions (e.g. cargo cult)?

Are there any working agreements defined by the team? Have they come up with any simple documentation for their "way of working"?

Kiron
May 08, 2020 2:27 AM
Replying to Peter Ambrosy
...
As Sergio and Kiron already emphasized it is not about scrum, velocity, agile, etc. it is more about the constraints from outside the team is working in. Are the rules, principles and value understood and also actively supported by the management? Does the team really have a shared understanding about the goals to be achieved and about the way of working to achieve them? In general, people are motivated if the envionment provides them autonomy, purpose and mastery as Dan Pink described in his book Drive. This book and the book of the Heath brothers (Switch) are excellent sources of food for thoughts related to your described scenario. By the way, if the PO does not have trust in the team is already a warning signal that something is essential wrong with the understanding of product refinement and iteration planning in this project.
Hi Peter, I totally agree with your analysis. I want to find out if there is an issue here with rules, principles, and value. There might be an element of coaching required. I also want to understand more about the team’s motivations, are they being pushed and pulled in all sorts of directions, for example. Thanks for the recommendations, I had never heard of Dan Pink before but after having a look at his reviews online, Drive looks really useful. I have heard of Switch before but I’ve never read it, I will put that on my book list too!
May 08, 2020 2:42 PM
Replying to Jonathan Doyle
...
Hi Kiron, thanks for the great response. I think that I am going to have a closer look at the Scrum ceremonies, basically is everyone getting a chance to participate so they feel that they are part of the same team. I also want to meet with the Scrum team, mid-Sprint, and have an honest conversation with them. It is important try to get to the heart of the matter quickly as I don’t have too much time. My other thought is around, what exactly the Product Owner has in mind for the next Sprint. There might be a part of him that thinks that there is too much work in the Product Backlog lined up for the next Sprint and as the team are plodding along perhaps the team won’t push themselves to deliver. In terms of the system that they follow, perhaps a review is needed. They might prefer Kanban or Extreme Programming, also are the team coming under unnecessary criticism. Management could be the issue here more than any thing else. Excellent point about Velocity by the way, I will check if certain team members are being pulled onto other projects or doing ‘pet projects’ for certain senior members of staff.
Jonathan -

With regards to ceremonies, it would help to know how those were originally introduced to the team. Do the team members (including the PO) fully understand the purpose behind them or are they just going through the motions (e.g. cargo cult)?

Are there any working agreements defined by the team? Have they come up with any simple documentation for their "way of working"?

Kiron
...
1 reply by Jonathan Doyle
May 10, 2020 6:33 AM
Jonathan Doyle
...
Hi Kiron, I agree. In fact I think that there may be some training issues here. I suspect that some members are new to the Scrum team and might have either picked up bad habits from other teams or have come from companies who weren't really using Scrum. The Product Owner seems quite knowledgeable about their role, perhaps not so well informed on what the Dev team should be doing.

Thanks, Jonathan
I would do a 1:1 with each team member and find out what inhibits this person to excel. Might be team problems, process problems or governance problems. Velocity just shows symptoms, not root causes. Same to insecurity on PO side.
...
1 reply by Jonathan Doyle
May 10, 2020 6:36 AM
Jonathan Doyle
...
Hi Thomas, that is a good point. I was thinking of catching up with a few of the team members before the retrospective. However, it has to be a balancing act as I want them to refrain from blaming each other for things as that could damage moral even more.
Hi Jonathon - We don't want to make the assumption of ill intent of any of the anti-patterns mentioned. I'd recommend taking time to understand where the team is hand how they got there, what their training and support have been like, and what their understanding of where they fit in is.
Many times, it is how the team(s) perceived the training. Without proper coaching, the team will do (and continue to do) what they feel is right or working.
Work with the team toward a reset. It will do no good to point out what you think they are doing wrong or what they could do better. Take time to understand their current state and provide them with the knowledge to develop different behaviors.
Growth and change happen through a slow course correct with buy-in, not by grabbing the wheel from the passenger seat mentality.
By all means, not saying that is what you are or plan on doing, just as a point of reference to solidify a point.
...
1 reply by Jonathan Doyle
May 10, 2020 6:49 AM
Jonathan Doyle
...
Hi Andrew, I concur with your points. I certainty see the approach that you have outlined as part of my phase 2. Phase 1 is just getting as many quick-wins in as possible to start helping the team improve. There then needs to be a closer look at the core challenges and try and address those. It certainly feels that phase 2 will be for a long period of time. Much training and support from me will be needed to get the guys back on-track. Moral is also key so I will have to tread carefully so that when I examine closely the root causes the team don't get caught up in a blame culture. That would be detrimental.
Hi Jonathan,

I imagine that your are using Scrum for software development and the team members that are doing the actual work are software developers.

Having started my career as a software developer and still doing some coding even now my guess is that the team either has absolutely no problem or has some technical difficulties.

When I am saying that they may have no problem what I am implying is that it is normal in software development for the progress to fluctuate. Velocity going up and down is in my opinion normal and there are many good technical reasons for it.

Software development is a very creative activity that has a lot of bumps in the road developers having to face a lot of technical difficulties. There is nothing Scrum or other methodology can do about it. Trying to motivate the developers would not help, what would help is giving them technical direction helping them with their actual technical difficulties they are facing.

When there are problems with software development using Scrum or not, people often look for non-technical problems and propose non-technical solutions to them but in reality many times the team is facing technical challenges that only the technical experts can solve. A Scrum Master that is not a developer is completely powerless when the team is facing technical difficulties, he often makes things worse bothering the developers with his useless ideas that simply have nothing to do with the actual problem.
Page: 1 2 next>  

Please login or join to reply

Content ID:
ADVERTISEMENTS

"I don't know much about being a millionaire, but I'll bet I'd be darling at it."

- Dorothy Parker

ADVERTISEMENT

Sponsors