Timeline for The development teams can't deliver successful sprints
Current License: CC BY-SA 3.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 20, 2017 at 18:36 | comment | added | Alan Larimer | Happy to hear of your constant positive experiences, RubberDuck. Your experiences are not necessarily the norm of the curve. All the studies regarding the value of testing haven't convinced many organizations to test early and often; they continue to hold it until the end and cut it short. The responses of "That's just not how we do things here" or "That's not your job/concern" is no stranger to the ears and hearts of many. There's no fear here. I've ended employment (both voluntarily and not) attempting to correct root causes of "big and visible" inefficiencies, and will continue to do so. | |
| Apr 20, 2017 at 1:21 | comment | added | RubberDuck | I'm sorry @AlanLarimerPSM. I just can't see going through life being that afraid to do the right thing. I've found there's little reason to. I've never received anything but praise for raising issues like this. | |
| Apr 20, 2017 at 0:16 | comment | added | Alan Larimer | I'm with Mark C. Wallace on this. There are many organizations out there who do not invest in improvements whether they be technology, training, or other. | |
| Mar 6, 2017 at 22:38 | comment | added | RubberDuck | "Mgmt is aware", but do they know the true cost? Have you calculated it and shown them the hard cold numbers? | |
| Mar 6, 2017 at 14:33 | comment | added | dqm | Also the company is operating in a hub/spoke model, whereas we are the spoke team, and therefore not implementing core functionalities. The core functionalities are largely developed offshore and therefore the software is highly defective with many integration points. That's why we are called to fix either at integration level or on the core level. | |
| Mar 6, 2017 at 14:32 | comment | added | dqm | The senior management is fully aware of these, and these are the issues that "we already know about", and the proposed workaround is to "commit less because we know that things always pop up". We can't just fix the root cause, because it's a huge software and defective in many ways. Therefore, 50% of the times an error comes because of bad development that we need to trace and fix. | |
| Mar 6, 2017 at 12:23 | comment | added | RubberDuck | A more productive response: Make the interrupts as big and visible as possible. Show the powers at be how much more efficient and reliable you could be if the teams were allowed to fix these root causes. Show them the numbers; make your business case. | |
| Mar 6, 2017 at 12:20 | comment | added | RubberDuck | I call BS. It should not be very difficult to make the case for making your development teams more efficient. | |
| Mar 6, 2017 at 12:18 | comment | added | MCW | In most organizations, the Andon Cord is attached to a resignation letter. | |
| Mar 6, 2017 at 11:29 | comment | added | dqm | Thanks for your reply, I'm with you on that. However, I am talking about an organization of 20k employees, whereas environments setup and process setup is out of our control. We are EU based, and these "decisions" are taken on a C or SVP level in headquarters in US. We just adopt what's been decided. Therefore, if no decision is made to increase quality and stability, it won't happen and there's nothing we can do but keep highlighting it. | |
| Mar 6, 2017 at 10:12 | history | answered | RubberDuck | CC BY-SA 3.0 |