Agile Boston Open Space 2010

I attended Agile Boston Open Space 2010 (http://www.newtechusa.com/agileboston/events/AgileBostonOpen2010.asp) today. The event was at the Microsoft Building in Waltham, Boston. Of the many conferences that I have attended, I have no hesitation in saying this gave me the most value for money. Here's why:

1. Convenience: It was in my backyard - just a couple of miles from my workspot. It certainly helped that while the title had Boston in it, it wasn't in Boston. It was in Waltham (you can tell I don't like going to Boston).
2. Cost: Just $29. And that included breakfast and food. And yes - there was vegetarian food. It was just a wrap, but it was tasty. This is not a trivial matter. I'm a vegetarian and I have often found that some conferences that charge heavy fees don't pay much attention to the vegetarian fare. These people were thoughtful.
3. I got to hear Ken Schwaber for an hour.
4. I got to network with a number of smart people who were willing to teach, learn and share. I learn't about a number of misconceptions about Scrum. Just because it is highly adaptive doesn't mean that you shouldn't do some of the process that truly added value in waterfall. People didn't say that in so many words, but that was the gist of what I got from it. If it's valuable, keep it.
5. I learn't about "Open Space Technology" (http://www.openspaceworld.com/brief_history.htm) - a fabulous way to organize meetings very productively.

I think it was a day very well spent.

TDD is a Misnomer

We all know, at least those of us in the software community, that TDD stands for "Test Driven Development". That's a huge misnomer. Simply because TDD is much more than about tests. Yes - tests are a core part of TDD. But TDD is also about the following:

1. It's a way to capture behavior (think requirements)
2. It's a design tool (If it's easy to test, the resulting code will be elegant)
3. It captures high level documentation (think tools like agiledox)
4. It's a regression test suite.

The word "tests" in it leads to all kinds of confusion among TDD practitioners. What do I test? How do I test? What do I test first?

Happily, we now have Behavior Driven Development - which simply removes the confusion around TDD while taking it to a whole new level.

Yes - I'm beginning to like BDD a lot. It's a better TDD and more.

ScrumBut is not that bad

ScrumBut is a practice where teams implement partial apsects of Scrum. As in - "We did Scrum BUT we did not have daily standups". Scrum pracitioners look down on teams that practice ScrumBut and perhaps for good reason. As they argue, when a team does not implement a prescribed practice in Scrum, the team is allowing for a problem to fester.

For example, if a team finds that a Product Manager is unable/unwilling to participate in an agile team as a "Product Owner", using ScrumBut, the Business System Analyst may take on that role. The "Product Owner" is one of three key roles that Scrum prescribes. Not having the real Product Owner play that role is a violation of Scrum. In reality, there might be organizational hurdles, as in highly matrixed organizations, that prevent the Product Manager from participating in agile teams. Should the agile team give up their move towards adopting agile methodologies?

Perhaps not. ScrumBut is an excellent way to get started with agile methodologies. Agreed that it is not likely to give the same amount of return that Scrum promises. However, it is an incremental way to adopting Scrum. It is likely to result in less of a culture shock to new teams and may provide the breathing space to winning hearts and minds.

The end goal though must be to eliminate the "But" and have just "Scrum". Assuming of course, Scrum is what you want for an agile methodology.