“The legacy of the nineties has been a dangerous corporate delusion: the idea that organizations are effective ony to the extent that all their workers are totally and eternally busy. Anyone who’s not overworked (sweating, staying late, racing from one task to the next, working Saturdays, unable to squeeze time for even the briefest meeting till two weeks after next) is looked on with suspicion. People with a little idle time on their hands may not even be safe. As [one of the authors friends] at Digital Equipment Corporation told [him] during the company’s darkest days, “There are madmen in the halls looking for someone to ax.” Of course, the ones they were looking to ax were the folks who weren’t all that busy.”

It’s sad to be able to draw parallels with some of the rash actions that were being taken then and the drastic ones people are being forced to take now.

Inevitably, as people look to make their respective companys’ more efficient and trim their bottom lines, Development teams are called upon to get the latest cost / time saving feature delivered as soon as possible.

It’s at times like this, when we’re being asked to go as fast as we can it becomes increasingly difficult to sell the fact that we need to deliver a quality product rather than one in which we’ve cut corners, as Jason suggests in his post, perhaps quality will suffer as part of the credit crunch. But now is precisely the time that we should be pushing harder to see the quality of our product improved.

I’m a believer in the Lean principle that you should decide as late as possible and that development teams should seek to defer decisions until the last responsible moment. Should we defer that decision to include unit tests, to tackle that particularly naughty piece of the code that is always causing us problems or to automate our build and deployment process. Definitely not.

Choosing not to pursue quality from the outset is almost like behaving like a student, leave doing it until the last minute and you will either hand in something that’s rushed, doesn’t really meet the expectations and will therefore need to be reworked or having to ask for an extension to the deadline.

“Those who do not have a clue are still debating about the process.
Those who know, just do it. (56)”

When reading through the rest of the quotes on the page I find the following one more interesting though:

“If you want to be a great leader, stop trying to control.
Let go of fixed plans and concepts and the team will govern itself.
The more prohibitions you have, the less disciplined the team will be.
The more coercion you exert, the less secure the team will be.
The more external help you call, the less self-reliant the team will be. (57)”

I must confess, I’m no Taoist, nor (other than having read The Tao of Pooh, which is another story) do I know that much about it, particularly in the context of Software Development, but in the respect of what a manager can do to establish a well functioning team or department, I agree with a lot of the points above.

I’ve witnessed my fair share of change in what is a relatively short career, I’ve seen it instigated by managers and I’ve also observed it come from the people on the ground. Each approach has it’s relative merits in any given situation, in my opinion though, the act of facilitating change will tend to success more than a command and control structure.

Self organising teams need to be nurtured, they need to feel as though they are empowered to make change, furthermore and perhaps most importantly they need a clear vision of their remit as well as some parameters to operate within.

I think that it is relatively easy to define the vision and parameters for a development team; they should seek to deliver value, aggressively tackle waste and to do both of those continually.

One of the things that is starting to interest me more and more though is business transformation and how some of the agile techniques such as self organisation can be applied. I believe that self organisation can be used as a mechanism to deliver enterprise change however, I think it is even more important to ensure success that a clear vision is communicated and that some definite parameters even if these may change later, to work within are stated.

I’ve been following Karl Seguin’s foundations of programming series and have been impressed, it’s a good starting point I think and covers a lot of the technologies that we use here. He’s recently posted them all, compiled as a PDF, you can go get it here.