Vidar’s Musings

I attended a session with Mary Poppendieck at NDC today where the topic was trashing in projects. I was a very interesting talk. One of the things that I got out of it, was the notion of churning, which basically is about two things:

• If you have requirements churn, you are specifying requirements too early. Basically, this means that after you write the requirements, the customer changes his or her mind, and the requirements need to be changed before implementation starts.
• If you have test and fix cycles, you are testing too late. In general, testing should be done earlier, and preferably automated

Furthermore, Poppendieck made a few references to classic queuing theory, saying that if the utiliziation of a resource is too high (saturated), the handling time will be lower and result in trashing. Hence, one should no plan for a 100% utilized project resource. The main thing is to optimize on throughput, and not on utilization.

I attended a panel debate at OOPSLA on agile methodologies. A lot of insightful information was given by the panelists (including Alistair Cockburn, Dave Thomas, Jutta Eckstein, Randy Miller, and Mark Striebeck) derived from their experiences in the field.
One question to the panel was on how to introduce agile in a large corporation which relies heavily on the waterfall approach and that was unwilling to change? One argument (from Dave Thomas) was that the development team could start focusing on continuous integration, testing, and perhaps test-driven development. As the code handed over to the QA department would have a higher quality, the role of the QA department decrease, and a more agile model would occur. Jutta Eckstein pointed out that as long as you have no by-in from the management, you will not get the value proposition from agile, but you could still use some of the agile tools.
Another important topic that came up how one could be agile when faced with usability issues (and I think, user interface design). It was pointed out that experience was that user interface development had to be started before the (implementation) iterations. There was some controversy in the panel on this issue, but one point that was made that the iterations should not focus on delivery to the customer, but should focus on end-usage of the system, in which user interface design and usability are important components.
What is the greatest advance in agile practices in the last 5 years? What new things should we teach our students? To this question, Dave Thomas replied that the most important thing is testing; unit testing and acceptancy testing. I very much agree to this, and I feel that we still have a long way to go, especially on acceptancy testing.
All in all, the panel discussion touched on many very interesting topics:

• Everything should go in the backlog (Dave Thomas). Projects tend to keep things out of the backlog, making them lose overview and large variations in velocity. Things like vacations and defect stories should go in the backlog. Management should have a backlog, too, consisting of things like risks.
• Focus more on deliverables (Alistair Cockburn). Focus on deliverables are key to agile processes, not iteration planning, iterations, and velocity. If you have the three latter without the focus on the former, you are not going agile.
• There is no ideal iteration length. Iteration length varies from project to project. There have been teams (advanced!) that focus on continuous delivery with no iterations. The most important is to have short feedback loops.
• Pair programming (Dave Thomas). Pair programming is four eyes looking at the code at some time, it does not mean two hands holding the mouse

Last few weeks I’ve been back on the horse doing Notes/Domino programming
after been working on various J2EE-projects for a couple of years. And I have to
say that Notes/Domino still amazes me. Why? Swift development. Swift deployment.
Swift change. In my opinion, Notes/Domino fits particularly well when you are
doing prototyping: creating an initial version (or Proof of Concept) of your
application is very quick, allowing to present an initial version to your users
in order to collect feedback and change requests. Furthermore, the
Notes/Domino’s unstructured data model allows your application to be easily
changed during its entire life cycle. Being able to change is what agility is
all about. Put that in your pipe and smoke it.

On the downside, automated unit testing of a Notes/Domino application is very
difficult because of the lack of tool support. Because of this, development
methodology like Test Driven Development (which I am a big believer in) and XP
is hard to do.