In recent times, I have observed an even greater specialization of professions than before. Doctors are no longer simply doctors, but are specialists in specific organs. One no longer goes to a dentist, but depending on the problem, one goes to a dental surgeon to remove a tooth, and to a dental hygienist to clean the teeth of tartar. An internal medicine doctor, after a history, sends us to a specialist, who examines us in terms of his specialty only, without giving much thought to what might be causing the organ's dysfunction, and treats the effects rather than the causes, as this is outside his field of expertise.
Specialization vs. holistic approach
In the IT industry, a project manager may come from a professional group other than IT, with a specialty in leading projects and even requiring project managers to be certified to prove their specialization. Testers are no longer simply testers, but are black-box testers, functional testers, automation testers, manual testers, etc. Such examples can be multiplied in abundance. However, we forget a very important glue, without which it is impossible to move forward. One would like to say: doctor - a person is one organism and not loosely connected organs; IT specialist, your product works only when all its elements function harmoniously with each other.
Despite the undeniable logic of the above statements, the holistic approach seems to be increasingly marginalized. Specialists are valued more highly than those who know how the harmonious whole works, which is becoming the new specialization. Blind faith in automation and manufacturing processes, makes people more and more like machines. I check what I have assigned in the "backlog", code, "merge", mark it done and switch to another "task", answer questions in a meeting and that's it. If there are no errors then there is good quality, if there are, then they need to be corrected. I work according to the established process, when I don't have anything in the "backlog" - means free and so day after day.
However, the real quality, the one that will be appreciated by the customer (market), is born elsewhere, I call it commitment, passion, motivation of individual people working on the project. In simple terms, it means that I can do the same task so that it is done or do it exceptionally, so that I am proud of it and the client is delighted. However, in order to know about what can positively surprise the client, you need to change your approach to work. Without broadening our horizon, without at least knowing the specifics of the client, the essence of the problem we are solving, the environment in which our solution will be implemented, we are not able to make full use of our talents. The process itself will not change this, as it is an attribute of the person working on the task.
In an IT environment, a programmer can perform the same change in several ways. If he is committed and understands the target operating model of his application, the only thing that can discourage him from taking shortcuts is intrinsic motivation. The state of knowledge and the emotional state translate directly into the quality of the code and, consequently, the quality of the delivered product. The overlooking of this fact by executives leaves me bewildered, especially since we have been dealing with the IT industry for more than three decades. Nowadays, all sorts of facilities for employees are emerging as a remedy to these problems. They often have game rooms, rest areas, inspiring offices, all to make things more pleasant. This is nice, and I very much support it! However, what is most important still remains the same. Solutions are still being sought in tools, frameworks, processes, and not where it matters most - a close-knit group, communicating well, working with commitment in projects, a group that wants each other. Managers and leaders are not actively creating an ecosystem that promotes qualitative change. Processes are designed to have data sources for KPIs, but how often have you seen a KPI that measured this: "to work efficiently 6 hours a day (no more) and deliver projects in less time"? I'd like that, wouldn't you? Instead, we focus on important but not the most important topics and burn time, hours and frustration increases. At some point, employees spend more and more time in the game room than on project work or just "being" at work.
Requirements specification
I won't cite here all the possible ways to improve software development processes, but I'd like to focus on one of the fundamental issues where we can gain the most. I am referring to the requirements for the software being developed. Today we have various advanced tools to manage them, track changes, we can automatically translate them into tests and code, and even test results. But what about their quality? I don't mean their book correctness, that they should be SMART, etc., but that they should be complete, that they should reflect what their later user expects, or even that they should deliver more than they expected, so that they are positively surprised.
Let me start with "User." We should not assume that the user knows exactly what he wants. The approach of, "well, what should I do," at most leads to "squeezing" requirements out of the user, but they will be "effed up" and not good. The user often knows what's bothering him, but has no idea of the capabilities of the technology that can solve his problem differently than he thinks. Perhaps instead of filling several fields on the form with nonsense statuses, because the user knows nothing about them but has to fill them out obligatorily, you could hide them and change that attribute to optional. But how is he supposed to know about it, who is supposed to tell him that there is also this other better world.
Intuitively the answer comes by itself, this is after all the role of the Business Analyst. This is a fact, but what if this analyst is not familiar with the technology, and the "business" requires that the implementation be as cheap as possible? How can this be done so that the requirement has a chance to be good, and not just be? This is where the "human" element comes in: the person, his intellect and willingness to do the job better. If we assume that the delivery leader (sometimes also called the manager), is a person who is willing and understands where quality comes from, I suggest first focusing on motivating people, showing them that the same thing can be done better and more efficiently. If we know that the user or customer doesn't know exactly what he or she wants, that there is knowledge in our group of specialists, but the business analyst doesn't have technology roots, then a simple algorithm can be applied:
- We ask the business analyst, in consultation with the user and the developers and testers, to write the best requirements of his life, you need to give him a while to do it, not too long, but such that it can realistically be done (in the chaos of communication everything takes more time, the more people, the more chaos and more time)
- Depending on the size of the description (I mean the effective text not the number of pages with pictures), we distribute the document (or a link to it) to all participants, asking them to read the document and set a date for a meeting called Requirements peer review (not meeting). The time allotted for the meeting must give the participants a chance to review the document. The meeting should be scheduled to be "short," depending on the size of the material to be reviewed, for example 15 minutes (which in many situations will be a culture shock).
- During the meeting, at the very beginning of the meeting, ask the "sacramental" question whether everyone has read the document and is ready for review. Make sure at this point that the document has been read and not just opened. If at this point someone reports being unprepared (usually it will be something along the lines of, I've read as much as I can manage, or I've familiarized myself to my extent), politely thank everyone for coming. Ask the unprepared when they will be ready. And immediately set a date for the second meeting. This is the first lesson for everyone that there is no point in meeting to review an important document if not everyone has read it.
- While everyone has confirmed that they have read the document, then politely, firmly and specifically ask each individual how long it took them. If the document is large, and someone says 5 minutes, then we ask them questions on how they did it, if they don't convince us, then we postpone the meeting again, for the same reason. If everything is OK, then we know how much time everyone has spent preparing for the meeting and that everyone has prepared (at least declaratively).
- We proceed with the meeting. The facilitator instructs that he will only go through the points of the document and ask for comments on them, and asks for them during the review. If the document is very important, it is, for example, a text that is an important annex to the contract, it is worth reading each point aloud, because even syntactical errors can be crucial, and the requirement should leave no room for interpretation.
- Now the magic happens, at first moderated by the leader. He asks questions, asks for implementation details if he understands them well (e.g. paraphrasing and asking questions: that is, in practice it will work like this and like that, do I understand?), while showing the participants what the meeting is all about. I guarantee that in a while other questions will arise, inconsistencies in understanding will come out, despite the fact that everyone participated in the preparation of the documents. It is very important to involve the client, but even with a business analyst alone it can be done.
During this meeting, anything that is not corrected during the meeting (it's a good idea to have one person who changes the document during the meeting, and it's worthwhile if it's not the meeting leader) is documented as a defect (just like a software bug) assigned to a specific person.
It is very important for the meeting leader to make sure that the atmosphere is open, so that everyone is looking for bugs and not accusations from others. At this point, the quality of the requirements will largely depend on the atmosphere, the attitude of the participants and the clear purpose of the meeting. We also cut off all conversations conducted out of topic, if we happen to open the so-called "Pandora's box", we write it down as a defect and move on, we do not prolong if the topic cannot be closed at the meeting. It is important that participants understand that they have the opportunity to address all their comments, that they will be heard and taken into account. Then the document becomes a vehicle for information, a collaborative work and not a business analyst, this also raises motivation, as we will be delivering something that makes sense. In addition, a meeting on a topic, with the right dynamics, concerning specifics, will not be seen as an additional bureaucratic imposition, but will become an effective tool.
In the end, after reviewing the document, we determine that the new version of the requirement with the corrections applied is in effect. If there are no other defects (this rarely happens), we approve the version as the source of the requirement and can move to the next phase of delivery.
If we find defects, we determine whether we want to meet again and review the document together after correcting them (this usually happens when there are a lot of defects that require significant rewriting). On the other hand, if the defects are simple to implement, we can arrange to approve the material electronically without having to have another meeting.
The first meetings will be more difficult and longer than we planned, but with an experienced leader, the organization will quickly learn how to organize itself. For those who like theory, I suggest reading Fagan's method: https://en.wikipedia.org/wiki/Fagan_inspection
Motivation is key
I encourage you to experiment and apply efficient processes along with participant motivation. The method I've shown will significantly improve work, but if your people are in the process of looking for another place to work because they can't stand each other at your place, no method will force them to make an intellectual effort. If people don't identify with what they are doing, then you lose everything and are happy to deliver chunks. Reviews will take place, but problems will remain, code will be created, but it will be poor, deadlines will be met, but the product will be lousy. That's why I'm sounding the alarm to leaders, managers, decision makers, focus on people, on their motivation, on the work to be done, and don't burn time on unnecessary meetings or coming to work just to be. If people don't know what they are supposed to do, why and what they are participating in, they feel like cogs in a machine. And nothing will change this, no team-building meetings, motivational speeches, internal projects, and especially the methods used by HR, which are perceived as a bad joke. You have to go to the source of human motivation, which to be effective and long-lasting must flow from themselves, your role is to give them a chance.
