Grigori Melnik: Thoughts on Agile Software Engineering and Beyond : empirical evidence

Ethnographies to guide strategy

gmelnik — Wed, 25 Mar 2009 10:28:49 GMT

Ethnographies are descriptions of people with their habits and points of difference (typically, in their natural settings). They explore the richness, depth, and complexity of some phenomena. These descriptions are based on extended observations, which make this type of studies particularly difficult to produce. Popular in social, geographical and psychological studies, ethnographic-based research studies are hard to come by in computer science and software engineering. This is to no surprise as, historically, empirical software engineering was rooted in the quantitative paradigm and many pundits still believe that ethnographic research is less rigorous than other “hard”, quantitative methods of scientific inquiry (a multi-decade old positivism vs interpretivism argument). Still, ethnographic methods are slowly gaining popularity (see published studies on the topics of agile teams dynamics, conflict in software engineering teams, distributed teams, maintenance work).

Importantly, ethnographies are also getting attention in the industry. Corporate ethnographies are being used nowadays not only to explain customer behavior but to actually inform strategy and long-range planning. Ethnographic research is complementary to market research. In a short column of March 2009 issue of Harvard Business Review, Ken Anderson, an anthropologist at Intel Research, explains how it is different in a way that unlike market researcher who tend to ask specific and highly practical questions, ethnographers observe people in a nondirected way – the goal is “to see people’s behavior on their terms, not ours.” He describes how ethnographers have veered into strategic questions (in particular, in a business unit that is concentrated on processors and platforms for home use). Anderson concludes that “ethnography has proved so valuable at Intel that the company now employs two dozen anthropologists and other trained ethnographers”. He believes that “ethnography is so beneficial that it will spread widely, helping firms in every industry truly understand customers and adapt to fast-changing markets”. I tend to agree with this prediction.

At Microsoft, we too use ethnographies. I was actually quite happy to find people with job titles “UX – Ethnographer”. I am going to see if I can get any of them engaged on the Enterprise Library project. With their help, I plan to gain additional insight into how developers actually use Enterprise Library, not just what they say about their experience.

(Un)training puppies or adventures into the world of agile

gmelnik — Sat, 21 Mar 2009 03:18:16 GMT

As I was going through postings from our internal agile discussion forum (yes, we do have one at Microsoft and it’s pretty vibrant too, with, on average, about a dozen of messages daily), I came across the draft of Sara Ford’s story about how she learnt to program manage an agile team after 6 years of waterfall. Sara is a colleague from Codeplex team. She was asking for feedback on it prior to posting it publicly, which she’s a got tones of. I don’t want to re-tell her story but encourage you to read the final version as I do think it’s an awesome first person account of how a convinced waterfallian ventured into the sea of agile and what kind of mindset conversions took place.

The paragraph that I thought was quite notable and also funny is when Sara talks about the spec:

“…during my first week on the team, I had asked a specification question, like how many characters do we allow for a password? And Jim says, “we’ll have to look it up in the test cases.” And I said very proudly from my Visual Studio experience, “Gotta love it when the test cases are the specs.” (yes, I said this to Jim Newkirk, my manager.) To which Jim very calmly replied, “That’s the way it is supposed to be.” And I laughed, and then after a pause, I said in slight horror, “you’re serious, aren’t you?” It was like finding out there was no Santa Claus or you really don’t vote for the President of the United States. The mind just simply can’t comprehend.”

With time Sara’s mind learnt to appreciate and make the most of test cases as requirements. This resonates with the The Equivalence Hypothesis Bob Martin and I formulated several years ago stating that “as formality increases, acceptance tests and requirements become indistinguishable”.

When I saw Sara by the coffee machine today and commended her on posting the story, she mentioned that the actual look Jim had on his face at that moment of telling her to look up the spec in the test cases was identical to the one of a pet-owner who was ready to punish a new puppy for ruining the carpet and stopped short from smacking it while thinking to himself “Wait, it’s a puppy!”

After all, it looks like old tricks can be unlearnt.

Empirical Evidence of Agile Methods: ce que nous savons, ce que nous pensons savoir et ce que nous voulons savoir

gmelnik — Tue, 13 May 2008 16:37:00 GMT

I gave two versions of my talk on the Empirical Evidence of Agile Methods : What We Know, What We Think We Know, and What We Would Like to Know at the patterns & practices summit in Québec City, Canada and the Agile Québec user group last week. Here’re the materials of the talk I promised to post.

As a side note: I’ve noticed that the Quebec audience mainly interacts with their eyes. They are so polite that they don’t interrupt the speaker, they even turn off their cell phones.

IEEE Software Special Issue on Test-Driven Development

gmelnik — Mon, 02 Jul 2007 23:34:00 GMT

The special edition of the IEEE Software Magazine dedicated to Test-Driven Development is out. As TDD is becoming more popular across all sizes and kinds of software engineering projects, Ron Jeffries and I specifically looked for articles reporting on non-trivial use of it: test-driving control systems design, GUI development, database development, performance optimization, storytest-driven development. We also included a comprehensive summary of empirical studies on TDD in both industry and academia and a debate on the role of mock objects in TDD. Happy reading!