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 ...
183
Good answers so far, but they don't cover all the bases.
In my experience, many people fresh out of college have fantastic theoretical knowledge - far better than me or many other seniors with decades building software for a living.
BUT, and that's a big BUT, that knowledge isn't grounded in any practical scenario. In the real world, a lot of that theory ...
179
Don't let Scrum become the process which overwhelms everything else
My friends and I, who are part of Scrum teams are not fans of it. The reason is that in being the one process which has a dedicated process manager, it usually bends and breaks every other process to it and becomes this overarching process where you do nothing consistently except Scrum ...
159
Well, it's perfectly simple to increase velocity by 40% - just add 40% more points to all your estimates and do the same amount of work.
Given that this is so, it should be apparent why using velocity as a target is wrong, it just encourages inflated estimates.
A less glib answer is that your estimate already assumes you are going as fast as you can ...
151
You should first ask, 'who cares'?
Completing sprints feels good, and in some companies results in cookies from the scrum parent. But the ultimate test is whether the company is meeting its goals.
The above is facetious. If the company is succeeding while never completing the planned content of a sprint, you might as well use Kanban instead: you sort the ...
133
I see several fundamental management issues in your example:
if a Scrum-Addicts manager signs a "hard-deadline" contract, but adds only a safety margin of 33% in a situation where "a new system is involved", that is pretty reckless.
the availability of delivering at least x% of the features after one month could have been used to negotiate a contract ...
129
Am I missing something?
YES!
You went 18 months - or somewhere in the neighborhood of 36 sprints with retrospectives, but somehow couldn't fix it? Management didn't hold the team accountable, and then their management didn't hold them accountable for not holding the team accountable?
You are missing that your company is pervasively incompetent.
So, how ...
104
How do I prevent scrum from turning great developers into average developers?
By doing it correctly. All those horror stories I read, being it yours or the other answers, only tell me one thing: those people did not do it correctly. And I get it, it's hard. It's super easy to slap down some rules and have them followed, but that is not Scrum. Scrum is ...
88
If you are using Git, each developer would be pulling from the develop branch into their own feature branch so that they ensure they don't go too far from the current baseline. They can do that daily, so that tasks that take more than a couple days stay in sync and merge issues are resolved while they are still small.
When the developer is done with their ...
81
The formal answer is you misunderstood agile, agile does not dictate requirements, stakeholders do. The core of agile is not to carve your requirements in stone but rather have them emerge as you go, in close contact with your client, benefiting from progressive insights.
But that's all theory. What you have witnessed is indeed a common trait of many ...
77
A few things stand out to me.
The idea that management has that the team commits to a set of work is inconsistent with the latest versions of the Scrum Guide. The word "commit" or "commitment" is only used twice in the most recent (November 2017) version of the Scrum Guide - once when listing the Scrum Values and once to indicate that "people personally ...
75
There doesn't even seem to be a place for attractive qualities in agile.
You are comparing apples and oranges. In traditional waterfall, if your requirements say you need the must-haves, you get a Fiat. If the requirements say it has to be top notch, you get a Ferrari.
The same happens in Agile. If your requirements stop at must-haves, you get a Fiat. If ...
74
You are considering deleting the records of genuine problems with the codebase because the product owner wants a shorter backlog?
For me, the only reason to delete (close) an item in the backlog is because you decide it will never be implemented, not because it won't be implemented for a while. Also, in an agile environment, priorities may change quickly and ...
69
I believe that it's a faulty assumption to say that there are projects where the requirements don't change. Having worked in both the defense industry and the pharmaceutical industry making software, I can tell you that once software ends up in the hands of subject matter experts (either internal or external), there is feedback. Sometimes, this feedback is ...
66
One of the value statements of the "Manifesto for Agile Software Development" is :
Customer collaboration over contract negotiation
The fact that Scrum-Addicts LLC negotiated a contract instead of establishing a collaboration with a customer makes me question their agility.
One thing is clear : Agility needs to be accepted by EVERYONE. Agility is not ...
66
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 ...
65
Scrum is a process framework defined in the official scrum guide, which says, among other things, the following things about the daily scrum:
The Daily Scrum is a 15-minute time-boxed event for the Development Team.
The structure of the meeting is set by the Development Team.
The Scrum Master ensures that the Development Team has the meeting, but the ...
61
My question is basically: when is it fair to look for the problem in the quality of the developers
There isn't enough information in your post to answer that question. There's no way to know if they are failing because they are incompetent, or failing because they commit to doing more work than is reasonable.
If I'm an incredibly gifted developer, on a ...
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 ...
56
This has nothing to do with Agile or Scrum.
The problem with "duct tape it now and we'll fix it later" is that later never comes and in the mean time you are accumulating a lot of technical debt.
The first step to recovery is to recognize the problem and stop making it worse.
For every new user story, the team should consider "what's the right way to ...
53
As the comments have pointed out, the request is obviously wrong the way it has been put. But he's not really wrong to want to constantly improve productivity. As a rule, that is what managers strive (and are evaluated) for.
That said, managers are always looking to improve performance, and Scrum and Agile is all about being adaptable. While velocity is ...
53
If you work in a company that doesn't place any value in paying down technical debt, you may have no choice but to do unticketed work.
Stakeholders are generally not qualified to make decisions about this kind of work.
Include unticketed work as part of your ticket estimation process.
52
In this case I would simplify to Kanban. Kanban simply has a backlog that you work off, so there is no need to organize work into sprints. It's best not to over-complicate things. Considering this is a stretch of work that would be only one sprint, and a very limited staff, I think it matches the Kanban way more than scrum.
50
Nothing in agile changes how the lead developer should function. They should be involving the rest of the team with system architecture decisions, and technical direction no matter what development model is being followed.
Handing out decisions by edict is a terrible way for any development team to run. Agile just makes getting buy in from the rest of the ...
49
Alright, so someone's enthusiastically writing great code that needs to be done, just not in order. With all due emphasis:
LET THEM
It's causing some complications in your scrum sprints. Does it really matter in the grand scheme of things? If he's accomplishing what he's supposed to, then let him go on and build great things for you.
I know several ...
49
At the beginning of the sprint there is nothing to test yet
Really? You have no requirements to validate? No discussions to have with your customer? No wire-frames to evaluate? No test plans to think about?
at the end of the sprint there is typically nothing or very little
left to develop/fix
I have never been in that place in a project. No more work ...
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 ...
44
Yes but with a lot of care!
Let me clarify that.
You should strive to improve the habitability of the software. If you look at the code/team/business/project/management and your first response is to take a shower, then it is not habitable. If your first response is to shout yeah!... and then complain when you are turfed out of the office, then you need to ...
43
In other words it's not sustainable.
Right.
You don't run a sprint for months at a time in most Agile (well functioning ones, I'm sure some "we wanted buzzwords so we're an Agile waterfall shop" do), you have short sprints, followed by new planning/retros/etc.
That's the point.
Why do Scrum teams use the word "Sprint"? It appears to me to conflict one ...
Only top voted, non community-wiki answers of a minimum length are eligible
