Co-location can hide communication problems

We may still be communicating inefficiently but because face-to-face has such high bandwidth, we don't notice. In that sense, co-location is actually raising the water level rather than lowering it.

Without co-location, effective software development teams have no choice but to develop more disciplined communication protocols.

Of course, I'd rather have BOTH good communication protocols AND high-bandwidth communication.

This is the way we've done it for years

When someone says "This is the way we've done it for years", usually it's with the implication that this is a good thing.

But if they've been doing something for years, surely that would be more than enough time to figure out how to improve it? Surely, they haven't stumbled upon perfection and there's nothing left to learn...

In Lean circles I've sometimes encountered a rather harsh description for this kind of behaviour: oxygen thief.

The software community has nothing to learn from Lean operations

... only if the software community thinks that software ends once it's deployed to production.

ThoughtWorks still hiring in Australia (and elsewhere)

Looks like it's been over a couple years since I last wrote a recruitment post.

Well, ThoughtWorks is always looking for people, with the current emphasis on people with demonstrated capability in Agile/Lean coaching, business analysis, and testing.

People skilled in development, architecture, project management or interaction design are also welcome. And if you're just starting out, we have a graduate program. I'm personally currently interested in people who are at the cutting edge of operational management and deployment.

So now let's talk about what I'm looking for, if for example, you ever find yourself being interviewed or assessed by me.

You believe and follow deliberate practice. That is, you practice your skills, you are interested in gradual, disciplined refinement, regular feedback, and have strategic goals. You accept that expertise requires 10 000 hours of deliberate practice and you don't buy the talent myth. This is not to say I'm only looking for experts. I'm looking for people who want to become experts and understand what it takes to become one.

Your career choice is actually a reflection of your strengths and a source of engagement. You've chosen or have tried to choose and grow in roles that best fit who you are.

The type of work we typically do involves direct engagement with clients. This means you actually have to believe in Respect for People and behave that way. Pretending isn't good enough.

----
So if this sounds like an environment you'd like to engage in and help improve (ThoughtWorks like any human endeavor is not perfect), contact me at jcyip@thoughtworks.com or apply online.

P.S. Just in case Australia is a bit too far to travel, I put "and elsewhere" in the title because we also have offices in the United States, Canada, India, the United Kingdom, and China.

What do the boundaries of a person look like?

Let's start with people.

If we could visualise the boundaries of a person in terms of their capabilities what would that look like? How could we show the difference between current capability and potential? How could we show strengths vs weaknesses? That is, how could we show potential that is more easily realised and strengthens the person versus potential that requires more work and drains the person?

What's a role? How likely is it that the artificial and arbitrary boundaries of a role will match the natural boundaries of a real person?

To achieve a goal with a team of people, we still need to work out roles and sometimes acquire capabilities that may not be our strengths. But if we believe that respect for people is important, that people are a first-order component of success, that people will perform the best and grow the fastest when exercising their strengths... if we believe all those things, then the organisations and systems we create should be focused on shaping roles to fit people instead of shaping people to fit roles.

Story points aren't a score

From a management point of view, User Stories exist to manage capacity. Therefore it doesn't matter if it's a "business" or a "technical" story. It matters if it will take time. The analysis of value vs non-value should be kept separate.

Agile design requires intense mindfulness

Agile design, which is essentially evolutionary design, fundamentally requires establishing and maintaining an intense mindfulness of the current state of design and stamping out the small flames that will otherwise turn into raging fires.

Effective enterprise architecture deployment is the same as effective strategy deployment

When deploying an enterprise architecture strategy, the same rules apply as for any effective strategy deployment.

There must be feedback from people focused on broad strategy to people focused on the concrete details of reality... and vice versa.

Everyone involved in deployment must commit to the strategy and therefore should be involved during the creation of the strategy.

The strategy should be based on the best that we've actually concretely seen or experienced, not on fantasy.

There will be large scale problems, medium scale problems, and small day-to-day problems. Responsibility for each type of problem should lie with those closest to the scale of problem.

Strategy deployment leaders should be familiar with all levels of details including impacts on development, support, interaction design, costs, etc.

The best presentation of stats you'll ever see

My friend Michelle pointed me to this 2 year old TED talk with Hans Rosling demonstrating data visualisation using Gapminder World.



Looks like there's now also a Google Gadget that does this sort of thing.