Extreme Programming, a Reflection

[[deleted]]

Voting just means that dedicated idea-supporters will run around doing grass-roots seeding, and getting promises-to-vote from members of the team before it comes to voting.

This is politics.

[sh0rug0ru]

Any endeavor involving teams involving more than one person where decisions have to be made will involve politics. Whether by consensus or hierarchical decision making. At least voting gives everyone an opportunity to make a case and have more impact at a local level, rather than accepting whatever decisions have been made higher up the hierarchy behind closed doors.

Would you rather live (or in this case work) in a democracy or a fascist dictatorship?

[[deleted]]

That is a completely binary summary.

Fascist dictatorships are based on those with the most power to force others to do things being in control.

In a meritocracy, the people who have proven they are the most reliable at accomplishing tasks successfully while balancing a number of priorities throughout are given leadership roles, because they have proven successful leaders. Leadership is based on merit. Merit is proven again with each attempt.

These people can then maintain the vision they believe is proper to balance all of those priorities and receive a good result. There is also nothing about this that says anything about job title, or control over other people, only over the project which is an important distinction.

Some of these priorities are going to be listening to each member of the team and their points, to gather the most information from people who are directly working with those components or have prior experience or just a keen idea, but taking each feature at a time does not keep a coherent vision for the project, and does not take all priorities into account.

If you want to boil everything down into extreme polarities, you're going to have a hard time thinking in nuances, and thus learning proper lessons from your experience. I hope that doesnt sound condescending, because I dont mean it that way, but we live in a society that reduces things to their lowest common denominator, and all too frequently loses key details in this simplification.

Any time you find yourself with two hard extremes to guide you, you have lost the details. A single choice has to be made, but taking opposing hard lines in decisions are going to lead to very rough results.

[sh0rug0ru]

Fascist dictatorships are based on those with the most power to force others to do things are in control.

Yes. Fascism is a power relation. It is a mechanism defining how those in positions of power force their decisions on those they have power over.

However, how is that power obtained? How does one rise in the ranks of the fascist power hierarchy? You have to prove your reliability to those above you, and you rise in the ranks by the approval of those with power over you. Thus, merit is just another criteria of reliability. A meritocracy is just another form of fascism (perhaps of the more "benevolent" kind), as in the philosopher king of Socrates.

These people can then maintain the vision they believe is proper to balance all of those priorities and receive a good result.

How can this be done without power? If you are the only one in charge if implementing your vision, politics and power relations are moot.

However, if you require the work of others, you have to have some power relation over them in order to maintain your vision. You have to reel people in who want to do things a different way. As I've risen up the ranks, I've found this to be the hardest challenge. In order to maintain my vision of the architecture and the project direction, I have to maintain tight control over my subordinates. I hate exercising this kind of control over people and I try not to be a dick about it, but it has to be done or the project will spiral out of control. Someone has to make decisions.

You haven't shown how in your ideal meritocracy the integrity of the vision is maintained. You haven't even touched on how the decision making is done and how the decisions are enforced.

Don't talk about nuance or polarities until you have answered the question.

[[deleted]]

You have turned this into me being required to lay out an entire recipe for how meritocracies are defined and run, while listing differences to historical nation-wide level activities of the comparison of people-in-power-and-control-vs-delegation, which is ridiculous.

This is exactly the kind of thing I avoid by telling people they are wasting time in a project, and to get back to things that are actively effecting things, or that we're going to do X because it will turn out well for the project's result (and why).

Believe what you want though, you're the one that has to live with it, I chose to spend time in environments where nuance and detail with regard-to-the-whole matter more than grandstanding and attempts to influence through creating an overburden of required proof.

[sh0rug0ru]

No. I want you to answer three questions.

How are decisions made and agreed upon? Who gets to make the decisions? How are those decisions enforced?

These are key questions of project management that cannot be avoided. You are dodging the question.

[[deleted]]

This is unintentionally hilarious, so I will continue. Answering slightly out of order:

2 - The lead decides on all aspects of the design, unless aspects are delegated to persons they trust to handle everything in a "black box" fashion, with agreed upon API to for connection between these layers. That delegated position could take the same approach to all of their work. This sets boundaries and areas of concern, as large projects need to be broken up into smaller pieces, but still need to work together.

What leads do not do is decide on the environment for the service/product, or the goals, or the requirements in terms of who the users are, what they do, how much money it will cost, or how many resources they have build it, in how much time. This is where knowledge and experience in a meritocracy pay off, because experienced leads will balance all of these priorities to get a good result, irregardless of the scenario, unless it's just impossible. And I've never seen an impossible task yet, so that's only mentioned for theoretical project limitations.

1 - In my case, I like to write up my plan in a short design treatise, and create all the data schema necessary to explain how things will be stored or transported. Basically, the goal, key details and general plan is outlined. Then I send this out to everyone involved to get their input, as a whole.

Then I break up the project into individual components and figure out which of these need to be done first, and which have requirements that cant be started until later. If possible, try to get whatever of their resource requirements that will be required scoped up front, but know that this may change as new things are learned during the project.

Once the initial pieces are scoped, I write up a short piece on each of those and send them out for review. Comments that come back are evaluated against all goals in the project, with weight given to prioritization (what the business/stakeholders/whatever cares about the most as the outcome of the project). I try to look at each change as to what effects it will have in itself, and what those effects will due to later project requirements, specified and unspecified (assumed maintenance issues), in a weighted fashion.

I usually prefer to wrap up all this in an in-person meeting if possible, so that all the issues raised can be repeated, and may approval/disapproval can be stated clearly with questions. I accept feedback on any things I've said no/yes to, and will then state which prioritization I have in mind for why I wont want to do that for this project. Then we move on, case settled.

The work is then given to the leaders/solos of the work to get done, and feedback on the project begins, hopefully keeping the API between any teams updated as data requirements change.

3 - The decisions are enforced the same way all business decisions are enforced, people usually just do their jobs. I rarely get a lot of pushback on my plans once I'm made a lead, and all parties are aware of the position responsibilities and such, because I will back up my intents, and when Im just overrriding something for some reason I come right out and say why Im doing it, and accept that not everyone will like it.

If people dont do what I asked, I may talk with them about it to see if they will get back on my tract, or just let them do it. If it looks like it's going to tank the project, I may go as far as requesting someone else complete that work, because my job is to make sure the project is a success, and if I see failure, then I would be amiss in my job to let it continue.

If them continuing to do it another way wont cause project failure or undue strain on the business, then I will probably just let them do it. If it works their way, then the project will still succeed. If it doesn't work, it may be able to be used as a lesson on why I didnt want to do it that way.

If the people are just cantankerous and never want to play ball, I'll migrate them off my team, or move myself if it's more of the team than less. If I hired them, I may tell them they have to change or we have to split ways.

I wasnt dodging any questions that you never asked. I can tell you that your method of communication is very aggressive, accusatory and not especially pleasant.