Timeline for Increasing productivity on a small team of back-end developers [closed]
Current License: CC BY-SA 3.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 19, 2018 at 22:50 | comment | added | Alan Larimer | There is no use of the Scrum framework based on the information in this question. Scrum Teams are cross-functional. | |
| Nov 27, 2017 at 19:06 | comment | added | HLGEM | Perhaps your business model can;t be profitable due to unrealistic assumptions (hint expecting more than 40 hours per week person is an unrealistic assumption. Expecting that in 40 hours, all time will be productive is an unreasonable assumption. Forgetting to account for sick time, vacation time, jury duty, etc is an unreasonable assumption. Assuming that all tasks can be completed easily in X amount of time is often an unreasonable assumption. | |
| Nov 27, 2017 at 19:05 | comment | added | HLGEM | If you don't go through enough work to make a profit, I think you first need to understand how much work is possible and reasonable in a given amount of time. Are your devs genuinely working at full speed or not. It is hard to say. This is a profession where thinking time is necessary, so not all work time will be people typing at full speed. Perhaps the best solution to the profit problem is to reduce management salaries rather than force an unreasonable workload on employees who will vote with their feet. | |
| Nov 27, 2017 at 1:55 | comment | added | Nemanja Trifunovic | How do you know you have improved productivity? You just introduced Scrum - what were they using before? What metrics are you using to measure productivity after switching to the new methodology? | |
| Nov 27, 2017 at 1:11 | comment | added | Fattie | The overwhelming answer is to change tools. It's very likely you could eliminate all six jobs by just moving to Firebase or Outsystems. The days of people being paid for laboriously building custom backends, is history. Dicking around with things like "agile" (lol) which might bring you a 5 or maybe 6 percent efficiency gain is - insanity. | |
| Nov 27, 2017 at 1:00 | history | closed |
Bernhard Barker gnat Philip Kendall Bluebird Masked Man |
Needs more focus | |
| Nov 26, 2017 at 23:25 | answer | added | Daniel | timeline score: 2 | |
| Nov 26, 2017 at 18:57 | comment | added | teego1967 | If you've truly "doubled productivity in 7 weeks" (4 weeks with a 3 week plateau) and the team is still not considered "profitable"... it makes me think that there's a serious problem with measurement methodology and expectations. A few weeks is rarely enough time to see substantive performance turnarounds in complex activities simply by virtue of project management techniques. Moreover, sprints are typically 1-2 weeks each, so are you just reacting to the team falling short on the last 2-3 sprints? | |
| Nov 26, 2017 at 16:48 | comment | added | Juha Untinen | Does your team spend a lot of time doing "nothing", eg. tasks not defined in the sprint planning, and do you compare the estimated times to actual times during sprint retrospectives? Is there a big difference in them? And how much time is allocated for them team? Eg. if they estimate a ticket to take 6 days, and it took 6 days, are they also assigned tickets to fill up the rest of the sprint with some overhead? Eg. 2 week sprint should result in eg. 8 days of estimated work done. If it is closer to 5-6 with correct estimates, then just assign one or two small tickets. | |
| Nov 26, 2017 at 15:39 | review | Close votes | |||
| Nov 27, 2017 at 1:02 | |||||
| Nov 26, 2017 at 14:56 | comment | added | user932132 | Productivity doubled since I implemented the methodology. This was 7 weeks ago | |
| Nov 26, 2017 at 14:45 | comment | added | Patricia Shanahan | Is the productivity better or worse than before changing methodology? How long is it since the change? | |
| Nov 26, 2017 at 14:07 | history | asked | user932132 | CC BY-SA 3.0 |