Twenty five posts on agile

I was re-organising my bookmarks yesterday and I decided to collect some of them into a post. Here then, in no particular order, are twenty five posts on agile:

1. Ten-Minute Build
2. The Next Big Thing
3. Knowing when you're done
4. The Coad Letter: Strategy Edition, Issue 40, Working Together -- Lessons Learned From Fred
5. An XP Team Room
6. Using Continuous Integration? Better do the "Check In Dance"
7. The Satir Change Model
8. Being an effective Onsite Customer or Product Owner
9. Agile team room photos
10. Scrum Tools Roundup
11. Agile Adoption across the Industry
12. Testing: Coverage Reports Considered Dangerous
13. It's Not Just Standing Up: Patterns for Daily Stand-up Meetings
14. Risk To Pattern Table
15. Buildix: The Agile development platform on a disk.
16. Dysfunctional Agile, Agile-in-the-Large
17. Project risk reduction patterns
18. Sending People Home
19. Agile - Losing Sight of the Goal?
20. Agile, Top Down
21. No Best Practices
22. Baby steps for your project in the new year
23. A Pragmatic Project: Live In Concert
24. Badge of Merit
25. Unjust Deserts? [PDF]

This post is a part of the selected archive.

Proto.in, Chennai, January 20-21, 2007

What is Proto.in?

Proto.in is positioning to be something like the DEMO conference. From the Proto.in blog:

One question that came up over and over again, was the question of What this event is supposed to achieve and what is the goal that we are aiming for? It’s simple. We are not just an outsourcing destination. We have innovation happening and we just want to shout that out to the world, so that the investments are varied and will also take that into account.

The event is scheduled for the dates of January 20th and 21st. We are narrowing down on the venues and the final list of companies will be 30 of them, with ten minute slots to present and make their pitch. The three questions that basically need answering are:

1. Who are you?
2. What do you do?
3. Why do you want the money? or What can you do with more money?

This is a pretty exciting time to be in India. Lots of cool stuff happening.

Agile in the Communications of the ACM

I got my October 2006 issue of the Communications of the ACM in the post today. The featured topic of this issue is "Flexible and Distributed software processes", and a lot of articles feature agile software development, especially in the context of distributed software development. If you have ACM digital library access, you can read the articles online at the above link.

The leading article, Flexible and Distributed Software Processes: Old Petunias in New Bowls?" (ACM Digital Library membership required) has some interesting commentaries by well known experts. Although about global software development and distributed teams, much of it is also applicable to co-located teams. Here are some snippets

David Parnas: I have been hearing the term "software crisis" for more than 40 years. Clearly, it is not a crisis; it is a chronic problem. Each time someone uses the term "crisis," it is a preface to the announcement of a new miracle cure for the problem. Examinations of the cure usually reveal new words for ideas the have been tried before without much effect. This decade's crisis is global software development (GSD); this decade's miracle cure (for all the ills of the industry) seems to be a collection of methods known as "agile."

It is fashionable to speak of "grand challenges." The real grand challenge is not to find ways to to avoid producing documentation, but to find ways to produce useful documents—documents that take time but save more time. We will find that real agility comes from good design that is well documented in precise, lean documentation.

Barry Boehm: There are no one-size-fits-all solutions. The best way I have been able to find is to use risk as a way to determine where to go agile and where to go document-driven. Thus, for example, if you are developing a graphic user interface (GUI) for an unprecedented decision support system and want to document its requirements, the most frequent answer you will get from users is, "I can't tell you in advance, but I'll know it when I see it (IKIWISI)."

In such a case, it is a high risk to try to document the GUI in advance, and with a GUI builder tool, it is a low risk not to document it.

On the other hand, when you are outsourcing a relatively stable piece of business logic to a contractor 10 time zones away, it is a high risk not to invest in a significant amount of thorough documentation of the interfaces and protocols connecting the outsourced sofware to the rest of your software.

Giancarlo Succi: No one thinks that analysis and design are useless. But consider a system to dispatch tracing messages and other information to a group of trucks. This domain is likely to be alien to most software developers. In such a case, would it be better to first spend a lot of time doing the upfront design, and eventually writing the code, or to work incrementally, involving the end customer, interleaving some analysis, design, and even coding, so that the developers grow their knowledge of the system domain?

Matthew Simons: While the idea of story cards appeals to those with no desire for reading or writing technical documentation, the reality of the situation is that such scanty artifacts are rarely sufficient for development of anything beyond simple systems for highly accessible individuals or small groups of users. This scenario rarely applies to GSD. As the picture becomes more complex, we have found the story card-only approach quickly becomes inadequate.

