Link | Formats | verticalslice

This is what Jason Fried of 37signals did when he gave his company a month to work on projects of their own choosing.

Sounds radical at first thought but if you have dedicated passionate people it makes a lot of sense. It’s the staff involved in the day to day running and building of your business that are most likely to know what your business needs. Fried has given them an opportunity to demonstrate what’s needed and the solutions to those needs.

How can you afford to do this? How can you afford not to? Argues Fried: “We would never have had such a burst of creative energy had we stuck to business as usual.”

Jason Fried – Why I gave my company a month off

Wonderful short video on how to be a Product Owner – should be required viewing for all PO’s and similarly essential viewing for anyone that’s trying to understand the principles of Agile. Captured in this video is the essence of Agile product development. Watch it once and if you don’t understand it all, watch it again. But most importantly, if you are a Product Owner, note the parts about working closely with the team.

Valve Handbook

Employee Handbook describing Valve’s completely flat management structure. Not exactly a methodology that you could apply to a big shareholder owned corporate but a great example of how successful you can be if you hire good people and allow them to get on with their job.

@azaza tells the story of how the English Channel was crossed on a man-powered machine by firstly solving the problem of how to iterate quickly and try thousands of differently configured aircraft. Thanks to @mootpointer for this one.

To wit:

If the problem you are trying to solve involves creating a magnum opus, you are solving the wrong problem.

http://www.azarask.in/blog/post/the-wrong-problem/

Unusual to have the SMH with a piece on the challenges facing the Software Industry. This quote absolutely sums up the problems that the Agile community is trying to solve

The old saying of ‘measure twice and cut once’ actually works against software development because it creates this false expectation that if we spend more time planning we will spend less time changing our minds. Sometimes the way it works on paper feels wrong once put into software or what appears as mild scope creep actually results in fundamental changes under the hood. I feel that the modern digital equivalent should be ‘prototype twice, go live once’.

verticalslice

being agile

Links