4 ms·

Three Ways Agile Has Gone Astray

2 points by aard 8y ago

caymanjim 8y ago
There are legitimate complaints in here, but it sounds more like the author has had bad experiences than that the practices themselves are at fault. I've been consulting for the past decade, at a company focused on agile methodology. Prior to that, I worked at waterfall organizations. As I consultant, I've seen about ten companies that practice (or pay lip service) to most aspects of agile. I agree with many of the concerns expressed in the article, but I'd counter a few of them. Sprints are a great learning tool. If you've got to timebox your development to two weeks, you've got to learn to break features down into bite-sized chunks. You've got to learn to write flexible code so that it's possible to accomplish something meaningful in two weeks. Over time, you learn to effectively estimate work, and your estimates are no longer meaningless and wrong. You can better predict milestones for the business, which goes a long way toward building faith and trust, and ultimately reduces stress and pressure. It also provides a regular cycle of checkpoints for the business, in the forms of demos, planning meetings, retrospectives, and other opportunities to give and receive feedback. This all helps both the business and the team to plan. When teams get into a rhythm, they can consider switching to a looser workflow, whether another defined practice like Kanban, or something less formal. Or stick with sprints if everyone is comfortable. Collective code ownership doesn't preclude having a domain or technical expert who provides leadership for a component. It doesn't mean everyone's opinion carries the same weight, or that you shouldn't have a gatekeeper, or that you can't require sign-off before merging changes to the production branch. It simply means that everyone feels empowered to work on anything, and that the team shares knowledge and responsibility. This isn't in opposition to the open source model cited. It's about teams sharing power and responsibility so that there aren't silos, sacred cows, or people whose disappearance would be catastrophic. Estimation is notoriously difficult, but it's necessary. Free open source projects outside the scope of a business don't have to estimate because they don't have paying customers, they don't have requirements, they don't have business deadlines. There may be reasons to impose some of those things, but in the end you're talking about projects that are largely staffed by people volunteering their spare time, with the freedom to do what they want when they want. A business has competitors it needs to beat to market, has sales and marketing and supply chain timing to coordinate, has support staffing decisions to make, and has customers making demands. You can't simply ignore these business realities and throw up your hands because estimation is hard. You have to learn to estimate, as a team, to provide predictability. The more you do it, the better you get at it. This ties into sprints as well; they provide a timebox within which a team learns over time to get better at predicting delivery. There are valid observations and concerns in the article, but no solutions. You can't simply dismiss the problems that agile methodologies try to solve. No ritual is a panacea. The true agile philosophy is to constantly evaluate the situation and try to find a better way of doing things. I didn't see any suggestions in this article, so I'll stick with the tools that have worked for me.

2 points by aard 8y ago

There are legitimate complaints in here, but it sounds more like the author has had bad experiences than that the practices themselves are at fault. I've been consulting for the past decade, at a company focused on agile methodology. Prior to that, I worked at waterfall organizations. As I consultant, I've seen about ten companies that practice (or pay lip service) to most aspects of agile. I agree with many of the concerns expressed in the article, but I'd counter a few of them. Sprints are a great learning tool. If you've got to timebox your development to two weeks, you've got to learn to break features down into bite-sized chunks. You've got to learn to write flexible code so that it's possible to accomplish something meaningful in two weeks. Over time, you learn to effectively estimate work, and your estimates are no longer meaningless and wrong. You can better predict milestones for the business, which goes a long way toward building faith and trust, and ultimately reduces stress and pressure. It also provides a regular cycle of checkpoints for the business, in the forms of demos, planning meetings, retrospectives, and other opportunities to give and receive feedback. This all helps both the business and the team to plan. When teams get into a rhythm, they can consider switching to a looser workflow, whether another defined practice like Kanban, or something less formal. Or stick with sprints if everyone is comfortable. Collective code ownership doesn't preclude having a domain or technical expert who provides leadership for a component. It doesn't mean everyone's opinion carries the same weight, or that you shouldn't have a gatekeeper, or that you can't require sign-off before merging changes to the production branch. It simply means that everyone feels empowered to work on anything, and that the team shares knowledge and responsibility. This isn't in opposition to the open source model cited. It's about teams sharing power and responsibility so that there aren't silos, sacred cows, or people whose disappearance would be catastrophic. Estimation is notoriously difficult, but it's necessary. Free open source projects outside the scope of a business don't have to estimate because they don't have paying customers, they don't have requirements, they don't have business deadlines. There may be reasons to impose some of those things, but in the end you're talking about projects that are largely staffed by people volunteering their spare time, with the freedom to do what they want when they want. A business has competitors it needs to beat to market, has sales and marketing and supply chain timing to coordinate, has support staffing decisions to make, and has customers making demands. You can't simply ignore these business realities and throw up your hands because estimation is hard. You have to learn to estimate, as a team, to provide predictability. The more you do it, the better you get at it. This ties into sprints as well; they provide a timebox within which a team learns over time to get better at predicting delivery. There are valid observations and concerns in the article, but no solutions. You can't simply dismiss the problems that agile methodologies try to solve. No ritual is a panacea. The true agile philosophy is to constantly evaluate the situation and try to find a better way of doing things. I didn't see any suggestions in this article, so I'll stick with the tools that have worked for me.