I disagree with the title - the problem isn't with the software teams, the problem is with management prioritizing certain tasks over others - possibly even for good reasons. The function of a company is to make money, not just to make great software. I tend to think the latter leads to the former, but sometimes you have to make bad choices because of financial or other non-technical reasons.
I agree with you, however getting the balance right is key. Many companies make bad decisions over very long time frames, each decision justifiable in its own right leading up to complete failure. For example many of the banks in the UK are facing significant IT failures due to their technical debt (e.g. charging cards twice, customers unable to withdraw funds). These situations happen one tiny step at a time. A good delivery team are responsible for their quality - you can't blame it on someone else.
Microsoft would be a good developer compared by the crap that I have seen being developed and sold as something very expensive because it was that hard to created.
The engineers mention this to the group. The system wasn’t designed to go live, it doesn’t scale easily, it doesn’t have good exception handling, it doesn’t do any logging, it can’t be monitored, the list goes on. The engineers are overruled but promised to be given time to fix it up later.
Typical SCRUM. And afterwards they wonder why the project crashes and burns when fully deployed.
Alternative? Waterfall is worse in my experience, as the massive project creeps toward a big bang role out more and more desperate decisions are made to meet deadlines.
SCRUM creates massive prototype code and never time to clean up. It is a constant race against time exhausting your team. After one year your team is either burned out or left the company.
Sounds like Scrum done wrong - you need to reserve time to payback the debt each sprint - easier said than done I know but I don't think any approach gives you this for free.
I always hear the SCRUM doing wrong excuse, but I have never seen a SCRUM that actually succeeded.
I have seen people claim that SCRUM saved their work, but when you look at what they did, you ask yourself : How can you even remotely call this professional developing? And why on earth did it take 3 times more than without SCRUM?
Yeah, I think you have a point. The vast majority of software development is done in a shoddy way, this includes Scrum and other agile approaches. However if you have a high performing team they will do better using these approaches. This is the big secret that none of the books will never tell you. With a great team you can do any methodology and be successful, with a shit team you'll always fail. However I think with a great team you'll get more done and higher quality using agile approaches verses something like Waterfall or RUP.
I understand the idea of SCRUM. It tries to mimic good developers. But the problem is that it tries too hard and actually kills the good developers and leave the bureaucrat developers in your team that follow the SCRUM rules to the letter.
SCRUM would probably work if you have one guy in that team that does not follow the planning. That guy will clean up the code and fix bugs.
SCRUM would also probably work when there is no fixed demo date set but is more relaxed. e.g. postpone the demo 1 or even 2 weeks later, because you want to make sure that your code has the minimal quality, before proceeding.
SCRUM would also work when you never show the progress graph to your developers; It is always depressing to see that you failed again to reach the target. It really kills moral after 2 or more sprints.
The failures I have seen in most projects is because they do not understand what they must solve. Most developers and managers are fixated on design patterns and rules that they are killing the solution. Yes I know that the program looks like crap but at least look at the cool design patterns we used
15 comments
4 u/RockAndNoWater 14 Jul 2015 21:40
I disagree with the title - the problem isn't with the software teams, the problem is with management prioritizing certain tasks over others - possibly even for good reasons. The function of a company is to make money, not just to make great software. I tend to think the latter leads to the former, but sometimes you have to make bad choices because of financial or other non-technical reasons.
1 u/nsfwalias [OP] 14 Jul 2015 21:44
I agree with you, however getting the balance right is key. Many companies make bad decisions over very long time frames, each decision justifiable in its own right leading up to complete failure. For example many of the banks in the UK are facing significant IT failures due to their technical debt (e.g. charging cards twice, customers unable to withdraw funds). These situations happen one tiny step at a time. A good delivery team are responsible for their quality - you can't blame it on someone else.
1 u/roznak 14 Jul 2015 21:44
Crappy software means crappy company.
1 u/RockAndNoWater 14 Jul 2015 21:49
Microsoft.
1 u/roznak 14 Jul 2015 21:55
Microsoft would be a good developer compared by the crap that I have seen being developed and sold as something very expensive because it was that hard to created.
2 u/roznak 14 Jul 2015 21:42
Typical SCRUM. And afterwards they wonder why the project crashes and burns when fully deployed.
0 u/nsfwalias [OP] 14 Jul 2015 21:45
Alternative? Waterfall is worse in my experience, as the massive project creeps toward a big bang role out more and more desperate decisions are made to meet deadlines.
2 u/roznak 14 Jul 2015 21:51
SCRUM creates massive prototype code and never time to clean up. It is a constant race against time exhausting your team. After one year your team is either burned out or left the company.
0 u/nsfwalias [OP] 14 Jul 2015 21:57
Sounds like Scrum done wrong - you need to reserve time to payback the debt each sprint - easier said than done I know but I don't think any approach gives you this for free.
1 u/roznak 14 Jul 2015 22:00
I always hear the SCRUM doing wrong excuse, but I have never seen a SCRUM that actually succeeded.
I have seen people claim that SCRUM saved their work, but when you look at what they did, you ask yourself : How can you even remotely call this professional developing? And why on earth did it take 3 times more than without SCRUM?
0 u/nsfwalias [OP] 14 Jul 2015 22:03
Yeah, I think you have a point. The vast majority of software development is done in a shoddy way, this includes Scrum and other agile approaches. However if you have a high performing team they will do better using these approaches. This is the big secret that none of the books will never tell you. With a great team you can do any methodology and be successful, with a shit team you'll always fail. However I think with a great team you'll get more done and higher quality using agile approaches verses something like Waterfall or RUP.
1 u/roznak 14 Jul 2015 22:11
I understand the idea of SCRUM. It tries to mimic good developers. But the problem is that it tries too hard and actually kills the good developers and leave the bureaucrat developers in your team that follow the SCRUM rules to the letter.
0 u/nsfwalias [OP] 14 Jul 2015 22:14
I agree
0 u/roznak 14 Jul 2015 22:18
The failures I have seen in most projects is because they do not understand what they must solve. Most developers and managers are fixated on design patterns and rules that they are killing the solution. Yes I know that the program looks like crap but at least look at the cool design patterns we used