When joining a new team, ask to see evidence of their tests and customer interactions, and use the way they respond as a quick maturity assessment.
One of the hardest points of working with any new team, either as a coach, or as a manager, is to understand their current level of maturity. You need to do this quickly to be able to calibrate the your interaction and ambition for improvement, as pitching the wrong tone to the team will damage your relationship from the start. A high maturity team can feel that you are dragging them backwards, while a low maturity team will see you as a know-all expert that lacks empathy.
In this circumstance, the team’s own view will often be biased, either self-deluded via the Dunning-Kruger effect, or wishing to give you a view that may not be the truth. This will be especially true if the team themselves have not asked for your help, but you have been brought in by some level of management. Until you have a better understanding of them, it will be hard to assess whether and to what extent these biases exist.
So you need a quick (which is more important than high precision) way of understanding where on the learning and maturity journey they are, and whether you need to start addressing fundamentals.
I have a simple, two part sniff test that I use, which has shown strong fidelity as a predictor of team core competence.
Can you please show me your tests?
The point of this is not to audit the tests, assess test coverage or any other metric. At this point, asking this hits a number of points instead:
- Whether tests exist in any standardised, repeatable way; fairly important to avoid regression problems and an absolute prerequisite for any kind of improvement in them.
- What level of thoroughness has gone into them – a repository with a few sketchy high level tests is a very different thing from a comprehensive library, and it’s obvious within a few seconds.
- Most importantly: the team’s attitude towards testing. Whether they take quality seriously. Whether responsibility is devolved off onto a few dedicated testers. Whether the team is actively engaged with the process
You can get a lot of information simply from the tone of response. If the team can point you to some kind of repository or visual management almost instantly with a
It’s over there. Fill your boots. Come back with any questions relaxed tone (or even an impatient one: an unspoken
you idiot is a good thing!) then that’s a very good sign. It means they actually have some consistent, thought through ways of working and have a way of transmitting them to new joiners.
If, on the other hand, you are repeatedly deflected with something like
Yeah, we have all that but not a simple pointer to where it is, then at best, it’s in someone’s head and we’re operating on the basis of rumour.
Note that I don’t care how it’s stored. Github, Sharepoint, fileserver, Cucumber, RTC, whiteboard: it’s all fine. And re whiteboard, even if it’s not already on a board, as long as any member of the team can describe it to me and sketch it, with some consistency between team members, that’s fine too.
Can you please invite me to your stakeholder demoes?
This doesn’t mean that you are imposing Scrum-like ceremonies on the team, which will be particularly problematic if the reality is that they have evolved out of it. It isn’t insisting on this as part of a planning cadence for the Kanbanistas.
What it is is a fairly good indicator of the team’s commitment to transparency and to taking feedback from a wider group of stakeholders than the product owner. Is the team willing to honestly show where they’ve got to every so often; say every couple of weeks or so. This helps reset the clock on expectations, avoiding an ever widening divergence, and gives a huge amount of confidence in those stakeholders that when the team says “X% done” then that’s reality, measured in working (including tested) software delivery, where most of the schedule risk is located.
What you’re looking for here ideally is a pointer to an existing regular and frequent cadence —
Every other Friday at 10, in the Forest meeting room. Next one is this week — with no special arrangements made for you. And again, a tone of mild annoyance is a healthy sign.
Worrying responses include:
- We don’t want to tie up the team for half a day when we could be producing real value
- Our stakeholders aren’t interested in story level detail (it’s very easy for a team to pitch a demo in a way that actively disengages non-technical stakeholders)
- It’s an internal meeting where the team demoes to the Product Owner and we don’t want to disrupt the delicate team mood with judgemental outsiders (my view: the PO should be far more engaged, already be fully aware of the progress and often be the one demoing to other stakeholders. This could also be an indicator of far bigger team dynamics problems)
It’s also useful to observe the tone in the demo. Is it a simple one way performance? Or is it a real two way conversation about whether this meets expectations, is it going in the right direction and does it spark new ideas?
Feel free to add further examples in the comments.
Carrying out this assessment has proven effective for me, and echoes Scott Ambler’s acid test:
Show me your tests. Introduce me to your stakeholders. If you can’t, you’re probably not Agile.
This is simply a quick diagnostic assessment, designed for speed rather than precision. It will not tell you everything, and is only a first pass. You should maintain an open mind, ready to be proven wrong in this, always receptive to new evidence, confirmatory or otherwise.
The Two Sniff Maturity Test by Martin Burns is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.