Hot answers tagged

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


182

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


152

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


132

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

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


125

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


89

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


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


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

I've been struggling with the same question a bit lately. We are starting on the next iteration, but I feel that this removes the satisfaction of an iteration well done. I am thinking about the option of leaving it up to the developers, with the caveat "as long as the intent is to benefit the company." Examples: Spend the day learning something Spend it ...


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


67

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


60

Your problem is not Scrum (and as Jarrod Roberson mentioned in comments, it is not Scrum what you're describing) - it's Product Owner's micromanagement and your (and Team's) lack of assertiveness. "However, due to scrum methodology, now many decisions simply come from product owner. He prioritizes PBIs, he analyzes how software should work, even sometimes ...


60

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


59

Ex ante: There seems to be a lot of confusion on what is regarded as testing what is not. Sure, every developer needs to test his code as he creates it, he/she needs to verify it works. She/he can't hand it to a tester before he/she thinks it's done and good enough. But developers don't see everything. They might not recognize bugs. These bugs can only be ...


58

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


57

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


54

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


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


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

However, I now feel like I'm always getting told to do something, instead of deciding to do something. This is a serious indicator that something has gone off the rails. An agile project should not feel like this. That "people over process" rhetoric should include "we don't force our people to do things that suck." Here are some ideas: Are you doing "scrum ...


50

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


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

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


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


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