Reading the agile manifesto, you won’t come across the word “respect,” but when I read it it’s clear to me that respect is an underlying theme. This dawned on me while having a conversation with my brother’s girlfriend, Cortni. Cornti is a dental hygienist who practices at a private dental office. Her office manages all of the patients’ dental records via old-school paper files. A few months ago, Cortni asked me what it would take to build software to replace the office’s existing paper system. She promised to bring me some example records to give me an idea of what she needed to enter into a patient’s file on a day-to-day basis. We spent about an hour talking about her interactions with her patients, the information she recorded, the frustrations she had with her existing system, and her vision of a software-based system that would solve her problems. At the end of it I must admit I was terrified for my own dental health, having learned of the whole slew of messy, painful dental problems a hygienist looks for and addresses. During that conversation, I learned a lot about how a dental office works, but I was also made painfully aware of just how much I don’t know about that profession.
We went to lunch and I briefly told her a bit about agile software development, although I never used the term agile. Our convo about agile went like this:
Me: So to overgeneralize, there are two basic approaches to building software. The first is where you and I sit down and talk about everything that I would possibly need to build, and then I go off and build it all, and show it to you when I’m done. In the second way, I’d build a tiny piece and show it to you, and then figure out what’s right or wrong about it, and keep building little pieces, getting feedback from you along the way.
Cortni: Hrm…I think we should do it the second way. I don’t think the first way would work very well.
Now to give you a bit more background on Cortni, she’s not what you would call an Agile champion. In fact, she’s never been involved in any sort of software project, or even in a company that builds software. She grew up on a horse farm in Colorado, roughly 15 minutes away from the nearest town of 1,000 people, and went to dental hygienist school because she “heard they get paid well and make their own hours.” That’s why I found it so amusing that she immediately and intuitively felt that an agile approach to software development might work, whereas a BDUF approach definitely wouldn’t. Yet that should come as no surprise. She spent three years in school just to get started in her profession. How gauche would it be of me to think that I can write software for her after one conversation, and get it right? How many conversations would we need to have before I could get it right? I don’t think it matters. There’s no way that I can do my job unless I get regular feedback from her on how I’m doing.
Whenever we try to build software, we have to be respectful of all people involved. The first point of the agile manifesto is that software creation is a human act – performed by imperfect beings in order to solve problems for other imperfect beings. We can respect this first at the team level. Software makers should be held in higher regard than a process you found in a book or learned in a workshop. Process can be instrumental in getting software out the door and enabling a team to continually improve itself and its product, but the moment you honor the process element over the human element, you’ve missed the point and will only cause your organization harm in the long run.
Respect should extend beyond the software team to the customers and users (which are sometimes a part of the software team, sometimes not, and are often ill-defined, mis-construed, or simply unknown). When developing software for a professional industry like dentistry, it should be obvious that practitioners are highly skilled and that your understanding of their work will always pale in comparison to theirs, even though you can develop sufficient enough understaning to build useful software for them. That’s why we call them “domain experts,” and their insight and feedback are critical to the success of a software project of this sort.
Another thing to consider is that not all software is built for skilled professionals. A lot of it is built for internal use by massive organizations whose employees have no choice but to use it. Without addressing the issue of how humane or inhumane it is to force software on a large group of people, it’s important that we as developers understand that we are partially responsible for the quality of worklife experience that these people have on a regular basis. It’s difficult for me to express this without sounding like I’m preaching, but basically we should just try to be aware that some of the software we build will be used by people who have no choice but to use it, other than giving up their jobs.
I have a lot more to say about this subject, but I think this is enough for now. If this resonated with you at all, I would like you to keep the principle of respect at the forefront of your mind today.