rules of thumb

don't rush

I don't think I can put it any better than Jerry Weinberg did when I interviewed him:

Things take the time they take, not the time you hope they will take. Pushing for half-time produces half-baked.

As a self-employed software coach/consultant I get to travel a lot and visit a lot of companies. At the best companies there is a palpable sense of not rushing.

think team

Software development is all about collaborative learning. I think one of the weakest points of the Agile Manifesto is it's lack of emphasis on teams. The very first word of the four "X over Y" statements is Individuals :-( XP at least takes a firm step beyond programming as an individual activity by mandating pair programming. I look at Sit Together, a practice from XP1 and I think s/Sit/X/. In other words, whatever X is, X Together.

increase visibility

Software and the process of developing it can be, to paraphrase Douglas Adams, mostly invisible. You think more clearly when you have something concrete to tie your thinking to. You manage things better when you can see them and see them constantly changing. It's no accident that Kanban boards are as popular as they are.