I want to make bad, difficult to maintain code, I want to spend more money doing it, and want to extract all of the enjoyment out of programming for those on the project so that innovation is stifled. Would Scrum be a good choice?
Why I'm not a big fan of Scrum
211–220 of 387 posts
Re: Why I'm not a big fan of Scrum
#212The most important agile practice, imho, is far and away the Retrospective. A good retrospective process will fix all other problems.
In the post, you sort of dismiss it out of hand because it is supposed to be a discussion limited to scrum, but that is an arbitrary and self-imposed restriction. You are doing it wrong. Remove that restriction and the doors will open up.
The retrospective is about creating time for the team to review what works and what doesn't about the software development process in general (no need to limit to scrum).
I've seen retrospective discussions veer into company culture, the need for faster hardware, testing processes, etc. Anything related to making the software, the software development process, or the team better should be on the table.
A good retrospective enables the team to use its sprints as experiments to try different things, to evolve the practices to better fit the needs of the team and organization. If stand-ups aren't working, go a sprint without them, or doing them differently -- whatever change would address the weakness identified by the team -- then in the next retrospective reflect on whether it actually improved things. Rinse and repeat. Done properly, a good retrospective will enable your team to evolve and get better and better with every sprint.
Points can be frustratingly fuzzy, but they serve a valuable purpose. They give a measure of team productivity (e.g. velocity), even if imperfect. Yes points can be gamed, but a team should learn quickly that gaming only serves to fool themselves. Because of they can be gamed, I'm not a fan of using points as an externally visible "vanity metric". They should only be used or shared within the team. They should not show up in performance reviews or presentations to management. But points can be very useful as an internal metric for the team to measure whether or not tweaks to the process made a positive impact. You need some way to objectively measure the success or failure of your process experiments.
Of course, any metrics used are themselves certainly deserving of scrutiny and fine-tuning, as poor metrics lead to poor decisions. To me the benefit of points (or t-shirt size estimates) over something like hours is that in software development, hour-precision estimates give a false sense of accuracy. It requires more effort to provide more precise estimates, yet they won't be any more accurate (given the inherent non-repetitive nature of software development). Thus, the use of a coarse-grained measure like points serves to re-enforce the notion that the estimate are inherently imprecise and that we don't want to waste effort on greater precision estimates.
All that said, whether or not to use points or any measure of team productivity at all is a team decision. If the measure isn't serving the goal of improving the software and the software dev process, then change it or get rid of it. That's the beauty of the retrospective -- it explicitly encourages this sort of process-hacking and fine-tuning.
Embrace the Retrospective!
Re: Why I'm not a big fan of Scrum
#213Just read the summary which I highly agree with and will quote here:
> So, in summary, Scrum
* wastes too much of the developers' time for management
* does not lead to good quality code
* is a control freak which does not leave room for new ideas and innovation.
Re: Why I'm not a big fan of Scrum
#214Earlier quoted context omitted.
It sounds as though you objecting to being required to give any estimate at all.
I don't know how you manage to read this. He seems to say he would like to be in a situation where he has the means to give good estimate but scrum forbids it and forces to give random and biased estimations.
can we infer that he would like to give his estimates:
* while he is actually writing the code (so not up front)
* not in a group setting but as an individual, so either one person estimating the whole thing or each person giving different estimates
* (third point same as first, dont want to estimate up front)
* must incorporate what is often called 'contingency' (which is actually what the whole point of measuring velocity is for!)
* and the final point - he doesn't want to have to commit to it
how can you _not_ read this into it?
Re: Why I'm not a big fan of Scrum
#215>> The daily standup deserves a blog post of its own. This religious ritual has become a staple of every team in the world. Ten minutes of staring into the void, talking about what you did while no one else listens, because they were in the middle of something five minutes ago and will go back to it in another five minutes, and waiting for everyone else to finish.
I've had this happen my times while I was leading the project - it bugs me. I've ended up reducing daily standups and replacing with walking around (physically and virtually) and chatting with people and getting similar results. Of course, "similar results" here is that I heard what someone had to say but nobody else did - so a key to this walking around approach is to tell each person what other people are doing in order to connect the dots.
On the surface this might seem terribly inefficient, but there are a lot of positives, biggest of which is building good relationships with team members and learning about all the other little things going on in life.
On the down side, for people who are only part time on my team (not uncommon in my bigco setting) there is extra scheduling effort and discipline required to make these chats happen frequently.
Re: Why I'm not a big fan of Scrum
#216John Cleese (Monty Python) in "Meetings, Bloody Meetings"
https://www.youtube.com/watch?v=ZWYnVt-umSA
You need to rent this video and show it to the team. (and rent "More Bloody Meetings").
Scrum is a management technique, not related to programming. In fact, it is a "micro-management" technique. However, those who lead don't seem to know how to conduct meetings. I don't see scrum training that even hints at the fundamentals of management, even the fundamentals of meetings.
Re: Why I'm not a big fan of Scrum
#217The aha moment for my team which changed us from a mindset of dealing with scrum to enjoying it was when we moved from aiming towards a number of story points to complete towards committing to the stories that we could individually complete in a sprint, without a concern for the associated story points. All of a sudden story points disassociated with time. They just became a number. a combination of complexity and un…
Is each developer just working on as many stories as he can in a sprint, picking from a prioritized list? Because otherwise, how do you estimate what you can complete in a sprint? Don't you commit beforehand to deliver a certain amount of stories? And doesn't that translate to a certain number of story points?
We get the prioritized list, we review our other commitments in the upcoming Sprint, and starting from the top of the list we go down and developers pick which ones that they will work on. Since we've groomed these stories, we have an idea of complexity and one or more developer may have already taken the time to identify exactly what needs to be done.
We don't commit before hand to deliver a specific number of stories, or a specific number of story points. That would never work. Rather we focus on what individuals believe they can achieve. Our velocity has become pretty consistent and our delivery of story points is close to 100%
Re: Why I'm not a big fan of Scrum
#218Earlier quoted context omitted.
Modularize by functionality, not by layer. Start with a simple end-to-end path and grow outwards, rather than trying to go top-down or bottom-up, and don't split into distinct layers until you're actually deriving value from doing so. Writing code when you don't have the use case yet is always a bad idea.
Yep. And then at the third sprint into this path you realize that the way the backend has been built during the first two sprints makes it impossible to deliver some essential or just very desirable feature that nobody took in consideration because it was outside the scope of the first two sprints. Seen it happen multiple times.
That's the opposite of my experience. It's always the extra layer that was added for some planned feature that we never actually implemented in the end that gets in the way.
Re: Why I'm not a big fan of Scrum
#219Earlier quoted context omitted.
You misunderstand. If more than a small minority of your code cares what OS it's running on (beyond obvious excepted), you have a large amount of technical debt. Cleaning that up, either by refactoring or replacing the offending code, is in the business's best interest because it keeps costs down and keeps more options available to the business. The 'business people' are not qualified by themselves to say that the co…
> Cleaning that up, either by refactoring or replacing the offending code, is in the business's best interest because it keeps costs down and keeps more options available to the business. IME that's very rarely the highest-value thing you can be doing for the business. It's not worth paying for flexibility that you're never going to use, and it's not like it's going to take longer to refactor later than it would to d…
> it's not like it's going to take longer to refactor later than it would to do it now.
It is so, when you have to build on top of something you will have to refactor later. I think the miscomunnication here is happening because the person you are replying to is assuming that case, and you are assuming the case where the code to be refactored is isolated form the rest of the system.
Re: Why I'm not a big fan of Scrum
#220Earlier quoted context omitted.
One amendment I always wanted to make was to have a "technical debt dial". You could stick it on the wall next to the scrum board. The debt dial should be from 0% (spend all the time refactoring) to 100% (spend zero time refactoring, get it out at all costs). Management should have complete control over the dial. Developers should have control over what kind of refactoring they do (ideally the retro should have a que…
I often have the impression that the term "technical debt" is just an euphemism to avoid admitting that someone in the team has produced poorly thought and poorly written code. I'm not sure I ever found myself in the position of writing bad code just for the sake of speed - I surely wrote tons of bad code because I didn't know how to do it better, or because I didn't have the requirements clear from the start, or bec…
>I often have the impression that the term "technical debt" is just an euphemism to avoid admitting that someone in the team has produced poorly thought and poorly written code.
It's absolutely not that. Technical debt is a natural by-product of working even with the best coders. There's nobody out there who doesn't create it.
Better coders just produce it more slowly and clean it up more often.
>I'm not sure I ever found myself in the position of writing bad code just for the sake of speed
I could literally spend all of my time making code nicer and none at all developing features/fixing bugs. It's always a trade off between speed and quality.