The Challenge

In his blog, Mark Levison posed a Challenge to Agile Tool Vendors with questions any vendor of a tool supporting agile management methods had to answer, before he would consider to show it to his clients. So here is microTOOL's answer.

History of Agile at microTOOL

My first contact with Agile at microTOOL was in 2001. I was at another company then, where I had introduced XP and microTOOL's MDD solution, objectiF. I was giving a talk about the successfull combination of XP and MDD with objectiF at microTOOL's user conference. Afterwards, I talked with the microTOOL colleages about XP practices. They were just getting into those as well at the time. In 2002, more and more XP practices were integrated into microTOOL's development processes. I joined the company in summer 2002 and by the end of the year we had our full own flavour of Agile established in one of the development teams, called actiF. actiF integrated time-boxed iterations, refactoring, continuous integration etc. and the teams ran at a sustainable pace. I'll never forget a release of objectiF where the team was done two weeks in advance of the planned release date. They were literally flying because of their pride.

Beginning in 2007, we refactored our process to Scrum, to reinvigorate the agile mindset of the company and to make communication easier for new team members, as Scrum became the predominant of agile methods. As of now, all projects at microTOOL are using Scrum, product development projects as well as administrative or marketing projects. As each project and team has their own goals, challenges and, of course, people, they are doing Scrum differently. But: they all have a product owner, a scrum master, time-boxed sprints, a prioritized backlog and potentially shippable increments at the end of every sprint. They do daily Scrums and retrospectives and shape their own processes.

Following, I'll answer Mark's questions for the development team of our Not-only-Agile Project Management Tool, in-Step. It's a management platform for processes in organizations, specialized for, but not limited to, projects. It's available in different flavours, to support agile (Scrum, actiF) as well as more formal processes (V-Model XT, PRINCE2, SPICE). And, of course, all our projects use the in-Step Scrum Edition for the management of their product backlog and sprints.

Our Definition of Done

1. Fully developed according to story definition/communication with PO
2. Independently tested by another team member, tests automated
3. Fully documented for users (online help etc.)
4. Fully integrated into standard setup - no "runs on my machine"

TDD and Unit Testing

As microTOOL is a tool vendor for both MDD and project management tools, and because we have a strong urge to use our own tools in our own projects, the development style in the in-Step team is more model driven than test driven. All classes that directly access or manipulate data in the database are generated from a model, and the generator is very thoroughly tested—automated. In addition, the user command interface of the application has an interface for test execution, these automated acceptance tests are run with every build. For performance tests, there's a special stress test suite and a generator for random test data.

In our “neighbour” project, where the MDD solution objectiF is developed, they went through a major change in architecture this year, where they developed a new rich internet architecture which allows for much easier test development. Just for the latest release of objectiF, that team produced more than 1400 automated unit and acceptance tests which are executed with every build. in-Step will start using this new technology next year, leading to a much better integration of TDD and MDD in the consequence.

Acceptance Testing

After the sprint review, which is attended by all consultants like myself, a group of consultants does acceptance testing of the new sprint version. A good indicator of our product quality is the statistics from our customer help desks. Over the last year, the rate of calls which were caused by software errors was below 10% in every single month.

Releases

Every Sprint (three-weekly at the moment) produces a releasable version of in-Step. As we develop a standard product for 1000s of users, some of which are in companies with a very regulated IT infrastructure, we don't officially release more often than 2-3 times a year. But if a client has a feature request which goes through our development cycle within a few weeks, we can send an earlier release to the client to put this feature into production fast.

Retrospectives

We introduced retrospectives with Scrum in 2007. Since then the team continually learned and shaped their own process. They record their findings and take actions. The in-Step consultants take their turns to facilitate the retrospectives. That way we maintain a strong connection to the development team and hone our coaching skills, which helps us when we're at the clients. You can see the actions tracked on the team room wall in the picture:

Important recent actions were:

1. Pair programming mandatory on all tasks.
2. Stop the line: if one person is stuck, no new task is begun before the problem is solved.
3. More detailed structuring of tasks in the sprint planning

Starting this summer, we initiated release retrospectives where product management, sales and consulting discuss their interactions and bring process improvement from the project to the company level.

Conclusion

Having started the development of standard software solutions for development 25 years ago, microTOOL has learned a lot from the implementation of agile methods. Communication is faster and more effective, within the company and most notably with our clients. Every release of in-Step has a few hundred new requirements added to it, and more than two thirds of those are customer requests. This way, it is ensured that our software stays to be a pragmatic solution for the problems our clients are facing.