In the first article of this series, Micro PDCA: Improve Your Improvement
, I introduced the Micro PDCA concept and talked about how we use it in our sprint plannings at my company. In this article, I'll show a way to apply PDCA in subcontexts of a sprint cycle: the sprint itself, where we do our development, and the sprint review, where we check if everything went well.
Do: Test-driven development
We've done our sprint planning and it's time to code some features. How do we begin? We plan
A lot of people know what TDD stands for, but they're still unable to see how it differs from simple unit tests. And the difference is that TDD brings the PDCA concept to the development team when it says that we should test first and develop later.
Plan it first and then do it. If your test doesn't pass after you write your code, just fix it
Can you see the PDCA cycle hidden in the sentences above? It's there, but sometimes we are unable to see it. And believe me, the mere fact that you wrote your tests before you developed your features makes a huge difference in your code and product quality. After all, if you don't plan
what you're going to do
, how can you check
to see if it's OK or if you need to take some act
Let's suppose we're developing a simple calculator that divides one number by another. Although the calculator is simple, I'll use the Grails Framework
and the Spock Test Framework
to make it closer to a real-life example. The Spock Test Framework is also a nice option for Java applications because it makes unit tests more readable and less cumbersome.
Planning: It's time to write unit tests.
We all know how to divide one number by another, so this test is an easy one. Also, the Spock Test Framework makes the test a lot more readable and self-explanatory:
In more complex situations, your team might have a hard time writing the unit tests before the code at first. But it pays off and they'll get used to it pretty fast.
OK, the plan is ready. Let's move forward.
Doing: Now you do what you already know.
The greatest thing about Test Driven Development or Behavior Driven Development is the way the production code comes out easy and clean. That's because bad code is usually untestable. Have you ever read Clean Code
, by Robert C. Martin
? It's a must-read for every developer, and TDD/BDD helps us smoothly achieve what Martin teaches.
Here's the code:
But we can't divide any number by zero. Let's return "infinite" when that happens and move forward.
Checking: Is your code working? Is it clean, pretty, and awesome?
The first thing to check is a little obvious: Are the tests passing?
OK, what about our code coverage?
Hmm . . . not so nice. We forgot to include the "division by zero" case in our tests, and now we have a part of our code that isn't being tested. But we'll come back to that in the act
phase. There are others metrics that are worth a look, such as lines per method, cyclomatic complexity
, and many others.
Acting: Did we miss something? Let's fix it.
Our tests passed, so there's no need to change our production code. But we know that we can improve our code coverage by adding one more test case to our unit tests. And that's something I really like in Spock: You can write a new unit test or just insert a new set of data at the end of your existing one.
But I'll let you decide which one is better and do this step on your own. This simple code I wrote is waiting for you at github
if you feel like trying.
Micro PDCA: Checking the "C"
It's time to check
if we did what was planned and everything went fine. We had a plan and followed it, so it's pretty easy to check, right? The thing is, we might get overconfident and throw our well-done job away in just a few seconds here.
If you're using Scrum, this step is well defined and called the sprint review. By now you probably figured out that Scrum is a cooler way to use PDCA in complex projects, right? So let's plan our check
phase, aka the sprint review.
Plan? Check. What do we need to review our work?
What do we need to check to see if we succeeded? Results. But we need a little more than that: We need a way to show them to stakeholders. So before a sprint review, you need to prepare an environment in which your results can be seen in a flawless way. I've seen a lot of sprint reviews that caused an awful impression on stakeholders just because "there was no time to prepare a demonstration." Nobody will be impressed by the application your team developed if it only runs on your machines.
It is also essential to learn more about the environment where you'll be showing your work. A long time ago I worked on a nice Web application that made every team member proud. Although the layout looked gorgeous on our wide-screen laptops, however, that didn't win us any points when the application was barely usable when presented to our stakeholders on a 4:3 projector.
Everybody ready to check? Check! How do we conduct the meeting?
First thing: Make the previously established plan visible. Write it on a board and choose the order in which the features will be shown. This is a great approach because it helps everybody keep their focus on what must be accomplished in this meeting, and it also serves as a progress indicator.
Listen to comments and suggestions about what was done and take notes, but beware of subject changes. Sprint reviews are meetings in which people will eventually try to plan something or start to brainstorm. So you might want to ask everybody to write down their thoughts and save them for the next sprint planning session.
Everything checked? Check! Is it over yet?
If you've shown everything you did, it is almost
over. You can also check if the other side did what they were supposed to do. Were there any user stories that needed more details? Any internal research that needs to be done to deliver crucial information to your team in the next sprint planning?
Sometimes we forget that while we're developing, our customers are also working hard on something related to the project. And if we forget to give them time to show us their work, we're not being collaborative. That might close some doors we'd like to keep open.
Something to act on? Check! But what?
The sprint review is a meeting where people -- specially the stakeholders -- come with a lot of expectations. And the higher we fly, the harder we fall. It's important to talk to everyone in the room to make sure they don't leave the meeting with a pessimistic outlook of the project.
If somehow you couldn't show some part of the work your team did, write down the reasons why. You can't risk forgetting it until the sprint retrospective, which will be the main theme of the next and final article.
The author wishes to offer special thanks to the talented Rebeca Zocratto for the images in this article.