Please login or join to subscribe to this thread
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.
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.
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.
Furthermore, considerations around direction from senior managers is important and if that is lacking which will also have bearing on current Vs future state.
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"?
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.
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.
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.
Please login or join to reply