Hot answers tagged

145

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


126

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


69

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


66

I'd like to suggest you to make a small change and try Kanban for couple of weeks instead of Scrum. It may work better for your team. While Scrum drives productivity by limiting the work time available in a sprint, Kanban drives productivity and velocity by limiting the number of active, concurrent issues. Time estimation is no longer part of the ...


64

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


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


51

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


33

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


32

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


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


25

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.


20

They're not actually user stories. They're stakeholder stories. Unless the software is actually paid for direct by users, it's rare that a story is created entirely for their benefit. I give you a couple of examples: keyworded articles, which allow advertisers to have more effective adverts CAPTCHAs, which are there to stop moderators having to deal with ...


20

When you have the privilege of starting on a new project you have a blank canvas--which is both exciting and daunting at the same time. I work in iterations, and this is how I divide up the work: Start with the goals for the project. Goals are necessarily the most vague, but helps you focus on what the client or user intends to do with the software. At ...


20

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

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


19

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


17

Good estimates take some time. If somebody wants an estimate now, let them know you'll get back to them. It's better to give them a better estimate later and make them squirm a bit now, than give them what they want, and fail to deliver because you failed at estimating. Break the task down into smaller tasks. Large tasks cannot be estimated effectively. If ...


17

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


17

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


16

Right at the very beginning! You want the community to feel that they have a genuine stake in your project, otherwise they will feel like they are being used as free labour. All communication should be over a public mailing list or forum, again this enhances the idea of the community. You can mitigate the 'design by committee' problem by laying out a ...


16

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


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


15

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


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

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


14

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



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