Thanks to my good friend Deborah Hartmann Preuss for showing me this great tool: Retr-O-Mat – Inspiration (and Plans) for Agile Retrospectives. It’s a great way of generating a plan for your retrospective if you’re feeling a lack of inspiration! Includes all five stages of a retrospective: set the stage, gather data, generate insights, decide what to do, and close the retrospective.
Over the past six months we have been working hard on launching a new product: The Scrum Team Assessment. This tool delivers to you a valuable report full of practical advice on how your team can get better at Scrum… and deliver better results! It’s like an automated Scrum coach. All your team members will fill in a comprehensive survey, we collect the results, generate a report – and then we personally review it – and send it back to you.
For more information, please visit our Scrum Team Assessment site.
Scrum is an Agile process framework that is optimized for product development. The rules of Scrum are fine-tuned after decades of use to help product development teams become hyper-productive and to maximize business value. If you use Scrum for product development, then you are applying it to the right problem. If you use Scrum for some other type of work (e.g. general project management) then you are mis-applying Scrum and it probably won’t give you the ideal results. Scrum is not simply a collection of best practices. Therefore, if you are using Scrum by picking and choosing some of its pieces, it is likely that you are using a sub-optimal approach to product development. In this way, Scrum is like a tool rather than a toolbox with many tools. When you take a hammer out of a toolbox, you don’t pull the head off and start pounding nails without the handle. Likewise, if you only use some parts of Scrum, you are missing the benefits of using Scrum as a tool. As a Scrum Team Member, you should know the purpose of Scrum and be aware of applying it correctly to the right problems.
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.
For the last 3 months I have been lucky to work with tools and in an environment that is agile. My job requires lots of small projects and tasks and my job title is clear but my work is every changing. I like new challenges and creative tasks.
Recently our small team has been using http://cardmeeting.com/ an online tool to add ideas, set up tasks, and keep track of what the whole is doing and what still needs to be done.
I am looking for more tools to make our agile practices more streamlined and efficient. Any suggestions or ideas?