There are a bunch of non-hierarchical businesses out there. But there aren't many (any?) on the Fortune 100. And that's what I want to change.

I've worked for a long time on expanding the range of human existence. On expanding what is possible by those who push the boundaries. I still see tons of value in that work, but right now I want to focus on something else: expanding the bounds of what is normal.

I want people who are trying to create a business to be traded on the NYSE to, by default, choose a non-hierarchical business model – because that's how you get accepted as a public company. And that's how you get rich as a founder (and make everyone else in the company rich along with you).

This is the part that remains impossible.

So I like efforts like Happy Melly. I thing they can do lots of good. And I strongly believe that it will be the individual contributors – not the CXOs – who push the next business movement. But I'm looking for leverage. An that means shifting the fundamental mindset and culture of 80,000 person businesses.

Seriously, though, if a company can't wait for results for a month or so then it isn't going to get any value out of anything it tries. Or, rather, it will get value only out of the simple stuff. So move on. If they're willing to wait for 4 weeks – watching the whole time, but not requiring proof of success on week two – then you are OK. In this case, you simply need to ensure that your team is well coached, well launched and has permission to improve itself. If so, you will get well into storming inside of the window that people are watching. And so you should start seeing results (some positive, some negative, but at least results).

The first place I'd start is by helping the observers understand that team formation takes time. It is a trust building exercise. That happens as the team runs into problems and works through them. So they should certainly monitor for what's happening throughout, but they shouldn't expect that Agile will magically introduce high-performing teams in 6 weeks.

Also, odds are that they haven't seen high-performing teams before. Odds are pretty good that they haven't even seen teams get out of forming before. So some prep is necessary.

Once that groundwork is laid, then focus on the team. Extreme Programming really does give all the practices that are necessary to create a high-performance team every time. It doesn't take that long. If you are having problems getting a team to gel within 3 months every time (at least well into norming), look to your use of the practices (or, if you aren't using XP, look to the practices in XP that your methodology is missing – they're there for a reason). Make sure you observe the emotional aspects of the team (they're the stuff that really matters for performance, not the intellectual stuff). And make sure that every moment you are enhancing the team's ability to be a team, not your ability to support the team.

There is a ton of nuance in optimally helping a team gel, but there is also a ton of flexibility: anyone can do it with the right practices and mindset; doing it well and quickly is full of nuance. I'd be happy to help with specific troubles – if you can describe them well enough.

In a sense, the topic is pretty simple: tests are for legibility. A little duplication is OK, as long as is the right stuff. The key evil in a test is including irrelevant detail – that makes it hard for people to read the test as a spec. Thus Write Explicit Tests. Hit exactly and only the things that are necessary from this test's perspective. Don't abstract things that are relevant and don't expose things that aren't.

The devil, of course, is in the details. But it's not much of a devil. Simply ask yourself with each test "what, of what I have written here, is not explicitly part of the purpose of this test?" Then find a way to hide that. Do this a dozen times and you will have found most of the useful techniques.

Check it out and drop me a line: @duarte_vasco on twitter

I have enjoyed the posts. I am working through similar org changes and appreciate the insights you give. I hear ya on the team naming. I have wanted badly to name certain teams that could not figure it out but have bit my lip and been glad for it. Some teams take longer than others, but with enough people around each team that have been exposed to agile, they seem to pick up things like a name and quickly swarming. The bigger question has been do they pick it up fast enough for the org not to squash the teams agile attempt.

Any thoughts on steaming the tide when agile squashing is in the air due to a team being slow to gel?

I use mocks to eliminate duplication. I, too, see people use mocks without eliminating the resulting duplication. Often they don't know what do; often they don't feel like they can take the time to do it; often they don't know what the duplication signifies.

The resulting duplication, not the mocks, is the smell.

This duplication signals underlying design problems, almost always related to dependencies that need inverting or methods that need extracting — often both — such as in your example. When we fix the problems that cause the mocks to cause the duplication, the resulting tests do not smell.