The garden analogy suggested by Jurgen Applelo is a great concept.
Gardening around the world takes dramatically different approaches. Here in the United States there are many gardening zones. Having grown up in a "gentleman rancher" environment in North Texas (horse, cows, and wheat), then getting deep into organic gardening in Southern California I was very disappointed when we moved to Colorado. In California you can throw seeds in tilled furrow, splash so water to start and pretty much pick fruit or vegetables on the appointed ripening day. Minus the work to pick off the bugs and a bit of fertilizer, gardening in the coastal southern California area is straight forward.
Most everything grows with a little bit of attention to detail. Kind of like developing software with a couple of engineers and a customer sitting by your side. If you competent at the language and tools, you can get something up and running in weeks or at most a month or two. Skill is needed, you have to have a good customer, and be proficient at your job. But you don't need formal methods, management overseeing your efforts, and especially you don't need detailed plans, and regulations to follow. The code and the Strawberries can "emerge" as the season goes on.
Outside of previous Orange County coastal home (48 Sycamore Creek, Irvine CA), there's a different set of constraints on home gardening. How you manage the soil, what plants can be used, what irrigation systems, and a myriad of other external constraints determine the method used and the probability of success.
We have a moderate garden (under 200 square feet) here in Colorado. Gardening in Colorado is hard work. Low rain fall, high winds in the spring and fall, unexpected snow, and large and small animals all waiting to eat the results of your labor. Like projects that are outside the sweet spot of agile development. External customers, changing funding, poor COTS interfaces, rigorous requirements for documentation, and testing.
When we plant in May (it's snowing today - April 17th), we'll redo the soil both mechanically and with amendments (compost mostly). We'll rebuild the fall wooden boundaries (the underlying soil is clay and granite chunks), repair the irrigation (11" rain fall average). The choice of tomatoes foe example must be "tuned" to our climate. We need to protect them from early season frost, birds, and a few pests. High winds and deer need to be repealed. Careful watering around rapidly changing temperatures in the spring. Root protection with compost.
The garden analogy can be transferred to software.
The conjecture that "managers" are hands off for projects if the project is "self" managing makes some sense. Like a garden that has most of the conditions for success built into the environment. Sun, light rain daily, few pests, good air flow, and nice soil. This yields good results with just a little care and oversight. Keep the bugs off, the raccoons out, and the birds away and you've got nice berries in the planned time.
Are all projects "self managing?" That is a BIG question that no one in the agile community likes to talk about. Gardening in Southern California (and Northern Coastal as well) starts with Sunset Magazine. Picture of lush gardens, hanging flowers, and it may be that the commenter's on the Blog work in a domain where "self organizing" is possible or even encouraged. But there are other domains, where "management" as a verb is not only required it is the critical success factor.
What kinds of domains?
- Enterprise ERP
- Industrial controls
- Banking, financial, retail, commercial COTS products
When we generalize in the absence of a context and a domain, confusion about the topic results.
So someone says "the manager needs to be removed from the team..." in what context can this take place? What is the supporting evidence this is the best approach – not anecdotes, but scalable evidence to other domains and context in the absence of the anecdotal person physically being there? What are the constraints on the team for their behavioral outcomes, skill sets to self manage, and what external condition for their success and the success of the project – in the absence of management.
This statement is much too broad and general to be put to any practice use. Much like the statement the "projects are complex adaptive systems." But more importantly these types of statement are "bottom up" anecdotes of most likely "non managers." How would I scale this to a regulatory managed firm – say insurance, health care, engineering, construction and finally aerospace and defense? Sure Agile works well in Health Care and Insurance. There are agile development firms doing this all the time. But, and this is the BIG but, the agile processes are embedded inside HIPPA and other constraint based guidance. They are not "management free" domains. Same for defense. Scrum is a natural process for development of embedded systems. Scrum driven by IMP/IMS and MIL-STD-881A Work Breakdown Structure process. Process mandated by DoD, but implemented in Scrum-centric ways.
In The End The Absence of Context and Domain Creates Nonsensical Conversations
When a broad statement like "self managed teams are best," or "the manager needs to be removed from the team," needs a context and a domain. Defining the interactions with the team (as suggested by Mendelt Siebenga, is the right starting point. The challenge is how to actually determine what this interaction should or could be. Is this determined by those being managed? Partly. By the management itself – this is difficult having been there before. How about by external assessments and suggestions – this is the role of conferences, journal articles, and research.
But my experience – my anecdotes – tells me without a context and a domain in which to place the anecdotal suggestion is like taking the Sunset Magazine gardening zone suggestions for coastal Southern California and applying them to rural high plains Colorado. You're going be disappointed with the results.
