192

You may have heard a lot of statistics about failed software projects and came to the conclusion that the failure is not of a technical nature. Technological problems can be solved via hundreds of technical solutions, but solving problems in your workplace atmosphere by using Scrum is not going to work. My suggestion here is to completely stop looking at ...


65

In my experience, teams who are disillusioned need to start by having effective retrospectives. That's why in my opinion retrospectives are the only mandatory part of an agile process. Everything else is subject to change through the retrospectives. In effective retrospectives, you don't just complain about your issues, you choose at least one of those ...


60

This problem is as old as scrum. There is a solution, but you won't like it. Put new tasks on the backlog. Don't interrupt developers. Wait for the next sprint. Putting your devs in more than one scrum, having two separate backlogs or assigning only a percentage of their time to the sprint all work against what scrum is trying to achieve, i.e. a ...


47

Ok so let's start rough - big part of the problem is with you - You hear, but you don't listen. Your team is telling you clearly what the problems are. You need to address them instead of blaming your team. Planning To them, Planning is just a waste of time, because we just move overflow into the new Sprint and don't complete the work anyways, so why ...


25

Just trying to think outside the box here. As it might not be possible to get the product owner see things your way. There still might be critical errors that simply can't wait, meeting with clients where developer assistance is needed etc. where you need to take one developer out of the sprint for a while. Why not try to anticipate this and use it for ...


20

You need to de-scope the least important stories and move them to the next sprint. Your capacity has changed and the sprint should reflect that. If the customer adds a new, high priority big story, what do you do? Accept it and add it to the sprint? Re-plan? Change the burn-down chart? Bite the bullet? No. You de-scope other stories as you don't have ...


14

An effective solution for managing developer effort for truly essential production issues that I've used is the "Batman approach". The expensive aspect of production support responsibility while developing new functionality is context switching, so you should aim to limit that. With the team's buy in, create a list of the team members and cycle through it, ...


13

Embrace this... you see, Agile does NOT mean the proscribed ways of working are what you have to do. It means you get to decide what works for you and do exactly that. Now I'm sure, given that advice, your team will become effective immediately with the Cobol guys doing their thing and communicating with the .NET guy who'll do his thing. Hopefully they'll ...


12

Speaking as a developer who was trained up as a scrum master I'd say that if you are serious about using agile, and the people around you are too, then it's well worth training up. A scrum master should know how the agile process works, which meetings are required, what peoples' responsibilities are etc It's your job to make sure the agile process flows ...


12

Is my understanding of average velocity and sprint commitments correct? Yeah, you have the gist of it. If not, what have I gotten wrong? The thing you overlooked is that story points are the things you get done. It is nigh impossible for everyone to work on stories right up to the end of the sprint. If you're doing things right, most of your developers ...


11

Agile follows several principles. One of them is: Empower people. Because of that tasks should be defined by team and tasks should be selected by team members. Tasks should not be assigned to team member. The team should be self organizing and because of that distribution of hard / easy / interesting / boring tasks should be even. Scrum master should ensure ...


10

One of major agile principle is to go back, and correct whatever is wrong. That doesn't only include code refactoring and bug fixes, but also fixing the development process. So, why don't you make a meeting with your team, and see how can you improve development process? If that means, no scrum or standup meetings, then be it. Also you are breaking one of ...


9

As I priority, I'd look at tasks which keep getting carried over. Not meeting targets is hugely demoralizing. Are you committing to too much? Are there fatlogs that should be broken down? Are there bottlenecks outside your control? Do you have a clear definition of "done"? Are the requirements clear? Are the hours per developer reasonable (i.e. takes into ...


9

There's no prescribed way to document Retrospective feedback, but there are some things to consider. The most important thing to consider is that the team needs to be able to be open and honest. If you are using an electronic tool and requiring people to complete retrospective notes before a meeting, then it is likely that the authorship of those notes may ...


9

