Coaches for Agile teams and organizations is a growing profession. I’ve been coaching for a long time, and I’ve used/invented/learned-about many different techniques or interventions for coaching in the context of Agile teams. I have recently started a Wiki to capture some of this information. (Originally, I was hoping to write a book, but I don’t have the time to do it on my own or even to coordinate a multi-author effort.) This is an open invitation to participate in the wiki. I won’t make it fully open (like wikipedia), instead, it will be by invitation. Connect with me on LinkedIn and mention you would like to contribute, and I will set you up with an account… and then you can go nuts 🙂 If there end up being several contributors, I’ll make a block on the front page for links to contributors and/or their organizations.
This post is a little geeky and technical and product-related for AgileAdvice, and is a shameless self-promotion. Nevertheless, since testability, test-driven-development, and incremental design are non-exclusive sub-topics of Agile, I though I’d report this here anyway.
Many developers use the Dependency Injection and Inversion of Control (IoC) patterns through such IoC containers as Spring, Hivemind, Picocontainer, and others. They have all sorts of benefits to testability, flexibility, etc. that I won’t repeat here, but can be read about here, here, and here. A great summary of the history of “IoC” can be found here. J2ME developers, however, especially those on limited devices that use the CLDC configuration of J2ME, cannot use the substantial number of IoC/DI containers out there, because they nearly all rely on reflection. These also often make use of APIs not present in the CLDC – APIs which could not easily be added. Lastly there’s a tendency among developers of “embedded software” to be very suspicious of complexity.
In working out some examples of DI as part of a testability workshop at one of my clients, I whipped up a quick DI container, and being the freak that I am, hardened it until it was suitable for production, because I hate half-finished products. So allow me to introduce the Israfil Micro Container. (That is, the Container from the Israfil Micro project). As I mention in the docs, “FemtoContainer” just was too ridiculous, and this container is smaller than pico-container. The project is BSD licensed, and hosted on googlecode, so source is freely available and there’s an issue/feature tracker, yadda yadda.
Essentially I believe that people working on cellphones and set-top boxes shouldn’t be constrained out of some basic software design approaches – you just have to bend the design approach to fit the environment. So hopefully this is of use to more than one of my clients. It currently supports an auto-wiring registration, delayed object creation (until first need), and forthcoming are some basic lifecycle support, and a few other nicities. It does not use reflection (you use a little adapter for object creation instead), and performs quicker than pico-container. Low, low overhead. It’s also less than 10 classes and interfaces (including the two classes in the util project). It’s built with Maven2, so you can use it in any Maven2-built project with ease, but of course you can always also just download the jar (and the required util jar too). Enjoy…
P.S. There are a few other bits on googlecode that I’m working on in the micro-zone. Some minimalist backports of some of java.lang.concurrency (just the locks), as well as some of the java.util.Collections stuff. Not finished, but also part of the googlecode project.
Mike Cohn has written an excellent article that covers a number of different options that can be taken when someone in an organization desires to implement an agile method.Â These Patterns of Agile Adoptions are described as three sets of contrasting options:
- Start Small vs. Go All In
- Technical Practices First vs. Iterations First
- Stealth Mode vs. Public Display