Really liked Jon talking about the importance of experience in development. I just wanted to add that it’s also important to consider experience on the system. Even the most talented developers will need time to find their feet if they’ve only worked with a system for a few months.
So don’t treat developers as replaceable resources! If you fire an experienced team because you found some cheaper bums on seats elsewhere, you’ll usually pay the price!
The problem is that all too often do customers think they know what they want but actually have NFC what they need.
Unless there is a constructive dialogue between the people who build it and the people that want it, it will end disastrously. Just think of all the failed white elephant projects that get “negotiated” on the golf course.
Until there’s an acceptance that being agile isn’t just something developers do but has to be adopted by the whole org, it’s not going to work. I know it sounds a bit dreamy but I’ve worked in big orgs that did agile rather well, so it is possible…
I used to work in banks where you had teams of architects create high level design (HLD) docs that get turned over to the design team to produce low level designs (LLD) that the get turned over to developers how are meant to write the code, then to be turned over to the testing team. With massive handover meetings at every stage and forests of paper for milestone documentation that had to be signed off.
Never had my soul be destroyed as completely and I seen such a massive waste of time and money.
Sounds to me that the artificial crunch is the problem. And if you have the capability to deploy quickly, I don’t see any value in sprints they tend to artificially delay deployments, reviews or retrospectives. If something needs talking about, don’t wait for a ceremony in a week and a half when everyone has forgotten about it.
I’ve been part of teams working this way without sprints and artificial crunch on mature and large scale services, so it really isn’t a MVP/startup only deal…
I’m not a fan of ceremonies/rituals and always have to laugh when looking up the dictionary definition of ceremony/ritual which implies something that gets because “we’ve always done it” but is actually pointless. Pretty much on the nose. If something is useless, then change it!
The worst thing about Agile is the commercialisation that came with agile training coaches and certifications. It always boggles my mind when realising how many people think “agile” means sprints, backlog grooming, Fibonacci sizing or planning poker and not what’s in the manifesto.
When you take it back to its roots and cut out all the Scrum or SAFe nonsense and adapt it to your team it can really work.
Note, I’m not saying estimates are bad per se and can imagine teams for whom it does work, but it would have to be something that the team is happy with not an impose-from-above methodology…
I think the main thing about agile is a plan-do-study-act cycle than can be adapted to anything even project management. The trick is not to think I can just adopt a process and will then be agile. It always has to be adapted to context and what works for you.
As to CI/CD pipelines: I think a centralised devops team that blocks everyone is as much an anti pattern as a wild-west approach where 3 teams operate 4 different CI/CD tech stacks. There is much to be said about building a platform (when the size of the operation is big enough to warrant it) and using golden paths or paved roads.