Micro PDCA: Improve Your Improvement

17 May 2013

Mário Melo
Facta TI

The concern about continuous improvement has been a constant at Facta TI since the company's inception. This concern made some practices emerge in a natural way, and they quietly became part of our days. In fact, they became so natural to us that sometimes we don't even notice their existence.

However, if we start letting these natural practices go unnoticed, we run the serious risk of losing them. In order to avoid this risk, I decided to write about these practices — and I even gave them a nice name: Micro PDCAs.

The PDCA and Scrum

Scrum is an Agile method we use daily, and that makes explicit the meaning of each letter of PDCA. It provides small cycles where the development team plans its activities, does its job, checks if the previously planned expectations were met, and then acts by analyzing what went well and what didn't in the last cycle (sprint) in order to improve and become a better team in the next cycle.

Sounds simple, and it is: The sooner we detect a problem, the weaker its impact is.

We can also use the PDCA main idea inside each of its own steps. This might seem a little scary and complex at first, but trust me, it's plain and simple. I'll describe what we do in each one of the PDCA steps. This way we can dive deeper into what we've been doing to improve each step (and avoid writing a single giant article, by taking them one at a time).

Planning the "P"

So, how do you plan a planning meeting?

This might seem a little bit unnecessary, but it pays off. It's not about chronograms and Gantt charts; it's about what must come out of the meeting. Just follow these four simple steps and you're good to go:

Plan it: Who needs to be in this meeting?

OK. I know Scrum makes this question fairly easy to answer. But . . . sometimes we might think we need to include people that shouldn't be there. And nobody goes to a meeting just to listen the others talk — it's human nature to join in. That's why a meeting with 15 people often takes a lot of time to achieve . . . nothing. Especially if all the attendees aren't fully committed to the project.

Do it: What's the point of this meeting?

People tend to talk about all kinds of stuff, and it's good to see your coworkers and partners getting along so well. But the meeting has an objective, and it must be accomplished. If you find yourself in a meeting in which people are adrift while the main point is still untouched, you should try using something like the Pomodoro Technique. I often use it to focus on my own work, but, depending on the people you invite to the meeting, it might fit there as well.

Check it: What have you got?

The meeting adjourns and everybody goes back to their normal lives. What have you got? Are your problems gone, or at least being solved? Did you miss someone who could have key information?

Act on it: How can you improve the next meeting?

Now, what are the results from your checklist? If something went wrong, you should discuss it with everyone who attended to the meeting and see what they can suggest. Remember: The more you involve your people, the better results you'll get.

There's a really important point hidden in each of these tips: Treat people well. It doesn't matter if they're going the wrong way during the meeting or refusing to change a bad habit. You need to convince them without force. Just remember what Dale Carnegie said in How to Win Friends and Influence People and try to put that in practice: "Criticism is futile because it puts a person on the defensive and usually makes him strive to justify himself. Criticism is dangerous, because it wounds a person's precious pride, hurts his sense of importance, and arouses resentment." Or, in a simple sentence: If you want to gather honey, don't kick over the beehive.

That's a start — just a taste, to introduce the PDCA idea and begin, little by little, trying to apply the concepts in our daily routine. In the next article I'll dive into the development process (including some code samples) and talk about how we can improve our Do, Check, and Act steps.

The author wishes to offer special thanks to the talented Rebeca Zocratto for the images in this article.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 0 (0 ratings)

Comments

Gurpreet Singh, CSP,CSM, 5/17/2013 1:22:38 PM
super cool write up
Mário Melo, CSP,CSM,CSD,CSPO,REP, 5/17/2013 2:09:58 PM
Thanks Gurpreet!

I'm working on its continuation (the "CDA" part) and I it'll be ready soon. If you have any suggestions I'll be glad to add them.

You must Login or Signup to comment.