4 ms·

Good point. The irony is this https://agilemanifesto.org/display/index.html https://agilemanifesto.org/display/index.html All these programmers agreeing to I

• tored 4y ago
  My homegrown conspiracy theory is that Agile was invented by project managers that wanted to constantly change project goals. Broken pleb developer - Why are why yet again changing project goals? We already changed them last week after a long meeting. Carefree Manager - It is Agile to adapt! Core of Agile makes sort of sense, that you continuously involve the client and iterate thru the project to create a product that meet client demands. However that also assumes that you are working with clients that are competent, in the real world most clients are clueless. Now you have a clueless client and a clueless manager running the project to the torment of the developers. In my own experience after working at different management positions (team lead, scrum master, senior developer, project manager, technical project lead, architect etc) is that the vast majority of developers, me included, are uninterested in project management, they just want to code. Thus when I run projects I run it as a dictatorship instead of a democracy (scrum) and give the developers the tasks that fit them based on their skill level. This requires some skill in understanding your developers needs, 1) that they feel that they make a difference, 2) that they have some freedom on how to solve each task, but within the constraints of the architecture and project. It usually works best for everyone involved. If there are some developers that do enjoy project management (often they are knee deep into scrum theory and such) I handle them separately from the rest of the team and do some project management with them only. No reason to involve the entire team just because a single developer enjoy retrospect meetings. If there any valuable conclusions (rarely) you can introduce it to the rest of the team afterwards anyway. Scrum and such theories assumes that every developer are equally engaged in the project, in reality that never happens because we have different personalities, different skill level and different priorities, thus making a developer to "freely" pick a task from a board of tasks is just nonsense. We all know in advance who will do what, it is just a charade. Same goes for planning tasks, if you have no idea how to implement a task you can't really help with planning it either. The common timeboxed two week scrum iteration is probably one of the most common reasons why developers feel stress. Morning meetings must have an agenda, a chairman and be timeboxed, otherwise it is a waste of time. Personally I find that asking what everyone is doing is a bit unnecessary, most people don't care and wont listen anyways. It tends to be better to use that meeting to inform what is happening next in the project. Common among developers is that they are a bit socially inept, however many of the scrum ideas force them to into socially awkward situations, I view that as bad company policy. Clients needs to be handled individually on case by case basis, you can't run an entire project management style based on the assumption that clients know what they are doing. Most clients will accept your decisions if you present them confidently, they view it as they pay a professional so solve their problem, similar how you would hire a carpenter.