> the processes we love to make rarely help us

I'm going to make a potentially bold claim here. This depends _heavily_ on what the threshold of "rarely" is, and whether we actually _love_ to make these processes.

In the case of people before process, as stated in the Agile Manifesto, the process is begat _from_ the people in many cases. That doesn't mean it shouldn't be questioned, but when the chimney sweeps that built the process are saying "I don't want to go back to things that are similar to the way that gave me mesothelioma", I don't think it's fair to write them off as the minority.

▲

jmward01 2 hours ago | parent [-]

Every team I have been on that has been effective has had a few common traits:

- Teams stay relatively small so if problems are big then they divide and conquer with teams of teams so that they can:

- Bite off problems that they can fit in their heads which allows them to:

- Meet often not to just speak out loud with nobody really listening, but instead to actually coordinate and plan concrete steps that progresses the problem. And they can make daily adjustments not just because they are a small focused team but because they also:

- avoid backlogs, feature lists and similar documentation where possible since these things give them momentum in the direction they thought they were going when these products were created and not in the state the problem is in now.

Each of these things fight, well, math. Communication is a math problem. If everyone is talking to everyone about everything then you have a non-polynomial growth problem. Designing the big problem perfectly from the start is NP. Divide and conquer doesn't give you a perfect solution, but it gives you a really good one and it gives it to you in reasonable time. Splitting the task, and the team, and minimizing the communication, and accepting the loss in finding the perfect solution that triggers, is all needed for divide and conquer. We never accept that though so it turns back into an NP problem and something ends up dropping. Time, quality, capability or, unfortunately often, the whole thing fails. Similarly, if you put things on a backlog then prioritizing that backlog is again NP and that is especially bad if there is one massive team backlog from all sources. Backlogs become dead idea bins because it isn't possible to organize them efficiently so stop wasting time on them. If your team is properly sized they know what is needed now so they can make the next small step and they can optimally design and implement that step in their piece of the bigger problem. They will get done quickly and have a good product as opposed to getting done never because of the pursuit of the perfectly coordinated and communicated solution.

If you divide and conquer properly then the communication/process you use at each team's level becomes so obvious that every formalized system out there becomes silly. Let the team do whatever works for them. They are small and nimble and learn to talk to each other so no need to slam a process at them that makes them a machine.

▲

gitonup an hour ago | parent [-]

Is this in opposition to what I said? I consider process that is [a) done by the folks in that team and b) revised on a regular basis] to be a form of healthy communication while being efficient.

	▲	jmward01 14 minutes ago \| parent [-]
		Not every response has to be in opposition! I was clarifying more what I think is effective: divide and conquer, constrained communication (a requirement of divide and conquer), minimized process products, iterative development, etc, and that these general ideas are essentially all that is required, not a formal process. I was also, likely badly, trying to point out that if these basics are kept in mind the formal process artifacts and steps really aren't needed. Small, focused, iterative teams are so in sync that forcing them to speak a foreign language (a formalized process) is probably a hindrance. As I write, I clarify my own ideas. If I'm being honest I'm probably writing this more for me to better understand what really has worked than as a response. I hope it generates a good response and makes me think and refine more and I hope it makes others do the same, but really, selfishly!, I am doing this for me I guess to help me focus on these things in the future. So, with that I think this may be where I am really trying to go with this. Maybe we are missing the point with these things. Maybe we should hammer in these math concepts, NP growth, gradient descent (iterative development) and how to measure when teams and problems are breaking because of the math so that we can understand and address the root issue better. I have ever heard anyone explain that NP math concepts and gradient descent dominate the reasons why teams fail or succeed, but the evidence is everywhere. Push the why and how to spot it and less the prescriptive how? Maybe a more effective set of things the industry could be pushing are simpler checks: how big are your teams? How many problems are they thinking about at a time? How many levels of teams do you have compared to the size of the organization? Can each member of a team articulate that team's goal? Can they articulate what their team is currently, this minute, working on? Can the team above them articulate how the goals of the teams below them fit together to solve the problem they were given? Are teams talking when they shouldn't? (We so focus on teams not talking that we often miss that talking too much is kind of a bigger deal). That kind of thing. More management and organization and less process and product oriented.