3 ms·

> Despite working in a a Scrum team, I recognise literally nothing of the problems that are described. Same. This process takes work, requires buy in by all le

> Despite working in a a Scrum team, I recognise literally nothing of the problems that are described. Same. This process takes work, requires buy in by all levels of the company and needs to be fully understood including its error cases. It takes time and requires course correct and attention. Its not easy but done right it is effective.

yebyen 8y ago
> done right it is effective. That is one of the problems highlighted in the article though, too. What is the appropriate level of training for a scrum master and scrum team? Should we read the Scrum Guide? Are we reading the Scrum Guide? Do we actually know what Scrum is? Do we even know that we are doing Scrum? I am working on a young, small team, and we started with an expertly trained scrum-master about 30 sprints ago. She was so well-trained that she was promoted out of our team. Since we started, we've had about 72% turnover. I'm the only original member of the team who is still on full-time except for the product owner... and reading this article, I am coming to find out that our product owner is not doing the job of product owner (mostly our new project manager is.) And > apparently it has to involve something called “Jira”. hits me right in the feels! We have been working with one project management tool (not Jira) since the beginning, and we found another tool that we like (the dev team likes) better. Doesn't matter what the tools are. Bear with me. The first tool is used to communicate with our product owner(s) or stakeholders, where we get their acceptance of stories, and the second tool was meant to be a place where we developers can own tasks and "blog" about our progress without adding noise to the stakeholder channels. A task list that we control. Again, neither tool is Jira. We did a trial, and we quickly found by consensus of opinion and observation that it really helped us a lot to add this tool to our process, all of the developers were buying in! Brought it to management to get it added in the budget... really a nominal sum, but then we were told we had too many tools already and made to abort the trial. I was devastated, but I played along. It was the wrong decision! I started using slips of paper to fill the void, a place where development issues that are not part of our product backlog can live outside of the backlog and the sprint, and now in my perception at least, we're more disorganized than ever as a team. I believe you both, that Scrum can work well if done right, and I'm glad it's working well for you, but ... I think at least some of us definitely need to hear these stories, many of them are our own stories, properly articulated so we can understand what's going wrong in our teams.
- alistairSH 8y ago
  With turn-over like that, nobody is going to be successful. What is driving the turn-over? Are team-members being moved elsewhere, or are the quitting out of frustration? As for training for the SM (or PO, or anybody else), it's a continuous process. The CSM is a starting point, a basic level of understanding. At my office, many of us have gone on to take the Advanced CSM course. Most of us attend meet-ups, conferences, etc. It's not a once-and-done thing - nothing in a professional career ever is - if you aren't learning and improving every day, you're not doing your job.
  - yebyen 8y ago
    > What is driving the turn-over? Are team-members being moved elsewhere "72%" is really misleading... from the original team of 2 developers and one PM/Scrum-Master, the Scrum-Master was promoted to a newly formed team, and the other developer is still with us, but in a mostly consulting-only capacity, as she is focused on other projects in our team. Nobody is quitting out of frustration. (Not yet anyway!) We've since added two new developers from other groups within our organization, and a new PM. We're talking about a greenfield project with some inherited/appropriated/shared code from other projects on our (slightly larger) team, a mostly new dev effort, and we're approaching year 3 of development. For a dev team this small and a project of this scope and duration, I feel like this is almost an appropriate level of turnover. We have to strike a balance between spreading the domain knowledge around, and keeping the expertise near the "most important project," which is obviously the particular one that we're working on. (/s) The big problem is training, or lack of... the SM that left our team was practically the only one of us with any formal training in terms of either development skills or Project Management. The rest of us have learned basically everything "on the job." We've been exposed to some training opportunities for "business analyst" skills development, which is our organization's take on a little bit like "Scrum-lite" but I am not sure that's for all of us. (I'm working in higher-ed so there are a lot of training opportunities in-house. Just not sure they are the right ones. Most teams in our building just aren't doing product development, so we are special snowflakes.) I've taken some of those BA classes. We really need more technical training. We probably need a larger team too, but hiring is very difficult for us, and in reality I think we're going to have to cope with more of our team members being poached by other departments as we become more successful. Some members of the team have participated in bootcamp-style training courses for our chosen framework. In every case, it was years ago, some time before I arrived on the scene. I have not had any of this, just some prior on-the-job experience and also have read a book or two to pull myself up by bootstraps! We're all learning on the job, and we have a conference budget so we're getting exposed to plenty of new ideas each year, but that's nothing like a formal training day where we all hammer a particular skill until we all get it, or even a sprint that's dedicated for training. Second major problem is that we also usually don't have sprints or stories devoted to addressing technical debt. No refactor stories, basically ever. Basically all story cards must be customer-facing and represent some new, testable functionality for some functional user of the product. This part of the article also struck me as poignant: > The items promoted in the backlog, combined with the schedule pressure set by the product owner and the business mean that the Development Team often are told how to create releases: quickly and exactly how we said. The lack of technical craft or development control means each sprint is launched as soon as possible rather than as soon as prudent, refactoring isn't done, and technical debt builds up, eventually choking the product. When every story is a feature story or bugfix, this is what you get. When the team says "we need to learn this skill first, so we don't add unnecessary technical debt in the next sprint" and are overridden by the PM's boss and told to stick to the planned release timeline at all costs, we lose. > As mentioned above, the lack of titles or specific responsibilities in the development team means no-one is empowered to advocate for development priorities, and also contradicts the typical implementation where there certainly are titles and hierarchies within teams ... exactly this. We're told that the development team as a whole is accountable for progress, but when everyone is responsible, nobody is. You can't call someone a technical lead and then confine their decision-making to minutia within the already-planned sprint work. That's not really how I feel about my team, but I feel like sometimes circumstances put the pressure in that direction. This is getting too personal, but suffice it to say I really agree with this article about a lot of points.

