Good stuff in here, but be cautioned that the author doesn’t mention their customers are engineers until a bit later in. Which gives a lot more leeway in allowing engineers to make a majority of decisions. In a more complex domain, like maybe selling private securities, collaboration isn’t slow, it helps us not get fined millions of dollars by the SEC. Personally, I also love minimalist process and likewise believe “…
I'm in a large corp as bridge between development and the business. What i do is minimize process on the dev side, and maximize it on the org side. On the dev side my only ask is predictability, which is hard enough already, but is so important for communication. On the org side, i overengineered process. It focusses on value, and helps to keep chaos away from the developers.
Principles for product velocity
41–50 of 138 posts
Re: Principles for product velocity
#42Re: Principles for product velocity
#43I understand the outcry over the heavy processes, but I think there are a lot of confusing statements here. The point being made is "methodology is bullshit," yet what is proposed is exactly that: a new methodology. "Fix a 60-day timeframe and do whatever fits" is a method. The truth is, everyone needs to be organized somehow, and this is why we invent methodologies, frameworks, processes - call it whatever you want…
Agile and Scrum was great when it was introduced bottom-up and then accepted top-down. "We're all adults here, we don't need these rules" was a wide spread sentiment, yet work was horribly inefficient. I remember projects where we would discover every 3 weeks, during a Jour Fixe, that the pieces we built did not fit together. The Daily was fantastic because it was lightweight and short, but very frequent, so that com…
> The Daily was fantastic because it was lightweight and short, but very frequent, so that communication flowed freely.
You should qualify your statements with "for me" and "for our project" because dailies have not been a net positive over my 23 years long career. Yes, not even once. I can't remember a single time I enjoyed them, nor a single time they ever helped me with anything at all related to work.
I am not introverted, nor autistic (though I very likely have ADHD). I am quite outgoing in fact, yet I will hate the dailies until my grave.
The only thing they achieved was put some juniors back on track because when they get blocked they also close up and don't talk to anyone (for whatever reasons that I'll never understand apparently), and give excuse to introverted people to open up a little and have some casual chat. I am not against the latter but I dislike work meetings being hijacked and turned into half therapy sessions.
I've suggested to them to do periodic screen-share pair-developing sessions, they did it, they absolutely loved it and kept doing it even after I left, and us who didn't want to do casual chats in supposed work meetings enjoyed the work meetings slightly more. Everybody won.
> The Retro was the catch-all meeting to bring up stuff (People forgot just how big the obstacles were back then - I remember having to wait 12 weeks for a config change that allowed my app to connect to the database).
And again, please add "for me" and "for our project". Retrospectives have been used in my career, without failure, without a single exception, to slap developers into rushing even more. That's what all managers I was ever under viewed them as: an opportunity to "correct velocity".
Masters whipping up the slaves because they don't pick cotton quick enough. Try and sugarcoat it as much as you like -- it's that and it was always that, and the people in power will always try to swing everything in that direction. It's who they are. It's what they are.
> Recognising that one person who always tried to bring everyone together, calling them a Scrum Master and making room for them to do these tasks was a no-brainer.
Really cute, until you had my life and career and saw the "scrum masters" being one of the managers cousins who saw an opportunity to give them income while pretending they are useful.
In my defense, I never witnessed a managerial system that helped me, so bear with me here.
> "We're all adults here, we don't need these rules" was a wide spread sentiment, yet work was horribly inefficient.
And for the third time: maybe in your teams. I worked in no less than 6 teams that did this very, very well. To the point of us not needing a manager because I and one other guy (we were 7 in total) basically said "OK, things A / B / C are more or less done but we still need X and Y; me and Joel are busy with infra stuff, anybody wants to pick those up?" and somebody always stepped up.
Is that what a scrum master is supposed to be doing? I've never seen it though. But we managed to distribute load and responsibility between ourselves pretty well.
Predictably, that team was eventually disbanded because we had actual power during the executive meetings (me and the other guy attended them). Nobody likes programmers who can push back in an informed manner that ruins the CEO's prepared graphs and slides. Who wants their beautiful illusions shattered by facts? Not these "adults" for sure.
And yes all of us left shortly after. And yes 3 out of the 7 of us were called back some months later to fix the messes of the others. We beat the code back into shape in less than a month, charged them triple and laughed our way to the bank.
---
Bigger point is: we all know the beautiful theory. But there are people out there who don't like it and want to skew the practices to what serves their interests, not yours and not mine.
Glad that you had such a positive experience. Really. But you should be more objective and remind yourself that you are very likely privileged. Most of us are not.
Re: Principles for product velocity
#44I understand the outcry over the heavy processes, but I think there are a lot of confusing statements here. The point being made is "methodology is bullshit," yet what is proposed is exactly that: a new methodology. "Fix a 60-day timeframe and do whatever fits" is a method. The truth is, everyone needs to be organized somehow, and this is why we invent methodologies, frameworks, processes - call it whatever you want…
Make management consulting illegal.
All developers know all the wisdom. Everyone who had a manager knows the problems in any process.
The only ones who seem to not know or see or understand the problems are various layers of management. This is weird because ostensibly that is their one job.
I can understand how a junior manager who only worked one year in the industry can get fooled into believing in the rigid processes with pointless artifacts.
But if you worked building software for five or even two or three years, I cannot possibly imagine how one goes about their day managing a software project in this fantasy land.
By “manager” I mean all the chickens that decide how the pigs work, and all the chicken in pigs clothing. I do not mean all kinds of management.
Re: Principles for product velocity
#45I love The Rise of Worse is better, and this sounds just like that: https://www.dreamsongs.com/RiseOfWorseIsBetter.html It doesn't explain _why_ simple implementation is more important than having a simple interface, but it just makes an observation that simple implementation usually wins. In my experiments simple implementation won for velocity, because quite often I need to change small parts in all the implementat…
This really hinges on 'velocity': > .. simple implementation won for velocity .. How do you specifically define velocity in this context? (I am asking because I tend to favor speedy velocity in quick iterations; which is another story, than say velocity for change...) Kind regards
Re: Principles for product velocity
#46Re: Principles for product velocity
#47I understand the outcry over the heavy processes, but I think there are a lot of confusing statements here. The point being made is "methodology is bullshit," yet what is proposed is exactly that: a new methodology. "Fix a 60-day timeframe and do whatever fits" is a method. The truth is, everyone needs to be organized somehow, and this is why we invent methodologies, frameworks, processes - call it whatever you want…
https://zwischenzugs.com/2017/10/15/my-20-year-experience-of...
Re: Principles for product velocity
#48I love The Rise of Worse is better, and this sounds just like that: https://www.dreamsongs.com/RiseOfWorseIsBetter.html It doesn't explain _why_ simple implementation is more important than having a simple interface, but it just makes an observation that simple implementation usually wins. In my experiments simple implementation won for velocity, because quite often I need to change small parts in all the implementat…
> A wrong lesson is to take the parable literally and to conclude that C is the right vehicle for AI software. The 50%
Now we use Python to glue C code to train the best AIs of this time.
Re: Principles for product velocity
#49> What’s the moral of the story? Beware of Methodologies. They are a great way to bring everyone up to a dismal, but passable, level of performance, but at the same time, they are aggravating to more talented people who chafe at the restrictions that are placed on them. It’s pretty obvious to me that a talented chef is not going to be happy making burgers at McDonald’s, precisely because of McDonald’s rules. So why do IT consultants brag so much about their methodologies? (Beats me.)
https://www.joelonsoftware.com/2001/01/18/big-macs-vs-the-na...*
Re: Principles for product velocity
#50Earlier quoted context omitted.
Agile and Scrum was great when it was introduced bottom-up and then accepted top-down. "We're all adults here, we don't need these rules" was a wide spread sentiment, yet work was horribly inefficient. I remember projects where we would discover every 3 weeks, during a Jour Fixe, that the pieces we built did not fit together. The Daily was fantastic because it was lightweight and short, but very frequent, so that com…
Sorry for a bit of a blunt comment following -- but your rose-tinted view of even the original Agile / Scrum ticked me off. I have to push back here, severely so. > The Daily was fantastic because it was lightweight and short, but very frequent, so that communication flowed freely. You should qualify your statements with "for me" and "for our project" because dailies have not been a net positive over my 23 years long…