In all my years in the software industry, I've never seen a team where I would say the methodology they professed to use actually mattered.
The siren song of methodology is that you can take a poorly functioning software development team, "install" a name brand methodology, and they will turn into a highly functioning team.
The way a new methodology is minted is a person or group of people with experience in the software industry decide to write down the characteristics, philosophies, and practices of teams they've experienced in the wild that were good at making software.
They write a book about it, design training courses, and offer up their services as a consultant to organizations that want to "do" this methodology so their teams can be good like the teams that inspired the methodology.
In a paradoxical way, methodologies are useless for the teams that actually need them. Before people were buying books about Scrum, there were effective teams keeping track of the work they needed to do, maybe as a list scribbled on a whiteboard in the office, an Excel spreadsheet, a series of index cards tacked to a bulletin board. They didn't need to be told about "Product Backlogs". They were releasing updates to their software on some quasi-regular cadence without knowing anything about "Sprints".
Scrum, XP, Kanban—you name it—cannot help your team with these problems:
- We don't have the budget to hire good software developers
- The manager of this team is a jerk and people don't want to work for them
- The product owner is spread too thin so nobody knows what we're supposed to build
0 comments :
Post a Comment