Skip to main content

Posts

Showing posts from February, 2014

Return of the Matrix: The Organization Around the Self Organization

Do you have a group of, say, 100 people, whom you want to organize optimally for a software delivery program?  Martin Fowler is famously on record saying that " scaling agile is the last thing you should do. " A better approach is to try to scale down your project. ...an unscientific straw poll revealed that most projects could lose about half the people of the project without making things go slower. Time and time again I hear of success occurring when a team is cut significantly in size. Large teams carry a big overhead in communication and management. Using smaller teams staffed with more able people is usually faster and cheaper, even if the everyone is more individually expensive. This brings to mind one of Tom Waite's "non-lethal weapons," the Shrink Ray, in the movie Mystery Men ,.  Aficionados of the movie (or comic) will remember that the ray is "based on simple dry-cleaning technology." From the Blu-ray site:  http://www.blu-ray.com/m

Patterns for Agile Transformation Success: Agile Enterprise Adoption Without a Gut Rehab

Mike Cottmeyer has re-emerged in the blogosphere, after a bit of a lull, with an electrifying series of posts about enterprise agile, one of which is entitled How to Structure Your Agile Enterprise .  I love the whole series, and especially this post, anchored as it is in Cottmeyer's real life experience: First of all… let me share that I have NEVER worked on a small agile team. I’ve coached many of them, but my introduction to agile was in the context of large enterprise class financial systems… things like online banking and bill payment. The kinds of systems where the company makes a penny or two on every transaction and does millions every year. Is this your enterprise business flow reality??  From http://thedailywtf.com/Articles/The_Customer-Friendly_System.aspx Cottmeyer provides some really crucial insights about agile at scale that may run counter to what you believe is "fundamental" to agile: "Feature teams" are not practical, if any given