Hi everyone, this is my first post so please be kind!
Does anyone have experience of implementing the Test Maturity Model (TMMi)? I’m using this as a means of providing structure as to how we grow the capability of our team but wondered if any other users had practical experience of doing this and would be willing to share?
Brilliant question Charlotte. Me neither, whenever I hear a new acronym I smell a rent seeker somehow. Is TMM aligned with CMM Capability Maturity Model - Wikipedia or a actual part of it?
Hi, I am actually a TMMi Assessor, although I think my certification has probably expired, which tells you something in itself. I will formulate a more complete answer for you when I have time, but short answer:
It is great as a framework, especially in a V-model/W-fall environment, but if done strictly can be somewhat overkill. If you use it in a flexible way it can be very valuable.
CMMi & TMMi are similar in structure but have different objectives. CMMi is the whole SDLC with very little mention of Testing or Quality. TMMi focuses entirely on the Testing processes with little reference to other aspects that affect quality, or in fact how to build quality into the SDLC and the Product - just how to do the Testing Process.
I have not used it myself, but I think its useful as an exercise to see where you would place your team in relation to it and might give inspiration into what things you could outline to do in the future that you would not have otherwise considered.
Consider the reasons for using TMMi - are you in where CMMi is a business requirement? Or are you more looking for a model to support capabilities? The TMMi model is very fixed in it’s understatement of “maturity” and predictability - perhaps your targets and mission is something else? An alternative good be the Accelerate book from 2018 on high-performing teams.
I personally like Janet Gregory’s QPAM . It’s not a maturity model but more a way of assessing what’s in place now and the opportunities to improve. It’s essentially for agile/hybrid environments.
I also really like TMAP and often refer to my Quality for DevOps Teams book. It is a far more flexible and more useful direction for improving the quality of testing as well as the testing processes themselves.
TMMi has been around for a long time and, as has been already said, is somewhat rigid if implemented as per the instructions. It is a very old-school V-Model/W-fall in its criteria. That said it can be used more loosely in a flexible way to give suggestions for what you may want to have in place in your testing framework. If your environment is very old-school and isn’t going to change anytime soon, then it is ideal. Just don’t take it as dogma.
The main things I don’t like about TMMi are
You have to achieve all of the criteria within a level fully to be awarded that level. Not everybody needs or can apply everything within the model.
Being certified at a specific level is used as a badge of how good you are at testing when it only indicates that you have certain aspects of your testing processes in place, not how well you do it.
Getting and maintaining certification is a whole industry in itself & not cheap. Continuous & Step improvement should be within the agency of the teams themselves, sometimes assisted by outside views where necessary/appropriate.
These are purely my opinions and more than happy to discuss
No idea about TMMi. I don’t even hear about this one anymore. The last time it was mentioned around where I work was 7 years ago - a bit of a temporary hype.
I found this one about maturity that I feel it’s useful:
Good to see we did get that ball rolling. I recall encountering CMM a long time ago, and thinking how bad it was for my team, but also how good it was for some teams (in a V model world.) Today for me QA as a role bleeds into those gaps in the CMM, the “quality” and “happiness” gaps mostly. CMM seemed to only create shareholder or stakeholder happiness.
CMM I saw, as bad for teams when it comes to release time, because it still fails to give the team confidence that they can release and go on holiday secure in knowing there will be no fires, CMM gives you a working certified fire hose system you see, but teams don’t want to have to use disaster recovery plans, they prefer to build new, at a time that suits them best. You cannot guard against unknown disaster sources Y2K pretty much slew that beast.
Wow, thanks everyone for sharing your thoughts and experiences and also links to the HuibSchoots&JoepSchuurkes context driven maturity approach. I’m keen to take this to our next team meeting and apply some of the criteria to existing projects we are supporting to see where the strengths and weaknesses are and how we may address them
I’ve also reviewed this recently and imagine it could be very helpful when working in an agile team to deliver iteratively to get all members to take ownership of quality