Inspection is not a high-tech concept, it surrounds us.
Inspection is acceptance test. In fact, a lot of things you even don’t realize that’s the acceptance test, such as:
Racing, the winner is the first person who touches the finishing line. How can we do the acceptance test? We set up a physical rope across the finish area, the runner who touches the rope is the winner.
High jump, the winner is the person who has the highest jump. How can we do the acceptance test? We set up a cross-bar, the jumper who drop the bar will fail.
Imagine this situation, a group of people is racing, they don’t know what is “win”, there is no finish line also. While another group of people is jumping, but there is no cross-bar. And both the two group is excited and do their best.
Is it reasonable? No, That is ridiculous.
Question: if no inspection or acceptance test, why do you expect every team member do their best?
Inspection, not only the must-have but also need to be clarified to every team members.
From the project point of view, we use ATDD for inspection.
ATDD refers to Acceptance Test Driven Development. Maybe you knew TDD (Test Driven Development), and you have a question about the difference between them. Here is the answer, we add a word “acceptance” to emphasize this is an acceptance criterion, and TDD is just a technical method to the purpose.
About ATDD, I can assert that the only purpose of each development activity is to pass the acceptance criteria. That means before you start coding, you must think about how to test. In another word, to be a developer, if you couldn’t figure out how to test one feature automatically, you probably don’t know how to develop the feature either. Then stop coding, and ask BA for the requirement again.
Now, you know what is ATDD and why ATDD. There are two ways for ATDD, code review, and Retro. You may have a question about why these two uncorrelated activities are mentioned together. Think twice, the goal of these two actions are same. They all look back to find problems and correct them in the next iteration. The only difference is code review for the developer, Retro meeting for the whole team.
Besides the two activities, there are four things more specific: kick-off meeting, sign-off, showcase, and CI.
A. kick-off meeting, this meeting happens at the beginning of each iteration, in this meeting BA will explain each user story, the developer asks questions about the requirement and PM clarify the goal of this iteration. All team members align both requirements, goals, schedule, and velocity with each other.
B. Sign-off, at the end of each iteration, all user stories need to sign off by BA. BA has the authority to accept the work or not.
C. Showcase meeting, after BA sign off, the team will showcase to the client and get feed back from them.
D. CI, it refers to Continuous Integration, it’s a technical practice. CI assure each commit from developers will not break the build. CI needs TDD to do the test automatically.
There are some other things about the inspection I want to mention: Story card & Planning Wall.
In the past, the requirement was “hidden” in a deep folder of your computer, and project plan was a beautiful Gantt chart in that folder. But it always has the same problem: when the client changed their plan and requirements, everything needs to change and there will be a long changing process.
That will be a nightmare of waterfall management. In the agile world, we have user stories to describe the requirements with acceptance criteria in the same card. Project plan “document” is a physical wall with full of the user stories cards on it. This is a living document, big enough, clear enough and flexible enough.
At last, let’s talk about Velocity Estimation. I must say, the hardest inspection in the development team is the velocity of the team.
When we sell products, the client always asks the price. A computer has the price from hundreds to thousands according to the different hardware; A house has a quote base on the sq ft;
But how to make a quote for an IT project? We all know that the cost of an IT project is developers. So the question becomes to how to measure the team velocity.
It’s hard. Sometimes, even the developer doesn’t know his capability, let along the project manager.
In the agile world, we use story points to measure the team velocity. At the end of each iteration, the team should evaluate velocity again and compare with the historical data, the team will have a more precise evaluation. (Velocity estimation is another big topic, it worth to talk about in a new article).
Now, you understand the second pole of Agile: Inspection.