Iv'e just finished reading Re-Work, the 37Signals book that encapsulates their philosophy. Its written by DHH so it doesn't exactly pull its punches.

One of the chapters is about the work environment, it specifically talks about not treating staff like they are kids. Elsewhere in the book there are references to having people who work instead of delegators.

I think that the two ideas mesh together nicely. By giving people the ability to make decisions for themselves. You make yourself less important then if they are constantly having to come to you to ask for permission. At that point you might have to explain exactly what you do all day, or not. Maybe you just get to be able to work normal hours again instead of spending all day answering emails and then doing you day job outside of hours when you are tired.

Tim Ferris talks about the same ideas in the Four Hour Work Week except that employees he has outsourced most of his business to other companies. He told them to speak to each other and if they could resolve any problem for less than $400 to get on with it. At the end of the month he reviews any decisions made and sets new guidelines to inform decisions.

The essence of this treat people like children and they will act that way.

It seems that a lot of emphasis is placed on Definition of Done in SCRUM. Its generally the development team that are going to decide on this and communicate out, as a set of rules for them to abide by you can potentially change them every sprint or project. Hopefully to improve them.

The really complicated on is ready for development, this has to be communicated clearly to people outside the team. It will take them time to get their heads around it, so you don't want to be changing it every five minutes. Ready for dev is also something that is seen differently by different members of the team.

The absolute most important thing to remember is that for a user story to be ready a developer must be able estimate the complexity of the story and then start work on it. This absolutely has to be done without a raft of assumptions being made. If the writer of the user story needs to be consulted its not ready for dev.

There are two approaches to dealing with this:

Stick to the rules: Push back anything that isn't ready even if the sprint is only partially full. Warning this will end in tears.

Work together: The less us and them the better. Before the sprint planning meeting have a chat with the person writing the storys and go through some of them to make sure that there is enough detail. Encourage to flesh them out where needed.

The idea is to wean people off option two and onto one.

Also many thanks to the mate that I blatantly stole this idea from...

Sometimes it nice to see other people rant. That's not f'ing agile amused me. The point that there are certain places where agile might just not be for you is so very true. The on-board shuttle group are most definitely not agile, cos when they fail things go bang.

I've been thinking about this having done lots of it recently on a project with a lot of scrutiny on it. Reporting daily is tedious in the extreme.

Secondly it was via email and Excel, the horror. If there is one indication that you are doing something the wrong way that is it.

If your dealing with multiple projects this get old very very quickly.


So I've been thinking about something that that can send out reports for me, more importantly that lets people subscribe to the information that actually matters to them. This information shouldn't be spread out in various emails and files scattered about the place.

Do I have a solution, no do I hell but I'll keep thinking about it. Tell you one thing though tools like mingle aren't the way forward. 

At some point an agile thing (developer, project, business, whatever really) interfaces with something else. This is hard. Oh and its boring, its boring because you have to keep repeating the same ideas until they stick. And then un-stick them and re-explain because the wrong ideas has suck.

An electronic engineer would call this an impedance miss match.

The standard , solution to this seems to be to preach, oh sorry educate what ever is on the other side of the interface. The essential problem with this is that unless the entire work decided to be agile there will always be an interface. So we need a way to deal with it that doesn't involve conversion.

Oh and to be honest wile we think that its the most important thing in the word, err, no one else gives a damn.

They would mostly just like it to work please, soon if possible.

So how can we avoid going nuts repeating ourselves. Simple, get someone else to do it for you. Absolutely insist that someone from the other side of the interface is involved in the agile thing you are doing.

They can then go and explain what is going on for you, thus preserving your sanity.

Oh and your going to fail if you don't have it.