Agile – real or placebo?

Is Agile software development just a placebo effect ? Do we get better results because we expect and believe things will get better? Or is there something more to Agile?

Linda Rising continues to enthrall us in seeing agile way of developing software in a different perspective. Earlier it was aping the ape, which gave us new insight in seeing teams.

This time she ponders if the same belief system which makes placebo work in medicine makes agile work in software development.  She believes that the belief system in agile makes many good things happen in agile.  Sheep, it seems, are the believers.

Though I found it interesting, I found it difficult to see the direct connection. Nevertheless it raised some beautiful questions which makes you think. But at the end of the day – does it matter? She says it doesn’t.

Behavioral economist Dan Ariely devotes a chapter on placebo in his book Predictably Irrational . Quote from it: “Placebo comes from the Latin for “I shall please.” The term was used in the fourteenth century to refer to sham mourners who were hired to wail and sob for the deceased at funerals. By 1785 it appeared in the _New Medical Dictionary,__ attached to marginal practices of medicine”. Dan Ariely says, two mechanism shape expectations that make placebos work, one is belief and other is conditioning.

How will a patient react if she knows she is on placebo? How will an agile developer react? If agile is offering placebo, what reason is there to believe that waterfall didn’t? After all, more managers backed waterfall than agile. If placebo is defined as pseudo-treatment with real cure, which part of agile is really pseudo?

Anyway, whatever the questions are, it’s refreshing to see Dr.Linda Rising bringing forth another interesting perspective.

In sight, in mind

A.G.Lafley, CEO of Proctor & Gamble, in his HBR article ‘What Only the CEO Can Do‘ mentions “At our global headquarters we replaced dozens of paintings by local artists with photographs of everyday consumers around the world buying and using P&G brands. All these efforts keep the two moments of truth foremost in the minds of P&Gers as they work.” An effective way to nudge the customer centricity in the people, which he refers to as “hammering home the simple message that the consumer is boss”.

Seth Godin mentions on post on dashboardsOne company put pinwheels on a VPs desk. When sales went up, the pinwheels spun faster…” (Wonder who moved whom).

Ambient makes devices which displays relevant information without being intrusive. They state “some information requires constant awareness” And then explaining the science behind it “Our brains have evolved to monitor several streams of background information without any foreground cognitive loading. Furthermore, our brains bring this information to our foreground consciousness when we discern it to be relevant within a given context.”

Taking about professions, could we have saved the recession if we had giant displays of values and ethics on banker’s offices? That  might be a stretch of fantasy. Or for instance, in software development, known for its uncanny need to herd cats, could we manage to push through the business messages better when we have writings on the wall? Or quality consciousness?

Culture called Agile

Agile is a paradigm change. Agile usually gets introduced in an organization as a new framework, new methodology, with new techniques, so on (Though, there is nothing ‘new ‘ to it) . Agile, after all said and done, is about culture. And philosophy. I am not saying that thinking in terms on framework, methodology, techniques is wrong, but we are not doing us a favour by not beginning at the beginning. This way maybe true agile will elude us.

In 90s, many organizations pretended that by ignoring the uncertainties inherent to software development, the uncertainties will simply go away. Like financial institutions pretending to ignore the black swans. So the some organizations built mammoth structure to control more and more minutely, more and more frequently. They gave an illusion of change, a false security. Meanwhile Standish group’s Chaos reports did good business.

Much has already been said about what the organization culture ought to be to nurture true agile. Definition is the easy part. The trick is in the transformation. And there you start seeing cognitive dissonance. They now have to deal with the layers and layers of concrete poured over the years. Change is so difficult. Much easier is the illusion of change. It’s not easy to unlearn gantt chart; or unlearn that actuals is garbage; or unlearn that time reporting is lame; or learn that pair programming is not waste of time; or relearn that ‘accurate estimate’ is an oxymoron; or learn that team’s and not programmer’s productivity matters.

