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 ...
178
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 ...
158
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 ...
131
I think one of the main advantages is that humans and developers specifically are actually pretty bad at estimating time. Think of the nature of development too -- it's not some linear progression from start to finish. It's often "write 90% of the code in 10 minutes and then tear your hair out debugging for 17 hours." That's pretty hard to estimate in the ...
128
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 ...
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 ...
86
Don't let Scrum become the process which overwhelms everything else
I and my friends 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 ...
78
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 ...
74
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 ...
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 ...
68
Short Answer: Absolutely positively.
Long Answer: Unit tests are one of the most important practices I try and influence at my place of work (large bank, fx trading). Yes they are extra work, but it's work that pays back again and again. Automated unit tests not only help you actually execute code you're writing and of course verify your expectations but ...
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 ...
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 ...
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
If you're using Fibonacci numbers (or something similar), it limits the number of options when estimating a story. I worked with a group that used low numbers only: 1, 2, 3, 5, 8, and 13. We had a reference story that was a 5. This enabled us to easily make snap decisions on a story's complexity while doing Planning Poker. The other side effect was that ...
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 ...
59
Ideally, your software should be bug-free after each iteration, and fixing bugs should be part of each sprint, so the work required to fix bugs should be considered when assigning story points (i.e., a task that is more likely to produce bugs should have more story points assigned to it).
In reality, however, bugs surface post-deployment all the time, no ...
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
The crimes that are committed in the name of Agile these days make me sad. Lots of people are having a hard time making this transition.
Agile Manifesto: "We value people and interactions over process and tools.". When the people are clearly hurting, the process is wrong. I don't want to tell you how to do it, but will share how I do it.
In my teams, the ...
51
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.
51
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 ...
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 ...
48
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 ...
48
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 ...
Only top voted, non community-wiki answers of a minimum length are eligible
