As a former Systematic employee I was startled to discover that people from Systematic is going to do a presentation on JAOO 2009. Curious to know about their presentation I decided to do an interview with my former Colleagues – Gitte Ottosen and Jan Reher.

What do you do to avoid having a the classical wall between the development team and the test team, where the development team “throws” low quality software at the test team?

We do several things, and we will describe those things in our presentation. First of all, we make sure that there is no wall. Testers are co-located with programmers (or perhaps it is the other way around). Secondly, whenever a programmer finishes a small bit of code, he gives it to the resident tester, who performs preliminary testing of it. If the quality is inadequate, the tester tells that to the developer, who can then fix the code without further ado. So, low quality software gets thrown right back. Bonk. After getting bonked a few times, most programmers learn not to not throw bad software at testers.

This description is a bit imprecise in places. It does not explain what we mean by “finishes”, “a small bit of software”, “preliminary testing”, “quality is inadequate”. Please attend our presentation to learn more.

I know that you also use Lean principles in your software development process. One of the principles of Lean is “eliminate waste”. My experience with CMMI is that some of the things you need to do have no value other than ensuring that you pass your CMMI appraisal and it is therefore hard or even impossible to live up to the “eliminate waste” Lean principle. Is this your experience too?

Simplistically stated, Lean’s question is “what more can we leave out?”, while CMMI’s is “what more should we add?”. In our initial work with CMMI, years ago, we tended to uncritically add more and more activities, reports, checklist and procedures to make sure we had all the requirements of CMMI covered. Value came second. But since then we have been whittling away at that mass, and it is significantly reduced now. Lean principles have helped us a lot here, not the least the “eliminate waste” principle.

A CMMI certification is something you must buy all or nothing of. So yes, we had to implement some process areas which we did not quite see the relevance of. In some places, this has changed.

One of the key principles in SCRUM is that there is only have 3 different roles. CMMI has a lot more roles – Project Manager, Team Leader, Risk Manager, Observation Manager, Architect, Test Manager, Test Designer, etc – just to mention a few. How does this add up?

It adds up nicely. The two sets of roles are in two different name spaces. In both, a role merely means that there is a set of somewhat related tasks that someone must assume responsibility for. So for example, the Observation Manager manages observations (he probably has other roles as well). Someone has to do this, even if you are running pure Scrum, and I believe it is more efficient to assign that responsibility to one person than to merely say that this is the team’s collective responsibility. Scrum is too diffuse on practical matters like this.

And CMMI does not have all these roles. CMMI insists that responsibility is assigned and accepted, not how you organize that. Our particular implementation uses a number of roles.

What are your favorite CMMI process?

I don’t think the question makes sense. My favourites among our implementations of CMMI processes include our development process and test process, which you can hear all about if you attend our presentation. I also find our implementations of document review, causal analysis, and structured decision making to be efficient and useful.

Are there any CMMI processes that you dislike or even hate?

The Product Integration process area seems to me to be designed for organizations and projects that are orders of magnitude larger than us and what we do. We have been struggling to produce an implementation of it that is both compliant and meaningful. We got the former.

Tell us what you like about working at Systematic?

Challenging development work, nice colleagues, reasonable managers, wonderful food, sponsored knowledge networks on a long list of interesting topics, process improvement work, being sent to JAOO to do presentations. And I get paid, too.

What do you see as the biggest caveat when combining CMMI and agile processes?

Good question. The challenge is exactly that: To make it a combination. Bringing both perspectives to the table has enabled us to have a critical approach to both, and not go overboard with either.

Are you going to publish some of your experiences with combining CMMI and agile processes?

We hope so.

Experience the presentation on the Agile in Practice, Tuesday 16:15 – 17:15 (location: Store Sal)