Pragmatic Agile Weblog

Agile software development in real life

Quality is a state of mind

The past couple of weeks I was on vacation… ok, not at a nice and sunny beach, nor at relaxing mountain resort. I was at home to supervise some remodeling work I had to do in my house. This does not have anything to do with software indeed, but it was a great experience and I took advantage of having my mind out of development to watch closely how the construction workers worked. What does this has to do with quality? Well, being my house, and being just a remodeling I was paying very much attention to the fact they had to do the work in the best way, in a constrained environment (the house where I live) and respecting the deadlines. In short, they had to do a high quality work. And from what I’ve seen, they have done it! They have done the remodeling without breaking anything else, a little ahead the best-expected deadline and making some additional work. It was great, wasn’t it?

I compared construction work to software development and tried to extrapolate common factors that could be applied to so different fields. The general comment I have is that once more I realized that quality is, before anything else, a state of mind.

Below are some of the things that I observed and some lessons I learned.

  1. Before selecting the building company I looked for feedback. Everyone I talked to had great feedbacks about a small team of carpenters, the Bisi brothers. They are two brothers plus one coworker and they always work together. There is no way you get just one of them or you ask them to hire someone else. Watching at the results, I learned two lessons: first of all, reputation matters, and if you are good, people will acknowledge it; therefore, listen to feedback (and do not watch only the economics). Secondly, they are a team, a very committed one, passionate of their job: basically a scrum team!
  2. Bisi brothers do only the construction work; I also needed an electrician, a plumber, a painter, a parquet poser (sorry if the translation is not accurate, feel free to suggest a better one) and so on. I asked Massimo (the oldest brother, a sort of team leader) if he knew anyone that could recommend; indeed he has his network of specialists. All the people he brought and I met were very good technicians. Plus, Massimo’s team was very clear in telling me if anyone I mentioned to them and they knew were not going to do a good job. Lesson learned: real quality people brings quality people.
  3. In the case you do not know, the vast majority of Italian houses are built of bricks and hollow bricks. You cannot imagine, unless you experienced it, how much powder is generated when they collapse a wall! WOW, it is a nightmare! I know already I am going to broom it away for a couple of years. You would therefore assume that in doing remodeling the workers are going to work in the mess until the end of the work and then clean the ruins all together. Or even worse, leave the whole cleaning to you… Not in Bisi brothers case. Every time they finished a section or area of work, they cleaned everything away. Lessons learned:
    1. Quality is not only about the final result; it is a state of mind. Note that in the case of construction workers there is a very concerning factor which is workers safety. Bisi’s team has never experienced big incidents or injuries. I understand now why. You need to take care of each step in your process in order to minimize the risk of incidents. Turned into sw development, you have to look for quality in anything you do, from the scketch on your paper notepad to coding, commenting, unit testing and so on if you want high quality.
    2. Bisi’s team was applying many agile principles. Instead of completing the whole collapsing work and then cleaning up, they proceeded almost by user stories and then by tasks. A task was not completed until, for example, the ruines were not removed.
    3. You need to be careful in anything you do and ask yourself questions, if you want to achieve quality. One thing I really appreciated of Bisi’s team was that many times they found out issues and noticed things that could be wrong or required directions. Many times small things, but anyway things that I would have noticed only when it was too late.
  4. It is important you are able to say NO so to set the proper expectations. I notice even in my team that people sometimes tend to not to say no, just because they think I want to hear that we can do something. Bisi’s team was not afraid to say that something could not be done as I wanted/expected. For different reasons, maybe even just because the result would not have been of the quality standard they are used to. I appreciated it, because this allowed me to reset my expectations and to change my plan accordingly. The lesson I learned is that if you know your domain, do not be afraid to say NO, even if this is not what people expect.
  5. I sow for the first time many tools. From different kind of mason’s trowels to different types of hummers, drill-drivers and circular saws… tools are important and it is important to use the right tool for the task you have to do. Lesson learned: quality teams have the best tools and know when to use them. Note that not necessarily the most advanced tool is the most appropriate or usable. I was amazed by the use of the mason’s trowel. It is such an ancient tool but with a usability that is difficult to find in anything else/
  6. It was very interesting to note that Bisi’s team worked very similar to a SCRUM team. They haven’t been doing formal SCRUM daily meetings, but I am sure they communicated each other when they first met in the morning some guidelines for the work to do in the day. Indeed, in the case of construction work it is easier to see what has been done and what is missing. Anyway, all three had very clear in mind the final result and they have been picking up  a task to do autonomously, without the need of one telling the others what to do. They were constantly communicating and the results were under everyone else’s eyes. I was there when they needed to make some decision for which my input was necessary. They have been extremely efficient and productive, and that’s way the results were so good. I could not tell them, but I helped them simply removing the obstacles they encountered during their work and creating, for what I could, a good environment for them to work. The cost for me was a good number of chocolate bars, but I am sure they will remember it when they will present the bill! 😀 (or at least I hope so).

September 14, 2008 - Posted by | SCRUM

No comments yet.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: