«

»

Apr 03

Trust gets quality

People with the lowest individual velocity are assigned to the most complex bugs. We’ve found out that this practice increases development speed. Obviously, no one wants to fix complex bugs, so they work harder to avoid that.

 

A colleague sent this little text to me. I also got into an argument that scrum only works when teams not only commit to the work but even more to the quality of the work delivered. There is a definition of done. But this definition only partially dictates something about the quality of the work. Software should be tested. Should not have any technical debt and the software should be potentially shippable. And I can think of a few more items for the done definition. But where does quality come in. I have worked with a lot of developers and in most cases these people have a certain standard in coding. Call it acceptance criteria or scouts honor. A certain way code needs or even must be developed. I have even worked with developers who where insulted when I decided for them, as a former project manager, to release code without their consent. Over the years I have taken this for granted. A developer has a personal honor when it comes to his or her work. It’s like a sort of personal quality dedication. But what happens when this is not on the mind of the developers in your team. What if they just do the job and don’t see the consequences of their actions. Bugs in delivered software are a sure thing and nobody really cares. Well, you might say that you have a problem when this is the case. How do you tackle such an impediment? How can you make sure the business gets what they want and the quality is to everyones satisfaction?

What is it that ensures quality and dedication? It has for a part to do with knowledge. When someone does not know how to do things, things might end up wrong. So you must allow people to gain this knowledge through training and working together. When working together, people can check each other’s work by testing and learning. But what if people don’t want to share or work together. Than you will not get the quality needed. Let’s take this a step further. Why would people not work together? They don’t like the person they work with. You can get away with that in preschool but not in a work environment with grownups. When people don’t like each other  they don’t trust one another. Trust is a rare thing. You only give it when you feel safe, safe to share about things. Daring to tell that you don’t know things or being open about a colleagues work. Also, when the company you work for does not trust you in your work than it is obvious that people will stay within their own cubicles. So in essence, you get quality when people trust and are trusted. Far fetched? I don’t think so. Trust goes a long way. It makes that people start enjoying their workspace, colleagues and their work. They are trusted to do the thing the best they can and come up with new and good ideas. So invoke trust and you get quality.

How can you start trust? For starters, let go. Drop the leaches and let them do their job. Uninterrupted. This does sound easy but believe me it is very hard. In most cases old rules have to go. No more control by fear or micro management.  When things go wrong, don’t use that as a pointing finger. People must learn from mistakes, if they can, the first levels of trust will emerge. And believe me, nobody likes to make mistakes over and over again. Self correction and quality conscious will grow.

 

Someone once told me that every child has the right for some neglect, you can tell it that the stove is hot and should not be touched. But they only learn when they burn their fingers.

Source of text Target Process 

Permanente koppeling naar dit artikel: http://agilethings.nl/trust-gets-quality-2/