193

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 ...


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

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 ...


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

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

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 ...


6

In agile development, do whatever works. Identify impediments and remove them – if getting items assigned prevents you from being productive, find some solution to that. If you're trying to implement the Scrum process, it sounds even weirder that the Scrum Master is getting itemd assigned: The Scrum Master is just a role that takes care that the Scrum ...


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. ...


4

Canonically speaking, do whatever works for your team. That said, I'd suggest that A two-phased approach to documentation is ideal. Phase 1: Before the retro, each team member documents their own feedback privately. Phase 2: During retro, perform a round of "what went well" followed by a round of "what didn't go well." Document the main points, decisions, ...


3

One of the features of kanban, which I believe bleeds over into scrum, is that the process as a whole optimizes for the team, not the individual. In other words, it's no sin if someone on the team is idle for part of the sprint. If the team as a whole chooses X story points, it really doesn't matter (to the stakeholders) whether one person did all the work ...


3

Is my understanding of average velocity and sprint commitments correct? Unfortunately, you've been misinformed about a few things regarding Sprint Planning in Scrum. First, the Development Team (DT) is ...structured and empowered by the organization to organize and manage their own work. - Scrum Guide The word for this is self-organizing. This includes ...


3

If you are the scrum master and product owner you are a project manager pretending to do scrum. The product owner absolutely has to be someone from the client that is empowered to approve stories, prioritize stories, and accept stories as complete. This is necessary because it forces the client to be involved in the process and there expectations should ...


3

First, your velocity is from your previous sprint, or sometimes from an average of a few recent Sprints (Yesterday's Weather), and not an average of all past sprints. Of course, if you have no historical data from your team or company, you need to come up with a reasonable value for your first sprint. On your second sprint, you take in the completed story ...


3

Address this issue with the following techniques: Daily scrum to review progress. If people aren't making progress at a reasonable pace it will become more obvious to everyone day by day. If a problem is suspected the product manager or line manager can review recent stories and their points and see if there is an issue that persists over time. Continual ...


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