About two years ago I read Quality Software Management Volume 2 – First-order measurement from Jerry Weinberg. In it, he explains the differences between first-order and second-order measurements. The latter is a replacement measurement. Instead of measuring the thing, we measure something that we substitute for the thing that we are measuring. For example, measuring code coverage usually is a second-order measurement for test quality. It does not really measure the quality of the underlying tests, since you don’t know how many assertions lie behind the covered lines of code. In the same book, Weinberg also provides the concept of zero-order measurements for projects. A few months ago I was surprised that these seem to be focused on traditional projects, rather than agile ones. Since then I decided to come up with zero-order measurements for agile projects. So, here are some of the things I look for when entering a new client or company.

How much communication is not taken place due to team organization?

Team organization consists of how the teams are cut if you have multiple ones, how far apart team members sit, and how far they have to walk in order to get meaningful answers from other team members on the same team, on another team, or from their product owner or product champion. More often than not sitting people far apart leads to sub-optimizing, distrust, and silo-behavior. Things might get worse when you hire contractor teams from different companies, and ask them to work together. I saw teams sitting in the same physical room, but when it comes to information exchange, even ten meters become an impediment.

Can anybody on the project team deliver me a holistic picture of the problem that their application tries to solve for the business?

Agile software development takes into account the business problem. If I can merely get an overview of the piece of product a particular developer is working on in technical terms, I sense that the underlying is not understood well enough. If the problem is not understood, how can we be certain that the work we are doing is not a waste of time? Most of the time, I have to introduce ATDD, Specification by Example, and a holistic view on the business side of the program to fix that.

What’s the lead time between introducing a bug in the system and finding it?

Bugs are waste. The later we find them, the more waste we have in our process. The shorter we can keep the baseline between introducing a bug in the source code, and finding that bug with some automated checks or manual exploratory tests, the fewer waste we deal with in our process. Usually I dive deeply into the continuous integration system. How many unit tests are there? How long does the build take? How many external dependencies which the team might not have understood are there? Does the team use static code analysis? Pair programming? These all give some clues to the degree of technical excellence in the team.

How defensive act people on the project when I start asking questions?

I am quite aware that I can be very nit-picky and offensive at times. However, when I sense that people are overly defensive to my questions, I sense that the whole environment might be based on fear and mistrust rather than a trustful environment where people on the project can contribute meaningfully. It’s hard to act openly in such an environment. So I know, that my highest priority might be to shift the thinking from a Theory X to a Theory Y mindset.

What are the current experiments from the last retrospectives? Are they followed up on?

In order to continually improve, agile methodologies put retrospectives in place. As many thoughtleaders I think that regular retrospectives are the most powerful tool in any agile implementation – when done well. If it’s just another boring meeting with some boring or dreaded outcome, then there is probably another underlying problem that will keep the team from improving. In this situation we should fix the retrospectives first. Only then will emergent and continuous improvements start to step in.

What’s the state of the informative workspace?

Does the team have a physical board that invites team member to collaborate rather than manage and hide information in an electronic tool? How open is the team to provide information regarding their current state in the iteration? Regarding their state for the next release? How about the impediments and bugs fed back from production? The informative workspace should provide not only positive but also negative information, and team members should be open to answer questions regarding the state of the project, even and especially when there are clear problems i.e. in their velocity.

How empowered is the product champion, product owner or on-site customer?

Especially in hierarchically driven environment like most enterprises that I have seen, there are product owner in their so-called Scrum implementation that are not empowered, driven by the politics of the enterprise solely. That might mean that they simply work nine to five on the backlogs that their bosses provided them. That is not real empowerment, and the whole project will suffer from it long-term. When I sense a weak or poorly empowered product owner, I either try to fix the situation by talking to the upper boss, or by working towards replacing the product owner with the real product owner – thereby making the boss of all the ten product owner realizing that he really cannot do all the work on his or her own. Only when the product owner does make critical decisions regarding priorities and business value, is the team able to work effectively. Otherwise it will suffer from fighting the cases for the product owner or become demotivated by the ever-changing priorities in the different business areas.

These are my most immediate zero-order measurements when entering a new team or company. I think there are more, but these are probably the most important ones to start with. What else do you look for?