Waterfall was coined by a paper discussing why waterfall wasn't a good way to do software projects.
You aren't wrong, either. I found Scrum to be a series of waterfalls that weren't well thought out. "Iterative Design" essentially meant, "We aren't sure what the button should do exactly, but we know we need it there and it kinda has to do this and we'll figure the rest out for the next iteration."
That caused so many problems with tech debt.
Stories began to take longer due to the increasingly large and discombobulated code base, but the expectation was that we continue to deliver the same number of story points each sprint.
Then we got blasted for losing pace. "Why are you under-performing? We are just adding little features. You've already implemented this button on another form before? Why does it take longer the second time? You already know how to do it!"
It became absurd and no one could hear or understand what was happening was easily predictable and in fact -- was predicted by several members of the team many months prior.
When the project management was informed of these predictions now having come true, the development team was accused of intentionally causing the delays.
> "How could it possibly take that long? How do you not know how long it will take?"
Well, if they really said that, you can just dismiss the comment as incompetent. A witty retort may be in order if a non-technical manager is in earshot, e.g.:
"How long would it take for you to earn a green belt in karate?"
"Hmm, what does a green belt entail?"
"Exactly, you don't even know what you don't know, yet."
"We don't know because we've never done this before, and we can only compare to the most similar work we've done, and any existing data."
Before I could say more, they I interrupted: "You have to know, it's your job, or you don't know what your doing," or something along those lines. It was the most heated I've felt. I know what I'd reply with today, but I was younger and more naive then.
In these situations I shift the conversation to what is the PM really after. I explain that I can tell them any estimate they want (or they can make it up on their own - no need to even discuss), but does that really do them any good when it is missed? There is usually some pushback at first, but when items are delivered within estimate a few times in a row they realize it's better to take whatever hit up front than it is to miss and adjust.
Also, someone asking how could something take so long is not a belittling question. I don't see any problem with either question.
Personally I believe this is one of the major gaps in Scrum, and there is no prescripted way to solve this problem. XP's focus on technical aspects is much better in this regard, but the possibility of runaway technical debt still exists.
There are so many places where this can sneak in and become an issue, too:
- The development team can groupthink, underestimate and/or fail to account for technical debt payback in planning poker. They may estimate the cost for the new feature, but not include any time for refactoring to keep the codebase healthy
- The Scrum Master may not shield the development team from pressure to deliver coming from the product owner, which may cause the team to cut the above corners
- Codebase health may be split out from vertical stories into its own tasks that get deprioritised by the product owner
- Even if the development team identifies the need for codebase health, this may not be communicated back to the product owner in a way that makes business sense ("but we can still get this feature out the door quickly and fix the mess later, right?" - yes, once or twice, but the downside is a slowing of velocity)
- Even if the team started well with ground rules the Scrum Master is supposed to enforce surrounding technical quality, the Scrum Master may not be effective in enforcing the process - either because they lack authority or because they lack the ability or knowledge to do so
Among several others.
In your situation, the big red flag is that the team predicted the issue many months prior. The process has failed to extract that information from the team members and deliver a consensus between them and the product owner.
Though ultimately, as with any project, if the product owner has more organisational authority than the development team and chooses to exert this authority, no process will be able to save you.
The tricky bit is having a solution and implementing it.
Having something well thought out is hard work. Is hard work rewarded? Is initiative to even try rewarded? I'd say the answer is no.
The answer becomes yes in small teams that are given time, freedom and resources, or in times of crisis (same thing as small team really, minus the time bit), as far as I can tell. Otherwise, most people's natural tendency (including me) is to phone it in. We'd be wise to let people in software development and many other professions that are not manual labor, to switch careers after 30-35 if they haven't done anything worthwhile by then.
Working with people who have to phone it in for the next 30 years and know it is modern day hell for anyone with an iota of ability.
It's permanent compromise and insincerity, or being an outcast that's temporarily tolerated for doing 5-10x the work of the person next to you.
Because Tech debt and I reading messy code base never happened in waterfall...
The problem is always : features and customer request over bug fixing or design fixes.
The system, project type does not matter. That's why some PO recommend 10 percent allocation to devops / ops, 10 percent to improving code base . And "no bug survives the Sprint" philosophy. And what is left,is you next feature or customer request.
For every example of scrum operating badly there are examples of scrum working well. The common denominator in all of those situations - good and bad - is the project and middle/upper management.
In business process analysis, when a process is dependent on individual people, you don't have a mature process but an ad hoc process.
In other words, Scrum methodology in itself is not mature as a methodology and depends on individual fiat, just like any project that doesn't have any process at all.
The only tangible benefit to Scrum might be paying lip service to development departments while firmly retaining the status quo.
Scrum is no more or less dependant on individual people as any other methodology.
The rest of your post is just warping your initial conjecture to arrive at conclusions you'd already decided upon. I neither agree with those conclusions nor the chain of twisted logic you used to arrive that.
I'm not going to stand on a soapbox and sing for the glory of scrums. People - like yourself it seems - can get very tribal when talking about such things. Which is as weird to read as it is pointless for you to argue. In my experience leading different teams using different methodologies, the thing that really makes the big noticeable impact is people and not methodologies. If you work in a blame culture or have colleagues in your team who don't follow process - then whatever process you put in place will be undermined at every opportunity regardless of it's methodology. However if you work in an environment where people respect one another and want to collaborate in getting work done, then you pick a methodology that works best for the day to day work (eg project work or support operations) and for the way people like their work organised. All the rest of the arguments are superfluous.
> good and bad - is the project and middle/upper management.
Yep. People do not realize that the whole company has to adopt agile/scrum for it to work. It's a shift that many companies can not or will not make. They are tied to fixed deadline, fixed scope for various reasons.
I mostly agree with you but I wouldn’t go so far as to say the whole company has to adopt it. However you do certainly need the support from the wider company. I’ve seen scrum work really well despite waterfall being the predominant methodology in that business - there people were happy to embrace the preferred working styles of whichever team they had to liaise with. I’ve also worked in places where scrum failed badly despite the CEO pushing for it. Those places usually suffered from a blame culture that was also the CEOs doing and that blame culture meant that everyone was spending their time working against the best interest of any of the other teams. By “teams” I mean project managers, sales guys, support or operations teams (if they differ from your developers and/or DevOps), finance staff, directors/upper management and even your own paying clients (if you’re a hired service) etc.
I’ve noticed comments for and against scrum are often so focused on the technical aspects of the methodology that they overlook the human aspect. Which matters more in my opinion.
You aren't wrong, either. I found Scrum to be a series of waterfalls that weren't well thought out. "Iterative Design" essentially meant, "We aren't sure what the button should do exactly, but we know we need it there and it kinda has to do this and we'll figure the rest out for the next iteration."
That caused so many problems with tech debt.
Stories began to take longer due to the increasingly large and discombobulated code base, but the expectation was that we continue to deliver the same number of story points each sprint.
Then we got blasted for losing pace. "Why are you under-performing? We are just adding little features. You've already implemented this button on another form before? Why does it take longer the second time? You already know how to do it!"
It became absurd and no one could hear or understand what was happening was easily predictable and in fact -- was predicted by several members of the team many months prior.
When the project management was informed of these predictions now having come true, the development team was accused of intentionally causing the delays.