yebyen 8y ago

> done right it is effective. That is one of the problems highlighted in the article though, too. What is the appropriate level of training for a scrum master and scrum team? Should we read the Scrum Guide? Are we reading the Scrum Guide? Do we actually know what Scrum is? Do we even know that we are doing Scrum? I am working on a young, small team, and we started with an expertly trained scrum-master about 30 sprints ago. She was so well-trained that she was promoted out of our team. Since we started, we've had about 72% turnover. I'm the only original member of the team who is still on full-time except for the product owner... and reading this article, I am coming to find out that our product owner is not doing the job of product owner (mostly our new project manager is.) And > apparently it has to involve something called “Jira”. hits me right in the feels! We have been working with one project management tool (not Jira) since the beginning, and we found another tool that we like (the dev team likes) better. Doesn't matter what the tools are. Bear with me. The first tool is used to communicate with our product owner(s) or stakeholders, where we get their acceptance of stories, and the second tool was meant to be a place where we developers can own tasks and "blog" about our progress without adding noise to the stakeholder channels. A task list that we control. Again, neither tool is Jira. We did a trial, and we quickly found by consensus of opinion and observation that it really helped us a lot to add this tool to our process, all of the developers were buying in! Brought it to management to get it added in the budget... really a nominal sum, but then we were told we had too many tools already and made to abort the trial. I was devastated, but I played along. It was the wrong decision! I started using slips of paper to fill the void, a place where development issues that are not part of our product backlog can live outside of the backlog and the sprint, and now in my perception at least, we're more disorganized than ever as a team. I believe you both, that Scrum can work well if done right, and I'm glad it's working well for you, but ... I think at least some of us definitely need to hear these stories, many of them are our own stories, properly articulated so we can understand what's going wrong in our teams.

alistairSH 8y ago
With turn-over like that, nobody is going to be successful. What is driving the turn-over? Are team-members being moved elsewhere, or are the quitting out of frustration? As for training for the SM (or PO, or anybody else), it's a continuous process. The CSM is a starting point, a basic level of understanding. At my office, many of us have gone on to take the Advanced CSM course. Most of us attend meet-ups, conferences, etc. It's not a once-and-done thing - nothing in a professional career ever is - if you aren't learning and improving every day, you're not doing your job.
- yebyen 8y ago
  > What is driving the turn-over? Are team-members being moved elsewhere "72%" is really misleading... from the original team of 2 developers and one PM/Scrum-Master, the Scrum-Master was promoted to a newly formed team, and the other developer is still with us, but in a mostly consulting-only capacity, as she is focused on other projects in our team. Nobody is quitting out of frustration. (Not yet anyway!) We've since added two new developers from other groups within our organization, and a new PM. We're talking about a greenfield project with some inherited/appropriated/shared code from other projects on our (slightly larger) team, a mostly new dev effort, and we're approaching year 3 of development. For a dev team this small and a project of this scope and duration, I feel like this is almost an appropriate level of turnover. We have to strike a balance between spreading the domain knowledge around, and keeping the expertise near the "most important project," which is obviously the particular one that we're working on. (/s) The big problem is training, or lack of... the SM that left our team was practically the only one of us with any formal training in terms of either development skills or Project Management. The rest of us have learned basically everything "on the job." We've been exposed to some training opportunities for "business analyst" skills development, which is our organization's take on a little bit like "Scrum-lite" but I am not sure that's for all of us. (I'm working in higher-ed so there are a lot of training opportunities in-house. Just not sure they are the right ones. Most teams in our building just aren't doing product development, so we are special snowflakes.) I've taken some of those BA classes. We really need more technical training. We probably need a larger team too, but hiring is very difficult for us, and in reality I think we're going to have to cope with more of our team members being poached by other departments as we become more successful. Some members of the team have participated in bootcamp-style training courses for our chosen framework. In every case, it was years ago, some time before I arrived on the scene. I have not had any of this, just some prior on-the-job experience and also have read a book or two to pull myself up by bootstraps! We're all learning on the job, and we have a conference budget so we're getting exposed to plenty of new ideas each year, but that's nothing like a formal training day where we all hammer a particular skill until we all get it, or even a sprint that's dedicated for training. Second major problem is that we also usually don't have sprints or stories devoted to addressing technical debt. No refactor stories, basically ever. Basically all story cards must be customer-facing and represent some new, testable functionality for some functional user of the product. This part of the article also struck me as poignant: > The items promoted in the backlog, combined with the schedule pressure set by the product owner and the business mean that the Development Team often are told how to create releases: quickly and exactly how we said. The lack of technical craft or development control means each sprint is launched as soon as possible rather than as soon as prudent, refactoring isn't done, and technical debt builds up, eventually choking the product. When every story is a feature story or bugfix, this is what you get. When the team says "we need to learn this skill first, so we don't add unnecessary technical debt in the next sprint" and are overridden by the PM's boss and told to stick to the planned release timeline at all costs, we lose. > As mentioned above, the lack of titles or specific responsibilities in the development team means no-one is empowered to advocate for development priorities, and also contradicts the typical implementation where there certainly are titles and hierarchies within teams ... exactly this. We're told that the development team as a whole is accountable for progress, but when everyone is responsible, nobody is. You can't call someone a technical lead and then confine their decision-making to minutia within the already-planned sprint work. That's not really how I feel about my team, but I feel like sometimes circumstances put the pressure in that direction. This is getting too personal, but suffice it to say I really agree with this article about a lot of points.