My first suggestion would be to fix your terminology to improve communication, both internally and externally. You are using terms like "Scrum Master", "Sprint", and "Sprint Review". These are terms from Scrum. Scrum is a well-defined process framework with specific roles, responsibilities, events - it has rules and those rules are defined in the Scrum Guide....


7

There are official Scrum training courses as well as assessments and certifications that cover various roles in scrum - Scrum Master, Product Owner, development team member. For these, it's simply a matter of optionally taking a course, reading the recommended material, working through the assessments, and then paying to take a certification exam. I'm not ...


7

You say "I didn't do any work for those features to work properly" but that's not strictly true. While you didn't write any code, you did spend some time testing, and testing is valid work just as much as writing code is.


7

The Scrum Master is supposed to be several things: A coach to both the team and the organization. Someone who teaches and guides the team and organization on the implementation of the Scrum framework and removes any impediments to the team's success. A facilitator. Someone who helps to ensure that the events, ceremonies, and process works as the team and ...


6

tl;dr: The Scrum Master is a Facilitator -- it does not denote mastery of anything. Is this an official certification or just someone who specializes? What are the steps towards becoming one? There is an official "Certified Scrum Master" designation. It is an introductory course managed by the scrum alliance. If you take the course and pass the test, ...


6

I'd agree with Thomas on the generalities, but focusing on the scrum master role itself there's an important point to note. It is not a technical role. We discussed this a little on the scrum master training I attended recently, If you want to write code then on paper 'being a scrum master' probably not for you. That said, in practice It seems people wear ...


6

Should developers assign tasks to themselves or is it the responsibility of scrum master accompanied by product owner? I places where I've worked that have followed Scrum we've done both, though ideally developers should pick their own tasks. Ultimately it doesn't matter as long as all the tasks get done. There are pros and cons to each approach. Letting ...


6

So, how officially are issues of dependencies between stories and inherently serial stories handled by the methodology? As with anything else in Agile: Individuals and interactions over processes and tools If your process isn't serving you, then you mold it into something useful. For this, I would pull in lower priority stories (or some technical debt/...


6

When a story isn't done at the end of the sprint, then the points of the story don't count towards the velocity of that sprint and the story goes back onto the backlog. If during the planning of the next sprint the story is selected to be finished, then you can do a quick re-estimation of the remaining work. This estimate should only be used during the ...


5

Do not try to make your velocity look better than it is. The way forward is to acknowledge that the task was not completed you overestimated what you could do in the sprint and failed. But that is life, and an opportunity to learn. So 0 points for the incomplete task. As for the new sprint, estimate the work needed to complete the task in story points and ...


5

Getting your team to close your sprint effectively (like at least close 80% of stories) sprint over sprint is in my opinion the single most important thing you can do. If your team is consistently missing, then that's a clear indication that you need to adjust your estimates. The team should be receptive to this, though it can be very hard to get developers ...


4

To understand how to approach the problem you need to first understand from your superiors what the ultimate business goal is for having a cross functional Agile/Scrum team. Once you know that and understand the business perspective as well as understand the culture of the company and the goals of the individual members of the team can you begin to address ...


4

In this environment, your organization is the customer and the other organizations are the development organizations. Your organization should be providing Product Owners to the Scrum teams that are doing the development. Personally, I don't understand the need for a Scrum Master in your organization. Each of the developing organizations should be executing ...


4

As a Scrum Master you coach and guide the team to become more productive. The Scrum framework is a powerful tool to get there, but the Scrum framework absolutely must not ever become the goal by itself - otherwise you're doing Cargo Cult. It seems you've been doing Cargo Cult for 3 years now and people realized that's a horrible project management ...


4

Now, since I didn't do any work for those features to work properly, in order to reflect correctly what was done for those tasks should I close them unassigned in the backlog directly or put them in the sprint, assign them to me and close them? IMO you did some work: you tested it. Therefore, I would include in the sprint, assign it to me and close it. ...


Only top voted, non community-wiki answers of a minimum length are eligible