3 ms·

Whenever we hire a new Agile practitioner, as part of the interview I ask them to discuss the Agile Manifesto [1]. And then we run through some basic program de

by bane 9y ago

Whenever we hire a new Agile practitioner, as part of the interview I ask them to discuss the Agile Manifesto [1]. And then we run through some basic program design and I ask them what tools they bring to help support various program needs. They usually bring out various ceremonies and processes and what not. I then ask them to justify what they've offered against the Manifesto. If they're thoughtful about it (the Manifesto isn't always correct, and if you read it carefully leaves open the need for some of this stuff). If they simply insist it's correct they're cargo culting and we can move on. What I've found is that the ceremonies are appropriately named in that many of the practitioners seem to not know what they're for or why they're done. The teams that seem to really excel are the ones that seem to have thoughtful managers that shape the practices of their dev group to the specifics of their work. The ones that seem to always be bogged down and require huge numbers of staff to get even small amounts of work done seem to be the ones that follow a checklist of getting as many of the agile practice "things" jammed into their work processes as possible. I don't think Agile is dead, but I think it requires smarter team leads who look at what's come out of it as a set of tools to be employed against specific development challenges rather than a religion that needs worshiping. 1 - http://agilemanifesto.org/ http://agilemanifesto.org/

borplk 9y ago
I've noticed the same thing. I think it comes from a lack of experience which further creates fear and lack of self-confidence to challenge the practices of the cult. It's also similar to the "nobody got fired for buying IBM" issue. It's "nobody got fired for sticking to the established cult ceremonies". They are people who are afraid and don't care about the team or the company. They are only concerned about their own job security and paycheck. So they never risk trying something that is not in the book. The only way to get them to do something else is to make that thing the "new best practice". Give it a tacky name. Send them to some conferences and get them a "Senior Lingo Bingo Dingo master practitioner" certificate for the new cult ceremony and they will do it with their eyes closed. Or maybe ... just fire them.
auxbuss 9y ago
The issue I’ve always had with Agile – with a capital A – is that the manifesto itself is not agile; it’s been cast in stone – or, at least, embedded in a static web page. (That’s why I’ve never “signed” the manifesto.) I’ve been in this game for enough decades to know that you have to reinvent yourself every five years or so. Some things remain the same over time, of course, but a great deal changes. These changes must at some point affect the assertions laid down in the Agile Manifesto. Where is the mechanism for change? I must at this point point out that I consider myself agile. I absolutely have skin in the game. Now, to the language of managers. I work at CTO/Head of Tech level. That involves a bunch of strategic, operational, and financial stuff that doesn’t pertain to tech matters (tangentially sometimes), but my role at the tech level I regard as supportive not <air quotes> managerial. I usually describe my role as “looking after” not managing – I actively remove the terms manager and management from that part of my role. I expect – nay demand – that the teams responsible for delivery drive development/maintenance. My role is to provide them with what they need – to support, to look after, and so on – individuals and interactions. For me, that’s agile. That’s a dynamic process that’s enabled by tooling and that tooling changes rapidly. No set of pronouncements or practices can remain relevant in such a dynamic environment; unquestioningly following a static text is dangerously close to religious practice – I don’t regard this as a good thing, ymmv. So, while I believe that the Agile Manifesto is an excellent baseline, it is flawed and somewhat contradictory in operation. But, like democracy, it’s the best we’ve got.
arbie 9y ago
Your comment makes me think your workflow has become dogma. Does expecting new hires to hew so closely to existing principles give your team room to evolve?

by bane 9y ago

borplk 9y ago

I've noticed the same thing. I think it comes from a lack of experience which further creates fear and lack of self-confidence to challenge the practices of the cult. It's also similar to the "nobody got fired for buying IBM" issue. It's "nobody got fired for sticking to the established cult ceremonies". They are people who are afraid and don't care about the team or the company. They are only concerned about their own job security and paycheck. So they never risk trying something that is not in the book. The only way to get them to do something else is to make that thing the "new best practice". Give it a tacky name. Send them to some conferences and get them a "Senior Lingo Bingo Dingo master practitioner" certificate for the new cult ceremony and they will do it with their eyes closed. Or maybe ... just fire them.

auxbuss 9y ago

The issue I’ve always had with Agile – with a capital A – is that the manifesto itself is not agile; it’s been cast in stone – or, at least, embedded in a static web page. (That’s why I’ve never “signed” the manifesto.) I’ve been in this game for enough decades to know that you have to reinvent yourself every five years or so. Some things remain the same over time, of course, but a great deal changes. These changes must at some point affect the assertions laid down in the Agile Manifesto. Where is the mechanism for change? I must at this point point out that I consider myself agile. I absolutely have skin in the game. Now, to the language of managers. I work at CTO/Head of Tech level. That involves a bunch of strategic, operational, and financial stuff that doesn’t pertain to tech matters (tangentially sometimes), but my role at the tech level I regard as supportive not <air quotes> managerial. I usually describe my role as “looking after” not managing – I actively remove the terms manager and management from that part of my role. I expect – nay demand – that the teams responsible for delivery drive development/maintenance. My role is to provide them with what they need – to support, to look after, and so on – individuals and interactions. For me, that’s agile. That’s a dynamic process that’s enabled by tooling and that tooling changes rapidly. No set of pronouncements or practices can remain relevant in such a dynamic environment; unquestioningly following a static text is dangerously close to religious practice – I don’t regard this as a good thing, ymmv. So, while I believe that the Agile Manifesto is an excellent baseline, it is flawed and somewhat contradictory in operation. But, like democracy, it’s the best we’ve got.

arbie 9y ago

Your comment makes me think your workflow has become dogma. Does expecting new hires to hew so closely to existing principles give your team room to evolve?