4 ms·

The problem that a lot of people get to with Agile/Lean is that the actual practices deviate from the original goals. The powers that be can't actually handle a

by vertis 4y ago

The problem that a lot of people get to with Agile/Lean is that the actual practices deviate from the original goals. The powers that be can't actually handle agile in it's truest chaotic form. So it gets bastardised from the top down (and at times from the bottom up as well). Worse still some of the things that are advertised as 'agile' actually violate the principles. The card wall was supposed to be about as light a representation of ongoing work as you could get and facilitate the interactions with the teams. Unfortunately, tools like Jira change this to be an over-engineered process and tool (which violates point one of the manifesto). Remote work has not made this better. Sprints and pairing become tools to keep devs on a hamster wheel. Always productive, in theory at least. Leaving this to the side, I've seen sprints done well and badly. More often than not teams can't manage to point cards effectively. I've had a couple of teams where things just end up in a middle ground constantly (everything is a 3). The exercise of comparing this card to some previous representative card is too hard (and is itself prone to problems). Retrospectives, can be a useful tool, or they can be a back patting exercise. Showcases without a customer in sight (put your hand up if you're the "customer proxy"). Having said that, some of the behaviours can be really useful. Breaking down overly complex cards as a part of planning helps define the work. There are other opportunities to do this, but backlog grooming / planning sessions are one place. Having the team discuss cards and talk about complexity often reveals unknowns. I've seen a bunch of examples where things will be caught because of a dev/designer/product manager can see something that wouldn't have been identified if someone just started working on it.

P5fRxh5kUvp2th 4y ago
> The powers that be can't actually handle agile in it's truest chaotic form. I would argue the word phrase 'software development' should replace 'agile' in that sentence. I liken it to boiling water. It's messy and chaotic. You'll eventually reach the goal, but until that happens you must be comfortable with a bit of chaos. Attempting to remove the chaos from software dev is like trying to tell mozart not to practice. You'll never get out of it what you think you will.
denton-scratch 4y ago
> Sprints and pairing become tools to keep devs on a hamster wheel. Always productive, in theory at least. SCRUM and sprints lend themselves to "hamster-wheel management". That's an abuse, but it stilll gets labeled agile. Pair programming is amazing. Provided no pair has a total dullard (or worst: two dullards!), pairing with rotation quickly results in every member of the team knowing the whole project, so that any team member can pick up the work of any other team member. It also levels-up the skills of the whole team. Even mediocre devs can become good devs by working side-by-side with someone really good. On a per-task basis, I'm willing to grant that a pair might have lower velocity than two devs working alone. But the benefits of pairing with rotation for raising the standard of the whole team are striking. [I'm not saying that all work should be done as pairs; as in everything you have to use common sense.]
- vertis 4y ago
  I've had some amazing pairing sessions and really really terrible sessions (FWIW I try to be a good pair). I accept everything you say about pairing, it has some really good team impacts. It gets abused though far too often not just as a tool to upskill team members but also as a way to 'keep them honest'. The always on, always teaching/learning is exhausting. The constant social interaction is grueling, and I'm an ambivert (ENTP-A E=51%). I pity the actual introverts. I've discovered, years later, that I much prefer to be alone with my thoughts when programming. Not sure I'll ever go back to an open plan office either.
  - denton-scratch 4y ago
    Yes, I also found pairing exhausting. The hardest, most tiring, most-pointless pairing I participated in was with a diagnosed autistic. He was very clever; but I couldn't understand the code he wrote, and he couldn't explain what he was doing. And a lot of the code he wrote, I gradually discovered, wasn't actually helpful for the task.

by vertis 4y ago

P5fRxh5kUvp2th 4y ago

> The powers that be can't actually handle agile in it's truest chaotic form. I would argue the word phrase 'software development' should replace 'agile' in that sentence. I liken it to boiling water. It's messy and chaotic. You'll eventually reach the goal, but until that happens you must be comfortable with a bit of chaos. Attempting to remove the chaos from software dev is like trying to tell mozart not to practice. You'll never get out of it what you think you will.

denton-scratch 4y ago

> Sprints and pairing become tools to keep devs on a hamster wheel. Always productive, in theory at least. SCRUM and sprints lend themselves to "hamster-wheel management". That's an abuse, but it stilll gets labeled agile. Pair programming is amazing. Provided no pair has a total dullard (or worst: two dullards!), pairing with rotation quickly results in every member of the team knowing the whole project, so that any team member can pick up the work of any other team member. It also levels-up the skills of the whole team. Even mediocre devs can become good devs by working side-by-side with someone really good. On a per-task basis, I'm willing to grant that a pair might have lower velocity than two devs working alone. But the benefits of pairing with rotation for raising the standard of the whole team are striking. [I'm not saying that all work should be done as pairs; as in everything you have to use common sense.]

vertis 4y ago
I've had some amazing pairing sessions and really really terrible sessions (FWIW I try to be a good pair). I accept everything you say about pairing, it has some really good team impacts. It gets abused though far too often not just as a tool to upskill team members but also as a way to 'keep them honest'. The always on, always teaching/learning is exhausting. The constant social interaction is grueling, and I'm an ambivert (ENTP-A E=51%). I pity the actual introverts. I've discovered, years later, that I much prefer to be alone with my thoughts when programming. Not sure I'll ever go back to an open plan office either.
- denton-scratch 4y ago
  Yes, I also found pairing exhausting. The hardest, most tiring, most-pointless pairing I participated in was with a diagnosed autistic. He was very clever; but I couldn't understand the code he wrote, and he couldn't explain what he was doing. And a lot of the code he wrote, I gradually discovered, wasn't actually helpful for the task.