While writing effective documentation is a good place to start, we have found it takes a lot more than that to deliver complex systems with distributed teams. Without the discipline that comes from the remaining agile practices (such as Test-Driven Development, Continuous Integration, Pair Programming, among others) good documents are nothing more than a step on the long and perilous path toward successful delivery.

Like I said, the quotes above are only snippets. The actual commentaries include a lot more context and information than I have provided here. Read the whole article if you can, it is well worth it.

This post is a part of the selected archive.

Agile is not a set of techniques

A few weeks ago, Steve Yegge had a post on Good Agile, Bad Agile which caused a huge flutter in the blogosphere. The reactions on the Extreme Programming list went from "this is the usual 'I don't understand agile, so I'll bash it' crap" to "listen to your enemies. They'll tell you things about yourself that your friends never will." with a whole bunch in between. The post even turned up on Slashdot and Joel. Wow. Steve then posted a followup titled Egomania itself.

I personally think that both the articles have some good parts and some bad parts. He correctly points out that agilists can sometimes be loud and dogmatic. This is true and I've written about it before: Agile is not XP.

Having said that, I really do think that agile principles from the Agile Manifesto have a lot of value. Most of the problems associated with agile come from the 5 pitfalls list. Just to summarize, here is the list in short:

1. Unfamiliarity
2. Top-down thinking
3. Culture change
4. Incomplete implementation
5. Silver bullet syndrome

When something starts to get popular, there are any number of managers who want to implement it to get immediate results. "This book says that if we write requirements on index cards instead of an excel sheet, we will be more successful." Obviously that is nonsense, but for a number of people, that is the take away message from agile. "Do X and you will be more successful," where X can be test first, pair programming, daily standups or what have you. You then have the manager forcing the team to have standups everyday, its 45 minutes long (Standups are supposed to be short, not more than 15 mins), and naturally everyone just hates it. The result? The engineers hate it, and the manager is disillusioned.

Don't obsess over techniques. If pair programming doesn't work for you, that's perfectly fine. Don't do it. Do what works. Maybe you are having a lot of success with daily standups. Continue to do it. A confession: I don't do pair programming either.

Techniques do not exist in isolation. There are a number of factors that contribute to the success of a technique: the people, the environment, the culture, the management. A technique might work great for Google, but be terrible in your environment. A technique that is terrible for Google might work great for NASA.

So if you are not going to focus on techniques, what do you focus on? I prefer to focus on principles. Being agile is not about writing requirements on index cards or doing test first development. To me, being agile is about valuing people, working collaboratively, improving continuously and delivering consistently.

Now, that is a lot easier said than done. A comment on Steve's post goes like this (the company mentioned is Google):

I worked on a team (at the same company as you) where we were essentially "forced" to use Scrum. I don't think a single engineer on our team found it useful, and I personally found it annoying, but we didn't really have a recourse for evaluation: I gave feedback that I didn't like it, but I'm not sure that everyone else was comfortable doing the same, and there weren't any of these wonderful double blind weekly evals. I also think its results were mis-used. The data that was derived from it (how much our team could accomplish in a week) was tainted and it shouldn't have been turned around and used to make decisions.

If the engineers didn't find it useful, the practices should have been changed. Continuous improvement of the process by the team is a cornerstone of agile. This is a perfect example of following the techniques and ignoring the principles.

Agile is not a set of techniques. It is the principles that matter more than the techniques. Focus on the principles, and do the techniques that work in your environment.

This post is a part of the selected archive.

Stairs

Stairs
Originally uploaded by Siddhi.

Near my office, late at night

Techcrunch on PayPerPost

A year and a half ago, I wrote a post, pointing to this cartoon on corporate blogging. I had said

While its meant to be a bit funny, I can see the day when something like this actually happens.

A couple of days ago, Techcrunch had a post about the controversial PayPerPost, where bloggers are paid to post product reviews and the company can mandate that they be positive. This kind of thing is nothing new, as it happens all the time in mainstream media (what, you though all those magazine articles were unbiased? See this), but it has generated a lot of controversy for 'tainting the unbiased nature of the blogosphere', whatever that means. Check out the comments on the Techcrunch page.

Bug Bash

Bug Bash is a techie comic strip that I've been following for a long time. It's absolutely hilarious, so if you haven't heard of it yet, take a look here.