A maturity model for front end development?
I was recently asked an interesting question by a potential client:
“How do we know how good we are at UI engineering as an organisation?”
The questioner wanted to know where their existing team stood in comparison to the ‘industry average’. Put on the spot like this, I gave a vague and non-committal answer, probably starting with “Well, that depends”. To be fair on me, this is a hard question. If you remove the ‘UI’ part, it’s not something that the software industry has a consistent answer for.
There are plenty of attempts to measure the effectiveness of software development teams. For example, the Joel Test, now 18 years old (!), provides 12 simple yes/no questions such as ‘Do you fix bugs before writing new code?’. Some of the questions were always a matter of opinion, and others are getting a little dated, but it’s still a popular heuristic, especially in smaller organisations.
The Joel Test is really just a simple form of agile maturity model. These have been a controversial topic ever since agile practices began gaining adoption in larger organisations. The number of agile maturity models might even rival the number of JavaScript frameworks.
On top of this, there are also approximately 10,000 variations on agile team ‘health checks’. These have a slightly different purpose - to help a team focus on areas for potential improvement that are important to them.
And here lies the key difference for me between maturity models and health checks. I don’t think it would be useful to have a single measure of effectiveness for UI engineering across different teams. In fact, it just wouldn’t make any sense.
Externally prescribed models of all kinds make me uneasy just because they are externally prescribed. Despite attempts by some, there is no one accepted way to work as a software team. Just as there is not One True Way of building web applications.
On the other hand, health checks can provide teams with prompts for their own self-improvement. The prompts should reflect what the team considers to be important, their shared beliefs, values and principles in the context of the organisational interests they are working to further. And because these vary between teams, there is no way to compare one team with another.
So, with a bit of l’esprit de l’escalier, my more succinct answer to my prospective client’s question would be “You can’t really compare one team to another because you have different businesses, different audiences and different values. So don’t worry about it. All you can do is to help the team improve over time.”
What values and practices are most important for your team when building user interfaces? How has the team improved on them over time?
All the best,
– Jim
