Scott Ambler is in the habit of doing some very interesting surveys. One that caught my attention this morning was on Enterprise Architecture. The interesting part is the tables on success and failure factors. The highest rated success factors are about involvement and communication with both business, management and the development teams. The highest rated ‘reasons for cancelling enterprise architecture programs’ are getting insufficient time, not being able to prove any benefit, and rejection of the EA work (and sometimes the EA) by the development team.

In Agility, Or A Pig On Roller Skates? Ken Schwaber comments on the role of product management / ’the customer’ in Agile projects: The backlog is the result of actual work managing a product, and should be used to increase agility (ie. flexibility in getting higher value items out first), not just to adapt to a different development process. Usually, the introduction of Scrum is initiated by the development organisation. Whether it is completely bottom-up, initiated by the developers to get more grip on their process, or more top-down by development managers interested in increasing productivity and work satisfaction, the initiative is mostly from development.

I’ve just finished watching a Google Tech Talk by Ken Schwaber: Scrum et al, through the ‘running agile blog. This was the first time I’ve seen Schwaber talk, though I’ve been reading his blog. It was a good talk, with plenty of humour, and some very recognisable stories. Some highlights (paraphrased from memory, I’m lazy): “In Scrum there’s this role called the ‘ScrumMaster’. Otherwise often known as ’the prick’. This is the guy who needs to ensure that the team does not compromise on quality.

I’ve been reading up on Test Driven Development, starting out with Kent Beck’s book, then finding his screencasts, first the teasers at vimeo, and later the official release through the pragmatic programmers. There’s also a nice free example available on vimeo from Bret Schuchert of ObjectMentor, of which I watched the ‘Getting started with TDD in Java using Eclipse’ one. The nicest introduction on TDD, and on why you should use TDD, and how it helps you create better designs, emerging from the test driven approach, has been Neal Ford’s articles on IBM’s DeveloperWorks: Evolutionary architecture and emergent design: Test-driven design, parts 1 and 2.

Ron Jeffries has a nice new article on whether agile implies effectiveness, and vice versa. The way he describes this is that an agile approach gives more opportinity for effectiveness, but if you can’t follow the agile approach you can use non-agile measures to still reach a certain point of effectiveness. I think this resonates with some other things I’ve been reading and thinking about. The road to creating a full working agile implementation can take quite a few turns before ending up with the type of completely self-organising team that we’re aiming for.

In A Successful Manager But Never A Successful Project? Bruce Benson writes about a rather thought provoking idea: People might actually like being in firefighting mode! The next time I’m in a situation where I’m having trouble understanding why management is not encouraging improvement, but completely focused on dealing with the craze of the day, I’m going to remember this post. And perhaps arrange some panic theater to keep everybody happy…