111–120 of 214 posts
I think leading in "wartime" is way easier than leading in peacetime. When you are in full panic mode with a clear goal, a lot of decisions are very clear and easy to make. And everybody knows you can't scrutinize every little thing. You take a risk and see if it works out. In peacetime you have more time, goals are not that clear. So a lot of people suddenly have different opinions and they must somehow be negotiate…
Building businesses out of debt, starting with negative balance and when approaching out of money, asking employees for a last minute war time mode. That’s plain terrible business practice, don’t work there.
It all feels like theatre. Been working in many companies in “war mode” and they all think that in order to become profitable (none of them were) you need to push the most “important” features out of the door asap, otherwise your competitors will eat you alive. It’s a lie. Executives and VPs and all those folks that earn 5x what a normal engineer earns, don’t really care about the company they work for. All they care…
I really don't understand the hate for Agile. Adaptation, empiricism, iteration self-managed teams etc...what's not to like? I'm currently involved with two programs run by project managers who probably haven't written code for 30 years (if ever), and it's a nightmare.
Earlier quoted context omitted.
I don't think people are really unhappy with the manifesto, but with applied Agile as it is experienced out in the world where you're having your workday ordered by high powered productivity consultants and LinkedIn-brained middle managers.
so, things that are in no way agile but want to call themselves agile
Earlier quoted context omitted.
I really don't understand the hate for Agile, so let's make it concrete: which things to you not like about the Agile manifesto? 1. Value individuals and interactions over processes and tools 2. Value working software over comprehensive documentation 3. Value customer collaboration over contract negotiation 4. Value responding to change over following a plan And then there are the 12 principles: 1. Customer satisfact…
Can you provide me an actual way to practice these things? Like, specific, exacting ways to execute each of these? Or any of these? Because they don't make any sense. "Value individuals and interactions over processes and tools". So, rather than put an update in a Jira ticket, DM it to a single person in Slack? "Value working software over comprehensive documentation". So, never write documentation? And how do you de…
For example your
>> Value responding to change over following a plan
> ?????????? Does anyone know what the fuck this means?
In waterfall, once you start developing, it's very hard to change something during the process. Due to Agiles iterative and incremental approach (principles 1 & 3), it allows you to change priorities, features, integrations, etc, during development.
New technology also allowed this iterative approach. For example in the past, software was released on disk or CD-roms, which meant a huge release cycle. Nowadays with SaaS, you can constantly release and improve your products (using CI or CD for example, widely adopted now).
Maybe you have to look into other software development processes to really understand what sets Agile appart, for example Waterfall, Spiral, Incremental, Rational Unified Process, etc. A good overview is here: https://en.wikipedia.org/wiki/Software_development_process
Earlier quoted context omitted.
I don't think people are really unhappy with the manifesto, but with applied Agile as it is experienced out in the world where you're having your workday ordered by high powered productivity consultants and LinkedIn-brained middle managers.
so, things that are in no way agile but want to call themselves agile
Manifesto is the one with a small a.
Big A Agile is an exercise in making management happy because they read about it on LinkedIn while having a poo. It usually involves paying several consultants a lot of money.
This entire blog post assumes agency that you, the EM or Team lead, rarely have in an organisation that is on a "wartime" footing. It's cosplay. Real wartime footing: 1. Direction and technical decisions are driven by priorities of board-level members and often arrive in email form late on Friday evening. The entire organisation is expected to pivot immediately. A new senior leadership team member starts scheduling d…
Earlier quoted context omitted.
Can you provide me an actual way to practice these things? Like, specific, exacting ways to execute each of these? Or any of these? Because they don't make any sense. "Value individuals and interactions over processes and tools". So, rather than put an update in a Jira ticket, DM it to a single person in Slack? "Value working software over comprehensive documentation". So, never write documentation? And how do you de…
Agile was a reaction to waterfall and other heavy-process software development practices. You have to understand the bigger picture to fit the Agile points in there. For example your >> Value responding to change over following a plan > ?????????? Does anyone know what the fuck this means? In waterfall, once you start developing, it's very hard to change something during the process. Due to Agiles iterative and incre…
This entire blog post assumes agency that you, the EM or Team lead, rarely have in an organisation that is on a "wartime" footing. It's cosplay. Real wartime footing: 1. Direction and technical decisions are driven by priorities of board-level members and often arrive in email form late on Friday evening. The entire organisation is expected to pivot immediately. A new senior leadership team member starts scheduling d…
Are you sitting behind me ?
Earlier quoted context omitted.
Agile was a reaction to waterfall and other heavy-process software development practices. You have to understand the bigger picture to fit the Agile points in there. For example your >> Value responding to change over following a plan > ?????????? Does anyone know what the fuck this means? In waterfall, once you start developing, it's very hard to change something during the process. Due to Agiles iterative and incre…
That really doesn't answer GP's question