Being There

Update: added reference for W.Cunningham quote.

Bill de hÓra writes how keys to software success can be found in the business and operating models you adopt. Heed this advice.

We can be successful with the latest "service orchestration" software or with Smalltalk and relational databases, both decades old. (I think the latter may provide an advantage.) The keys are in how we form teams, communicate, and do work.

I would ban the phrase "service-oriented anything" until my organization understood this paragraph...

The reason in the past we needed to worry that 'it will never X' is because there is an assumption built into the procurement, requirements and development phases that systems of this kind get finished and that's it - no more money for active development. You have one shot to get it right. In turns out that one shot is an operational myth and a dangerous one at that - business systems are never really finished, but thinking that they are radically affects thereafter how budget is dispensed and for what.

Test-driven development is proving to be the operating model for continuously adding value to a system. We need equivalent models for the business that surrounds development.

• Whole teams.
• Communication.
• Frequent feedback.
• Test-driven.
• Continuous integration.

Ward Cunningham illustrates that the burden will land on middle and upper management as developers get their act together...

A common management mistake is to keep everyone busy by giving them different things to do. This basically tells people to work alone, and that is an easy way to fall prey to exactly [all] sorts of fears.

Agile asks the team to work together on only a few things at a time. That way, once someone gets over the wall, they can help everyone else over after.

Customers ask for a lot because they don't think they will ever get a chance to ask for more. Regular delivery of capability that doesn't go away will erase this fear in customers.