The way to begin the transformation is to unlearn and relearn. Better to begin top down. The grassroot level, sensing freedom, might already have started changing. But there’s a lot to do there too. Years of command and control had inured masses and they wait for directions, which in the name of agile, never comes. They are deer in headlights. Mentor them to find and build ways. Teach them to own up. Show them the vision. Empowerment never can come if all one sees is laying bricks and not building cathedral. Clichéd metaphor, I know. Steve Jobs once famously hired John Sculley from PepsiCo asking him ” Do you want to spend the rest of your life selling sugared water or do you want a chance to change the world?” . That is showing what vision is. (It is another story what Sculley did to Jobs later).

The managers by then should start building the right culture. But culture gets build brick by brick, over sometime decades. One can also start coaching  the right philosophy. Build the practices to support the philosophy. Build the techniques to support the practices. Use the tools to practice the practices. If you start at practices ignoring the culture or philosophy part, people  might be left standing with the why? questions. And they will end up in laying bricks, not building cathedral.

It’s all in culture. Right culture will spawn the right process. Right process will spawn the right techniques. If it doesn’t happen, look back at the culture, it might be broken. That way, anyday I will prefer ‘waterfall’ with right culture than so called agile with a wrong one. Scrum is after all the framework to help you reach that level of excellence.

Influence of Organizational Stucture on Software Quality

Messrs Nagappan, Murphy and Basilis’ paper on influence of organization structure on code quality caught my attention when was recently mentioned in infoq.com. (Though the paper is not recent, it is published in Jan 2008.)

The paper describes how organization structure affects software quality. Organization structure attributes can be used to build a prediction model for assessing software quality, or to be specific – failure proneness. In authors’ words “In this paper we present a metric scheme to quantify organizational complexity, in relation to the product development process to identify if the metrics impact failure-proneness.” Eight metrics were derived for organization structure. (Though it was difficult to understand how ‘edit frequency’ can always mean instability or low quality code. Think, a developer with healthy habit of continuous refactoring can skew the data.) The guinea pig was Windows Vista with 3404 binaries and 50 MLOC, seemingly the largest such study in commercial software. All data goes through a menacing logistic regression equation to spit out failure-proneness of binaries. This in turn is used to calculate Precision and Recall for pre-defined random split. And out came the numbers. The average precision value was 87% and average recall value was 84%.

Which means 87% of all binaries that were predicted to fail actually did fail. And 84% of the all binaries which failed were predicted beforehand. (It took me some time to understand the difference). Compared to other prediction models like Code Churn, Code complexity (they cited 5 more), the results are shown to be more predictive.

The authors, quite humbly, didn’t rush to propose any prescribed crystal ball model. But one cannot help wonder how this fits together with other factors which are already known to influence code quality, like quality of developers. That means if we keep the org structure same (say a control group) and change the quality of developers, by this model the failure-proneness stays the same, but we know that’s not the case.

The findings were quite interesting, perhaps important too, though this paper, even for a technical one, wasn’t a good read. Sometimes the sentence construction jarred and seemed prone to be misinterpreted or chuckled. (“NOE is the absolute number of unique engineers who have touched a binary and are still employed by the company” or “OOW is the ratio of percentage of people…”. But that’s my nitpicking, apologies). The paper mentions generously other papers which have carried work in similar vein. The references run 37 papers.

It is indeed promising to see that the authors plan to conduct this line of research for open source models where the organization structure is very different in being distributed and non-hierarchical. Similar research on open source might reveal a lot which can be used by other organizations (Open source itself is not likely to benefit from the results, though).

Outsourcing companies specializing is building software/solutions using delivery centers in low cost geographies will benefit the most from such studies. The findings will help clients realize the cost associated with or risk entailed on software quality with distributed development. It will also make sense for agile teams, which once fancied collocated teams, and now getting more distributed.

It might be possible, with enough studies, to suggest an organization structure for minimum failure proneness. But it seems to be a tall order.

[This paper is also being written about here and here.]

Outsourcing in the new normal

McKinsey & Company brought out an article – ‘How Innovators will change IT offshoring‘ (McKinsey Quarterly – October (premium access needed)), with tag line “A new managed-services business model helps both the customers and the employees of offshore-service providers“.

