Timeline for How can we effectively manage software projects without killing creativity?
Current License: CC BY-SA 3.0
32 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 19, 2017 at 17:23 | comment | added | Dunk | Ultimately, the solution to your problem is simple. "Don't look at how much time is allotted for a task." Contrary to other opinions here, I believe the developers job is to deliver professional quality software. That takes however long it takes, regardless of some predetermined estimate. After you complete the task then look at the time estimate. If you took longer than expected then try to figure out why and if possible don't do that on your next task. If you think it took how long it should have then keep being a professional regardless of estimates. You'll enjoy your job more that way. | |
| Oct 19, 2017 at 17:15 | comment | added | Dunk | @FrankPuffer - I see in another comment that you are concerned about tasks in hours rather than days. I'll build upon Thomas's comment. When I do task estimates there are only 4 choices for time. 1, 3 or 5 days. Anything longer is 10 days. If anything actually is 10 days then that means it needs to be broken down further into subtasks. In reality by the time estimates are done there's only 3 choices for time per task. A development task should never be in "hours". If you know something is a matter of hours then it seems like it should be part of some bigger task. | |
| Oct 18, 2017 at 13:27 | review | Close votes | |||
| Oct 26, 2017 at 3:03 | |||||
| Oct 18, 2017 at 11:44 | answer | added | Lena Weber | timeline score: 1 | |
| Aug 25, 2017 at 3:41 | history | tweeted | twitter.com/StackSoftEng/status/900926200373288960 | ||
| Aug 23, 2017 at 16:32 | vote | accept | Frank Puffer | ||
| Aug 20, 2017 at 18:15 | history | protected | gnat | ||
| Aug 19, 2017 at 10:44 | comment | added | Laiv | Because, when focusing on single small tasks, some ideas for improving the whole thing probably won't even come to my mind Are you sure? they won't or they are going to be ignored immediatly? During the sprints, do you get any feedback regarding this "issue"? Something like -I would have done this in another way but...- I don't think that creativity takes time. It takes the right environment (as Thomas commented) and the right people (creative people. Not all developers are creative). IMHO environment kills creativity. | |
| Aug 19, 2017 at 9:43 | comment | added | Frank Puffer | @ThomasOwens: "Why are you decomposing the work into such small increments?" Actually I don't. The average task size of my projects is around 2 days. But I sometimes get recommendations from both developers and managers to reduce task size. The expectation is that this will make issues obvious more quickly. | |
| Aug 18, 2017 at 17:35 | comment | added | Thomas Owens♦ | Why are you decomposing the work into such small increments? The effort needed to track that is to the point of disruptive. Work should typically be broken down into pieces that are large enough to add value but small enough to do quickly and get feedback on before it's costly to change them. Of course you're going to run into problems if you use crap methods to manage your engineering projects. | |
| Aug 18, 2017 at 17:30 | comment | added | Frank Puffer | @ThomasOwens: I think it depends on the size of the tasks. If I have 5 days to finish a job, this will leave enough room for being creative. If I first split the same job into 20 tasks of about 2 hours each and track the times for each task, it will likely take longer or the quality of the result will be worse. Why? Because, when focusing on single small tasks, some ideas for improving the whole thing probably won't even come to my mind. (I agree that when working in a team, an average task size of 5 days can be a problem.) | |
| Aug 18, 2017 at 12:36 | comment | added | Thomas Owens♦ | "I find it hard to be creative when facing a time limit for a job" -- All engineering requires some level of creativity. However, because engineering includes not only form and function, but also economics, it's always at least partially driven by time and cost. In some environments, "doing engineering" may be driven less by time and cost than others. But as an engineer, it's your job to balance all of those things. You need to either (1) change your environment to one that is more suitable for you or (2) learn to adapt. I believe both are beyond scope for this community to address. | |
| Aug 18, 2017 at 12:29 | answer | added | meriton | timeline score: 2 | |
| Aug 18, 2017 at 11:41 | comment | added | Doc Brown | You might be interested this article about illusionary premises of software estimation. | |
| Aug 18, 2017 at 10:32 | answer | added | Robzor | timeline score: 1 | |
| Aug 18, 2017 at 10:24 | answer | added | John Forkosh | timeline score: 0 | |
| Aug 18, 2017 at 10:08 | comment | added | Ewan | all the more reason to de-emphasise the importance of estimates. | |
| Aug 18, 2017 at 10:04 | answer | added | guillaume31 | timeline score: 0 | |
| Aug 18, 2017 at 10:01 | comment | added | Frank Puffer | @Ewan: It might not matter in theory, but it does increase the likelihood that other team members will consider this developer to be an underperformer. | |
| Aug 18, 2017 at 9:39 | comment | added | Ewan | they shouldnt, the explaination is always "the estimate, was an estimate". but more importantly, it doesnt matter. you just add up the points done per sprint | |
| Aug 18, 2017 at 9:35 | comment | added | Frank Puffer | @Ewan "Task estimates shouldn't be seen as a time limit." No, but don't they imply a time limit, even when working with story points? If one developer works a day on a 1 point story while another one finishes a 2 point story in two hours, most project managers will ask for an explanation. | |
| Aug 18, 2017 at 8:24 | history | edited | Frank Puffer | CC BY-SA 3.0 | added 2 characters in body |
| Aug 18, 2017 at 8:24 | comment | added | Ewan | I mean before scrum and the wide spread adoption of agile methodologies. its not that the tasks were any different, just we didnt track them individually | |
| Aug 18, 2017 at 8:22 | comment | added | Giorgio | @Ewan: "In the old days devs would be 'adding the big feature' for months and no-one would be able to say when it would be finished or how far along they were": What old days are you referring to? Been programming since the middle 90-ties and did not experience this more often than I do now: simple tasks were and are completed early and complex tasks are more difficult to estimate. Or by old days you mean the 70-ies? I do not have any direct experience of that time. | |
| Aug 18, 2017 at 7:41 | history | edited | Frank Puffer | CC BY-SA 3.0 | added 312 characters in body |
| Aug 18, 2017 at 7:11 | answer | added | Euphoric | timeline score: 6 | |
| Aug 18, 2017 at 7:04 | comment | added | Ewan | Task estimates shouldn't be seen as a time limit. They are just a way of being open about what you are working on. In the old days devs would be 'adding the big feature' for months and no-one would be able to say when it would be finished or how far along they were | |
| Aug 18, 2017 at 5:19 | comment | added | Giorgio | @Frank Puffer: "Is this just my personal perception or is it a general problem. If the latter, what can be done about it?": I know many people who feel the same (and I am one of them). To understand why it is like that you can refer to Samuel's answer's first paragraph. If you want to really be creative, consider joining an open source project, or working for some public institution. In the business the focus is on producing the minimal feature with enough quality that can be sold, and then forget about it and move on to the next task. In such a scenario, creativity gets lower priority. | |
| Aug 17, 2017 at 22:48 | comment | added | Frank Hileman | Many developers make the same complaint. It is hard to generalize the problem. It could be the project management is just not very good; it takes estimates literally when the uncertainty is high. On the other hand, your estimates may not be very good. Or perhaps the management doesn't know much about managing developers and they tend to quit. There can be many reasons for this feeling. | |
| Aug 17, 2017 at 21:28 | answer | added | Samuel | timeline score: 2 | |
| Aug 17, 2017 at 21:27 | review | Close votes | |||
| Aug 25, 2017 at 3:04 | |||||
| Aug 17, 2017 at 21:05 | history | asked | Frank Puffer | CC BY-SA 3.0 |