What if team doesn't self organise?
Hi,
I've been working in software development with scrum for almost 10 years. 5 last years in SAFe. Certainly not religiously.
I'd like to present situation and would love to hear from agile evangelist how this could be resolved.
Product that is over 5 years old, is a big pile of mess at this moment, most seniors already quit, most of people are juniors. One senior and one mid don't differ much from the rest in terms of commitment and engagement. They form two teams and both of those teams are completely disorganized. They continue to create mess and bugs. Even when presented with the opportunity to start changing things, even if upper management starts to give them green light to start fixing things they don't do anything to change this situation. Even if you grab them and tell them - let's do X, let's with towards that, it's going to make things better, they'll listen, say ok and you'll see zero engagement.
What now? How do we fix this? How do we enable them?
Not that I'm thinking about it, but nothing radical like replacing them with new seniors is possible as I really don't think with the codebase that we have, seniors would stay with us for too long. I think most senior people would run away quite quickly. We've actually got few new more senior hires, but they're still in the process of learning everything and they're already scared.
I think we should learn these teams how to work at first. Try to get them engaged. Learn the existing senior and mid to have more impact on the team. I actually think we need to have some kind of engineering manager, but I know the agile evangelists don't like that. Should this be on scrum master? Should scrum master shake them a bit and actually do what I've described above? They do have one but the guy is completely new to agile, only trained by agile couch, but he doesn't have any experience and for now his doing nothing pretty much.
Read what you have written again. Consider the emphasis upon seniority and hierarchy. Is it really surprising that people are unmotivated, and fail to demonstrate the teamwork, accountability, and commitment you'd expect from Scrum Team members?
If senior leadership are too busy or disengaged to evangelise cultural change in their own company, and to communicate a sense of urgency for it, perhaps they've already failed.
My immediate reaction upon reading your post is "what part of self-organization involves having a lead?". You imply that the "existing senior and mid" should be driving the team. You also mention multiple times that someone is telling them what to do. That is an anti-pattern for self-organization, self-management.
With your experience with Scrum, you should understand that a Scrum Team is made up of 3 roles. You mention the Scrum Master and the Developers but no mention of the Product Owner. Without that role, a Scrum Team does not have anyway to focus on what work needs to be done. Product Owners own and organize the Product Backlog. They create the Product Vision to provide insights into the future of the Product. They are responsible for ensuring that the Developers are working on the most important thing for the Product.
As you explain, your Scrum Teams have Developers that are willing to do work but have no one to provide direction. They have an inexperienced Scrum Master that may or may not understand the Scrum framework and their role in the Scrum Team. But the third crucial role (Product Owner) is not represented.
How do we fix this?
Patience and attention. Ensure that the Scrum Teams have someone fulfilling all of the roles. Ensure that the Scrum Team understand the Scrum framework. Ensure that the organization understands how to effectively interact with a Scrum Team. Ensure that the organization understands the Scrum framework and the benefits that can be derived from using it. Do not focus on how to make the Developers be better. Focus on how to create a Scrum Team and make it possible for that team to control the work they do in order to provide value to their stakeholders.
Daniel, I've not mentioned Product Owner, because the product has a huge tech debt at this moment that needs to be repaid and while there's a backlog of features that Product Owner would like the team to focus on (or rather Product Owners and teams as there are two teams), PO is not super technical and while he understands there's a tech debt and understands we need to slow down with the work related to his backlog he can't really give direction for the team. The tech debt is not the only problem in that team. They do all the stuff that you'd want the scrum team not to do, eg. allowing other people to jump in and push work on them changing scope mid sprint, estimating everything in days, never caring about finishing user stories commited in the sprint etc. All those things that unexperience scrum teams usually do. And of course having unexperience scrum master on top of that doesn't help at all. They might be given someone more experienced soon, but I'm not sure if scrum master alone can handle this.
Apologies Lukasz, but after reading your post, I did not get the sense that the issues you face are related to Scrum or Agile; instead, you seem to be working in a company saddled with an unmotivated and directionless workforce. I would suggest practices and communications that enforce transparency as one way to try and improve the low morale there.
Nothing else will really be effective until that is remedied, in my opinion.
PO is not super technical and while he understands there's a tech debt and understands we need to slow down with the work related to his backlog he can't really give direction for the team.
If there is tech debt that needs to be addressed, wouldn't that be considered work needed for the Product? This is the opening statement of the Scrum Guide section that describes the Product Backlog.
The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.
Note that it does not say the Product Backlog contains all of the enhancements and new features. It says "what is needed to improve the product". Technical debt improves the product so it should be represented in the Product Backlog. If the Product Owner does not fully understand the work, the Developers will need to explain the technical debt in a way that the Product Owner can understand. It is also the Developers' responsibility to help the Product Owner understand the potential impact of not addressing it.
This is a statement from the Scrum Guide that describes the Product Owner role.
The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.
It is not uncommon for a Product Owner to be untechnical and to delegate the responsibility for capturing technical needs in the Product Backlog. That is often delegated to someone that is included in the Developers role.
eg. allowing other people to jump in and push work on them changing scope mid sprint,
This is something the Product Owner and Scrum Master should be working to change. If there is a change needed to the product, the Product Owner should be the one that introduces it. The Scrum Master should help those that are interrupting understand the best way to interact with the Scrum Team.
estimating everything in days
There is nothing in the Scrum Guide that says this is wrong. The Developers are the ones responsible for sizing and if they choose to do in days, then no one can say it is wrong.
never caring about finishing user stories commited in the sprint
The commitment for a Sprint is not finishing all the user stories. It is about satisfying the Sprint Goal. And in my experience it is quite common to have stories in the Sprint Backlog that may not support the Sprint Goal but have been deemed as important and pulled into the Sprint.
but I'm not sure if scrum master alone can handle this.
The Scrum Master shouldn't handle this. The Scrum Team and the organization as a whole should. The organization should give the Scrum Master the support that they need. You mentioned in your original post that the Scrum Master was trained by the Agile Coach. It seems to me that the Agile Coach would be the ideal candidate to help the Scrum Master gain the experience needed. If in fact there is an Agile Coach that is experienced, they should know the concept of servant-leadership and be willing to help the Scrum Master.
You keep trying to make this the fault of the developers. But I do not see it as such. I see this as an organizational issue that requires more change than people are willing to make. A Scrum Team is only as strong as the organization that supports it. If they are not given the adequate support, no one has any right to expect that they will excel.
I do want to point out that this is entirely my opinion. Others may have differing opinions. I would encourage you to wait to see what others say and then form your own opinions on how to help your organization deal with this situation.
You keep trying to make this the fault of the developers
It may sound like it, but I'm 100% sure poor management has led to the current situation. Those guys were actually part of smaller company before. Only current company sees the problem and is willing to make the situation better.
you seem to be working in a company saddled with an unmotivated and directionless workforce
As above here, I think mostly this relates to the company before acquisition. I'm quite new to the company too, but I'd like to help those guys.
Are you sure you want to work for this company? Because, if a student can`t organize himself/herself, it's ok (at uni I also asked companies to write my assignment for me uk ahahahah). But at work I understand that this is my money and I want to work here. But if nobody wants to work, the owner has a huge tech debt so I don`t know…
What to do? Maybe, try to support them, explain what Scrum is and how things should be. Maybe you also should figure out why they’re so uninterested. But now it sounds like an almost impossible situation.
I'd look to see what leadership wants to get out of agile. The same answer should be on all of leaderships lips. They may be wanting something that agile isn't meant to deliver (certainty).
If you can redirect people to think that agile is not only better, but it's safer, you'll have a better chance of success than just convincing people it's better. At least that's what I've found.
This is a rough situation. Consider reading "Influence" by Robert Cialdini. Just what's in the book for the betterment of the group and not to manipulate.
BTW, I love the typo: "only trained by agile couch" I want to be a couch too. It seems relaxing!