Though much of what McKinsey says is nothing new (I was doing managed services 10 years back, though the now ubiquitous term Managed Services was not coined then), still it’s important to acknowledge that innovation will be a definite game player in the post-recession new normal outsourcing. Organizations like GE, though, has long matured in this concept of outsourcing.

It would have been good to see McKinsey present any data on how clients perceive managed services – as a threat or as an opportunity to focus on core business. There are buyers who do see this as a risk and not comfortable to let go areas which they have controlled for ages. The outsourcers need to fill this gap by making education of clients as part of their sales call. And providing utmost transparency. Transparency, thankfully, got a mention in this article. But transparency is a tricky practice, sometimes, for outsourcers who are trying out everything to respond to cost pressures. It is not uncommon to see clients projects being used as under the hood basic training grounds for novices, something which a buyer will not like to see and expect the seller to bear the cost. That brings another important dimension – trust. Generally speaking, hunger for transparency is more of a symptom. The root cause might be in credibility, or trust. R&D spending of outsourcer might be one important parameter to judge capability which in turn can make it credible.

The article deftly points out how attrition can be better managed with managed services, with an argument that “The key to minimizing attrition is for clients to give suppliers wide-ranging authority to manage their teams locally.”  Fine but that’s just one dimension. The type of work (among many many other factors) also do contribute to retention. And plain-jane help desk and support, even with all management controls, might not be that motivating. (The article do however says that mixing more challenging work might offer solution).

I would have liked to see thoughts on evolution of client-outsourcer relationship. (Referring them as buyer and seller itself seems defeating). Clients and outsourcers need to build long term partnerships which means mutual investment; merging on part or full of R&D to build assets together; flexibility in forming cross teams; so on. Together they need to build a platform of collaboration among different players, even if they happen to be competitors (like multiple outsourcers for same client, or other players in same business as client). Outsourcers might like to have some rights in using some models or assets in other domains or for other clients, again, even if they happen to be competitors. Same goes with clients also.

Then on Metrics :
“…..the highest levels of satisfaction and performance were reported by client companies that focus their offshoring performance metrics on a limited number of goals relevant at the CIO level. That’s not the traditional approach; clients have relied on an assortment of detailed, mostly cost-focused metrics that failed to frame their strategic objectives and achieve sustained performance improvement. Successful client-supplier partnerships are moving away from such legacy reporting systems, which reinforce the micromanagement aspects of the staff augmentation model…..More modern measurements focus on three to five goals.……”
That’s very important – to keep a few good metrics that focusses on business factors. It is not uncommon to see outsourcers trying to impress clients with lots of metrics, few of which being useful.

Business analytics and statistics might be areas outsources need to build capability in. Together with the client. There are huge amount of data, which on analysis, will show directions to improve services. And out will come a few good metrics.

All in all, the game will definitely change.

Conducive culture

“Before the boys’ team won the first-ever state cross-country championship in the school’s history, she didn’t explicitly set the goal or try to “motivate” the kids towards it. Instead, she let the kids gain momentum, seeing for themselves -race-by-race, week-by-week – that they could beat anyone in the state. Then, one day out on a training run, one boy said to his teammates, “Hey, I think we could win state.” “Yeah, I think so too.” said another. Everyone kept running, the goal quietly understood. The coaching staff never once mentioned the state championship idea until the kids saw for themselves that they could do it.
This created the strongest culture of discipline possible, as the seven varsity runners felt personally responsible, for winning state – a commitment made not to the coaches, but to each other.”
(bold mine)

The above is from Jim Collin’s ‘Good to Great’.

I quoted it verbatim to illustrate how powerful can self organization be. Corollary to that, how fake can the absence of it be.

For an initiave like agile or innovation to be successful, the underlying structure need to be conducive. Support structure comes from right culture, values and principles, not policies or power games. Sometime, we fail to take a holistic view of the organization and its culture and principles. So a typical organization with decades of top-down, command-and-control way of life suddenly wants to flip a switch and be successful with agile.

But there’s no such switch.