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. Again, all factors of involvement and communication.

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. This is both odd, and something of a problem: The main focus for Agile is to get the most value for the customer as soon as possible. This should be of huge interest to the customer, usually product management. But it often isn’t. Perhaps because the principles are not very well understood, or perhaps because any project manager has now been trained in distrusting development teams and their management because what is asked for is usually not delivered.

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. He’s the one that has to say, when some item has not been finished to the agreed level of quality: ‘Sorry, this is not going to be demoed’ to the team, and ‘Sorry, this will not be delivered until the end of the next sprint’ to the Product Owner. You can imagine how popular this makes this guy. They usually burn out after 12 to 15 months.”;

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.

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. A lot depends on the people in the team, the support in the wider organisation, and the experience with agile processes. Scott Ambler has been talking about his Agile Maturity Model which promotes that ‘you should strive to be as agile as you need to be, and that will be driven by the situation that you face’. Jeff Sutherland has been emphasizing that new teams should start with a complete and structured Scrum implementation before they start adapting it to their specific situation, to avoid team (and whole companies!) to ‘adapting’ Scrum towards their previous way of working.

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…