13 ms·

[Obligatory plug and disclaimer: Agile professional who wrote an earlier rant "Agile Ruined my Life" http://www.whattofix.com/blog/archives/2010/09/agile-ruined

[Obligatory plug and disclaimer: Agile professional who wrote an earlier rant "Agile Ruined my Life" http://www.whattofix.com/blog/archives/2010/09/agile-ruined-my.php http://www.whattofix.com/blog/archives/2010/09/agile-ruined-... Also I am writing some practical how-to Agile e-books trying to undo some of the damage: http://tiny-giant-books.com/scrummaster.htm http://tiny-giant-books.com/scrummaster.htm ] Just differentiate between what Agile is and how people are pushing Agile on you. Different things entirely. Agile is best practices around iterative and incremental development. Period. Yes, there's a manifesto and there's Scrum and all sorts of other things, but at the end of the day Agile is a marketing term. A place to go find out what people are trying in order to get better. Two secrets here. One, team success is about 90% dependent on who is on the team. Good teams do well. Bad teams do poorly. But if you're going to have more than one team, you need some way to measure and talk about what they are doing, so you have to have something. Agile -- when done correctly -- is just the minimum amount of something you need to get your work done. It is the minimum amount of process. After all, it's not like you can have no process at all. Whatever you're doing already is a process. I've seen hundreds of teams struggle with Agile, and to me the problem is that we do a really bad job of balancing the difference between "here's a best practice that worked awesome for about 80% of the teams that tried it" and "These are the rules. You must do this." In many shops, Agile is just another way of micro-managing teams, sadly. I can't help that. I also can't help the fact that lots of folks are out to make a buck on certifications and such. I don't think that makes Agile bad. Heck, I'm not even against certifications, although I'd never get one. I just think we take things too far. I like the idea of having a marketing blurb "Agile" where I can go to find out what kinds of new stuff is being done. It helps me pick better reading material. The second secret is that most teams, frankly, are not that good. So you need some kind of way to demonstrate that as well. Making things incrementally and in small iterations lets you see how bad teams are early on. You fail early and often. Then at least you have a bit of a shot at trying to help. But believe me, I feel your pain. Sounds to me like you are a lot more upset at modern marketing and management attitudes than Agile. Remember that we technical folks have a way of over-doing whatever we get into, as I was writing in my blog before your post appeared! (It's still very strange to me watching HN how the same topic comes from multiple writers at the same time) http://tiny-giant-books.com/blog/agile-means-stop-focusing-on-the-wrong-thing/ http://tiny-giant-books.com/blog/agile-means-stop-focusing-o...

_delirium 15y ago
> In many shops, Agile is just another way of micro-managing teams, sadly. I think this is a big source of the complaints, yeah. If I had to narrow it to one specific mis-implementation of agile, it'd be having daily standup meetings turn into daily mini-performance-reviews with the boss. Iirc the Official Scrum Rules try to avoid that by decreeing that the scrum-master should be just another team member, and not a project lead or other kind of supervisor/boss, but afaict that recommendation isn't often followed.
- DanielBMarkham 15y ago
  Yeah, you nailed it. I have seen this done so poorly so many times that I simply tell people to rotate the ScrumMaster role. Otherwise they just make it into a manager. A lot of times they want to keep the old Project Manager around, and that's very difficult to do. Project Managers and ScrumMasters are completely different animals. A few times as a coach I have literally thrown the PM out of the stand-ups and told them not to come back because they were turning it into a status meeting. I'm not trying to plug coaching, but if you're trying Agile, you really need an independent outsider to help referee stuff like this. Maybe it's only the SM from the team down the hall, but stuff like broken standups can be impossible to fix without a little neutral nudging.
- CompiledCode 15y ago
  Exactly. It was amazing how quickly, at my last place, standups devolved from ...recounting verbally what one did the previous day... ...to marking one's progress on a whiteboard... ...to having to write down on an index card beforehand and turning it in to the IT director after the scrum meeting (in addition to the above). With the boss (and sometimes, the CEO) in attendance, there was no chance of an honest verbal exchange about roadblocks etc. Good metrics for measuring coding progress are so elusive, I can't imagine management NOT trying to mess with pure agile principles if tight deadlines and delivery dates are at stake.
- Joeri 15y ago
  I think this kind of weird misinterpretation of the buzzwords happens because most people don't actually read anything about agile. They just hear other people say they need to be doing "daily stand-up meetings", and they interpret what they think that means, instead of bothering to find out. I had a wonderful example of this behavioral pattern last week. I was called into my project's first "sprint planning meeting" where I was asked to write down for the next 8 sprints which features would be delivered when. Of course, since we were now "doing agile" I was allowed to be off by one or two features every sprint. But it still had to all fit into 8 sprints, because the project's deadline was by the end of the 8th sprint, and we needed to be sure we would deliver the full scope by then. As pepe le pew so aptly described: "le sigh".

_delirium 15y ago

> In many shops, Agile is just another way of micro-managing teams, sadly. I think this is a big source of the complaints, yeah. If I had to narrow it to one specific mis-implementation of agile, it'd be having daily standup meetings turn into daily mini-performance-reviews with the boss. Iirc the Official Scrum Rules try to avoid that by decreeing that the scrum-master should be just another team member, and not a project lead or other kind of supervisor/boss, but afaict that recommendation isn't often followed.

DanielBMarkham 15y ago
Yeah, you nailed it. I have seen this done so poorly so many times that I simply tell people to rotate the ScrumMaster role. Otherwise they just make it into a manager. A lot of times they want to keep the old Project Manager around, and that's very difficult to do. Project Managers and ScrumMasters are completely different animals. A few times as a coach I have literally thrown the PM out of the stand-ups and told them not to come back because they were turning it into a status meeting. I'm not trying to plug coaching, but if you're trying Agile, you really need an independent outsider to help referee stuff like this. Maybe it's only the SM from the team down the hall, but stuff like broken standups can be impossible to fix without a little neutral nudging.
CompiledCode 15y ago
Exactly. It was amazing how quickly, at my last place, standups devolved from ...recounting verbally what one did the previous day... ...to marking one's progress on a whiteboard... ...to having to write down on an index card beforehand and turning it in to the IT director after the scrum meeting (in addition to the above). With the boss (and sometimes, the CEO) in attendance, there was no chance of an honest verbal exchange about roadblocks etc. Good metrics for measuring coding progress are so elusive, I can't imagine management NOT trying to mess with pure agile principles if tight deadlines and delivery dates are at stake.
Joeri 15y ago
I think this kind of weird misinterpretation of the buzzwords happens because most people don't actually read anything about agile. They just hear other people say they need to be doing "daily stand-up meetings", and they interpret what they think that means, instead of bothering to find out. I had a wonderful example of this behavioral pattern last week. I was called into my project's first "sprint planning meeting" where I was asked to write down for the next 8 sprints which features would be delivered when. Of course, since we were now "doing agile" I was allowed to be off by one or two features every sprint. But it still had to all fit into 8 sprints, because the project's deadline was by the end of the 8th sprint, and we needed to be sure we would deliver the full scope by then. As pepe le pew so aptly described: "le sigh".