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


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


71

There's nothing wrong with working out your algorithms on paper first. Not so much for everyday coding, but for more complex algorithms, professional programmers work them out on paper or a whiteboard all the time, especially if a graphical format makes it more clear. For a student, every program is complex. If you want to get better at designing ...


69

This is a perfect example of the excluded middle fallacy. Yes, writing out the whole program on paper before you touch the actual keyboard is a bad idea. But that doesn't make the opposite extreme--immediately jumping into the coding and starting to hack away--a good idea. In fact, it's even worse. It's very important to understand what you're trying to ...


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


51

I think (and I may be going out on a limb here) that ALL projects should have a bit of classic waterfall: The initial analysis and specification phase is essential. You must know what you are doing, and you must have it in writing. Getting the requirements in writing is difficult and time consuming, and easy to do badly. That's why so many skip it - any ...


36

I'm still amazed that many people think that TDD means writing unit tests first. No it means writing tests you will need before you write the code. The test actually can be unit test, integration test, end-to-end test and of course performance test (well you will probably not write performance test before the tested code but it doesn't mean you should not ...


35

You think Michelangelo just climbed to the top of the Sistine Chapel and just started drawing? Test drawings were made. Approvals from the Pope were needed. There was scaffolding to be built. Templates made to guide the group of other artists. The restoration was even more complex. If I want to build an application and I don't have to consider the design ...


31

According to the Scrum Guide: The Sprint Planning Meeting is time-boxed to eight hours for a one-month Sprint. For shorter Sprints, the event is proportionately shorter. For example, two-week Sprints have four-hour Sprint Planning Meetings. That generally works for me.


27

if you want to be just a programmer, then you wait until someone else has figured out what the client needs and then code that if you want to be a developer, and this is your client, then you take your client's hand and gently walk them through the dense scary forest of possibilities until together you find the happy bunny-filled meadow at the intersection ...


27

As long as it needs to last, no less and no more. Anything else isn't Agile. If you have a team of 2 - 3 developers and are doing 1 week sprints anything more than a hour is probably counter productive. If you have a team of 15 people and 2 weeks sprints you are looking at all day, anything less isn't detailed enough. It takes experience to get it mostly ...


21

I think it is all about forming a balance. It is impossible to think of everything before you type it all out, which is precisely why the Waterfall model is so broken. At the same time, if you do too little thinking, you can cause a big mess for yourself when you get past the first several iterations. After all, you cannot beat all code into shape, and it ...


20

The premise of the analogy is wrong: many writers outline or at least think out what they are going to write before they start writing, and many painters and architects will do dozens of studies and sketches before they start on their actual "work". Given that the analogy is wrong, the answer is yes--programmers should work like writers, painters and ...


20

This answer is written from the perspective of someone who had such a performance management system put in place around an Agile team; like you, everyone on the team realized the difficulty/uselessness of year-long SMART goals applied to an Agile group, where, when fully functioning, the implementation of Agile can be considered inherently/already SMART. No,...


20

What is the reason for [their estimate of 2 days taking 8 days], is this common for programmers? It is, if: It isn't actually clear what they're supposed to do, so they take more time getting it right (and they should then say so, not guess about how long it will take) They're unfamiliar with the task at hand (then they should mention that and include ...


20

Consider the Project Manager's point of view By asking for complexity they want a number that they can compare with your next sprint to find your velocity as a team. They may also be trying to use it to add together your result with the estimates from other teams to provide an over all estimate on when all the stories will be done. The project manager is ...


20

You're right - 5 hours in Sprint Planning for a 1 week Sprint does seem like a long time. The Scrum Guide time-boxes Sprint Planning to 8 hours for 1 month Sprints and says that "for shorter Sprints, the event is usually shorter". If you consider the ratio, a good target may be 2 hours of Sprint Planning for a 1 week Sprint, but there's no fixed timebox. So,...


19

As a lone developer, what can/should I do to make sure I am learning, There are books you can read. There are user-groups/meetups where you can talk with other developers. There is a code review site here where you can post code (that isn't vital/identifyable to your company) to get feedback. These are all fine, but no substitute for good practice. In ...


17

You say you "use retrospectives." But what does the team actually do in these retrospectives? Since you've gone 18 months without once addressing this aspect of your process, I'm guessing the answer is: nothing very useful. To me, the retrospective is the most important part of the process. Throw out or change anything else about scrum all you want (by ...


16

[our product was] too slow to use, buggy, becoming labyrinthinly complex and completely inflexible. That has nothing to do with agile, it's a sign of programmers not doing their job properly. One basic idea of agile is that the team has complete control over the process. That means they must agree on the amount of planning, documentation, testing and ...


16

Why is the argument that you'll produce a better quality product in Java weak? Assuming that the technology you are familiar with can be used to (relatively) easily implement the solutions you require you should go with the technology you (as developers) know for several reasons: You are more familiar with the libraries, frameworks and tools so you'll work ...


16

Go for it! If we call what you are doing thinking and designing your solution, then it makes sense your process will be much faster than just blasting out code. People like to think (and the noisy ones like to tell us) that their way of doings is better. But everyone's ability and skill mix is different. So do what works for you. As you gain practice, you ...


16

The general techniques are somewhat common-sense, the important thing to know is that they don't require much technical expertise. The starting point with planning is to identify the exact problem that needs to be solved and have a clear and unambiguous requirement. If you don't have that, your estimates will be incorrect. Having this documented in some ...


16

You can solve this problem with a free and simple solution. In our team, if we ever forget our planning poker cards we instead use our hands i.e. We clench our fists and show our estimates all at the same time. We find that this approach works very well as usually our estimates are on average at most eight points and any 13 point estimates are followed by a ...


14

P. Brian Mackey is right about TDD being useful - and any unit tests will improve things dramatically. As a tester, I can tell you that a thorough unit test suite dramatically decreases the number of bugs, and limits the remaining functional bugs to mostly a few predictable areas where I can focus my testing (mostly integration points / environmental ...


14

how do you handle dependencies in sprint planning? Ideally, non-development dependencies are handled before sprint planning, so that you have a good definition of the backlog item to estimate effort against. But, if that was "just development for you" last sprint, then that was probably going to be just development for you this sprint, so you should really ...


13

He seems to like things being defined formally, so a timer would be a good idea, since planning poker is defined as having set amounts of time for people to speak. He's got the wrong idea about estimation too, everyone estimates against the story and not the implementation, which is why you get such variance. For example some people may be ignorant of a ...


13

The situation you describe is toxic. This sort of bargaining ignores reality and the expertise of the team, it willfully conceals information from the team and organization at large, and it inhibits the team from improving over time. If you want to city http://www.scrumguides.org/scrum-guide.html as an authority I would highlight: Only the Development ...


13

I like the other answers that say to put as much "tooling" code as you can into Iteration 0. However, sometimes, these kinds of tools come up after the project has already started. Perhaps in Iteration 3 you realize you need a generalized XML parser widget to be used on various stories going forward. In that case, the first User Story that relies on these ...


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