coded ruminations

Erich Gamma spoke on Eclipse and transitioning it from closed to open source. One if the initial concerns was that competitors would see the bugs in the application. However, Erich believes that there is an upside to this, because there is nothing more motivating than to have your competition pointing out how bad Eclipse is because of this or that bug. He mentions what he calls the “Village Effect” where the community is more open because the communication lines are out in the open (everyone knows each other’s business). However, I wonder if the details sometimes get lost in the fire-hose of communication? The Eclipse project threw away the upfront planning that they were doing before Eclipse became open source, in favor of continuous transparent planning. To do this they move items from proposed to committed to deferred items. There is an initial release plan where those items are identified, but the lists don’t stay static as you go through the milestone releases (M1, M2). They have tried different release lengths, and settled on 6 week releases, this was determined through trial and error. To do component integration they have daily component use where component teams are encouraged to consume their own component, weekly component integration where the project team consumes the component, and then 6 week build cycle where the community is consuming it. In the end game they test for one to two days, and then flip to the developer role and fix for a couple of days. The End Game phase is not time boxed. They have no dedicated testers, as roles on the team are shared. To get end game conversions they ramp up process rules (multiple reviewers, multiple approvers), which will slow down the fix rate (less bugs are being found and fixed over time) but increase the quality (I don’t really understand if this is something that just happens, or if this is something they are trying to achieve).

They do component centric development, and to him the interesting thing about this is proof that you can scale up agile development techniques (throughout this talk he assumes that everyone at the conference is sold on Agile, this interesting. He seems to equate agile with continuous integration, planning, design, development, and testing cross-functional teams - he also tends to use the word continuous over agile)).

Jazz: joint project between IBM Rational and IBM Research to build a scalable, extensible team collaboration platform for seamlessly integrating tasks across the development cycle. The approach that they used was pain point centric. Software development should be fun and enjoyable. They wanted to eliminate the pain points (slide with a short list of common development pain points). One of the most interesting pain points to me was reconstructing the state of a failed build .. in general some of this build focused .. and also interesting is that Maven seems to address several of the pain points.

First they thought maybe there is a silver bullet that we can apply (kind of like adding refactoring to IDE tools… one thing eliminates a lot of pain). Take a look a the components:

-Requirements,
-Source Control
-Work Items,
-Builds,
-Reports,
-Process,
-Repository,

They have a closed source stack: WebSphere DB2, and an opensource stack tomcat, derby.

Jazz themes: team first, process awareness, and pervasive transparency (people can see what is going on in the project). Unfortunately the server is down to illustrate jazz, (which is developed using jazz: eat your own dog food).

Team First: the tool should know about the team. You also want to know what is going on with the team, and who is present (chat), and rss streams to see what happened in a team (team information). Each team has its own build (track an rss inbox) which tells you what happened in a team.

Lesson in scaling agility: at first everyone lived in the same build. There was no isolation and each team was swimming in a big soup. The tension is between sharing (lets you know what is broken) and isolation (lets you progress). We really want both. So the next step was to have component center development. You can have a high velocity in your component, and slow down the moment you reach the API. However, this is only a good architectural level, what we want is team-aware tooling: teams own components, tool support for collaborating on components, tools approach to improve a teams effectiveness collaborating on components. What you want is collaboration between components. For Jazz they do this by having a Team of Teams, and then individual teams, where each item has its own build, and team events, with the base teams feeding in to the parent team.

Process Awareness: people and their interactions are key, tools should support he team interaction. Each team owns its own process, and each team is different (self organizing) so you need to support teams that tweak process. The process can control and govern and control how the tool behaves, and must be highly tweakable. But which process? The process is context sensitive: i.e. process depends on development line: maintenance vs. next release. Process is context sensitive also to the development phase and once again to the team, since each team is different.

Process control points: define workflows, enhancements change requests etc. The most interesting process is advisors: advise how certain things should be executed. This allows hooks into interesting points of team interaction: such as submitting a change advises that there should be a code review. So the quick fix initiates a code review process. How do you evolve the processes? What they learned is you don’t want to evolve them top down, but rather you want to promote them bottom up, to be adopted by the entire team upon acceptance. (process customization is specified in XML? or is there a front end to that XML file I assume?). The framework leverages EPF (Eclipse process Framework) to help people define their processes, and it includes lots of examples.

Pervasive Transparency: transparency in: plans, development (project health, linking between project artifacts (which test failed linked to component), end game (done), and process.

I went to Scrum training not too long ago. For me the goal was: how do I package Agile so that I can sell it to companies that are not doing Agile. While attending NFJS today I ran into David Hussman who pointed me to a thread where, among other things, Scrum is compared to XP. The thread changes as you move towards the present, becoming critical of the direction that Scrum is moving, or perhaps its particular “brand” of Agile in general.

In the thread there is also a link to a blog entry from Tobias Mayer. David also attended the same Scrum event I attended. Soon after I ran into him in Chicago and he told me that he left the training event after the first day. David said he thought that … well he says it best himself. To be very honest: at the time David told me this I was still on a Ken Schwaber high. I lacked the ability to think critically about anything David was telling me that day. Today though is a different day, not to mention 4 months later.

Today I think David has a point, and that the thing that people are identifying in the thread David pointed me to is a distinct smell: Selling Agile. To sell a product you need to define it and package it. Maybe Agile should not be defined to the degree that it can be sold. Cultures are too different, experiences too varied, and the problems being solved are often disparate. The changes that Tobias suggests are pragmatic and reasonable, but they don’t fit the package that Scrum comes wrapped in. How ironic is it that any Agile approach has rigidity that does not allow you to refactor the approach itself?

I realize now that there is no magic way to sell Agile so that it can succeed in a non Agile environment. If you want to adopt Agile there are plenty of references that allow you to start using it. The use of Agile must be adopted using an iterative incremental approach - a nimble approach - an Agile approach. Agile is not to be sold, it is to be used.