The Human Factor in Software Engineering

Dieses Wochenende habe ich mal wieder eine weitere Tour gemacht. In Sandalen. Schließlich sind das die Schuhe, welche meine Füße gewohnt sind. Ich war erstaunt, wie viel Natur es auch in Stadtnähe gibt. Allerdings sieht man auch an den Spuren von Arbeitsfahrzeugen und Waldarbeiten, dass deutscher Wald nichts anderes ist als eine halbwegs naturbelassene Holzplantage. Besonders amüsant fand ich, dass es im Stuttgarter Wald mehr Straßenschilder gibt als in vielen deutschen Innenstädten. Nachdem ich mich zünftig verlaufen hatte, war ich über diese Beschilderung sehr froh, denn ich besitze immer noch kein Fußgänger-Navi. Ansonsten habe ich zwei Schlösser besichtigt und einen hundert Jahre alten Steinbruch. Außerdem habe ich unterwegs immer so gute Ideen. Nach meiner Heimkehr schrieb ich die Einleitung zu einem meiner neuen Bücher. Das Training geht also weiter...

The "Decision" course has started this morning - in English as well as in German.
I am currently preparing concepts for similar formats about data clutter, time management and creativity.

You (as a developer, analyst, manager) can use Software Engineering methods in two ways: either you apply the method or you use it as a mental model. Let´s take the UML use case model as an example.
1.) Method as method: Software Engineering methods come along with templates, notations, rules, tools, etc. When you apply a method in your project, you most probably will have to motivate others to use the UML tool, keep to the UML notations and rules for Use Case specification. This is usually difficult to achieve. Especially if it is not your official task to initiate work process improvements. But even if it is, people do not like to be told to change their way of working.
2.) Method as mental model: Psychologists emphasize the importance of a mental model for systematic work and for communication with your colleagues, team members and all stakeholders. Such mental models can be the project plan, the software architecture, a workflow model etc.. Their function is to steer expectations and to make that the work of each individual fits together with the rest of the project. Therefore, it is important that everyone shares the same mental model. Software Engineering methods often provide such models. You can use them as the basis for structuring all your tasks, communication and documents. You go and ask the stakeholders for actors and use cases, and also for the dependencies among these use cases. You know what to ask and when you have asked enough. Your interview gets a structure by using a method. This looks more professional than saying: "Please, tell my anything I need to know about your requirements." or "Oops, sorry, I forgot to ask one question." You note down the results in a Use Case diagram which you later copy into the requirements specification, in presentation slides, meeting protocols and reports. Maybe, you want to structure requirements document and test cases according to which use case they belong to. This helps you to keep your documents consistent and provides an informal traceability link between them. You can use an UML tool for modeling the use case model, but you need not. If you want others to also edit the graphs, then you might want to use the drawing tool that is already used by your colleagues.

You see the difference? Alternative (1) demands a change in the way of working of your colleagues, while alternative (2) means that you do your normal work in a more structured way.

"This will not work here" is a sentence I often hear from practitioners.
When I was young and naive, I trusted that my colleagues with their high experience can judge in advance what will work and what will not.
Meanwhile, I have seen that "This will not work here" is a sentence applied not only to highly sophisticated methods from University doctoral theses which cause more effort than they save. No, it is an almost automatic reaction to all types of changes proposed, even to lightweight methods which were developed and successfully applied by other practitioners. "This will not work here" in fact very rarely wants to say that this will not work here. This short sentence can express, summarize and hide a lot of other types of claims, such as:
- This method does not fit to our way of working / product / already applied methods.
- We have tried so much else before, we are tired of trying new methods.
- This was not invented here, therefore we dislike it. We want to realize our own ideas, not those of foreigners / those of you.
- If we use this method, then everyone can do good work. Currently, project success depends on the knowledge of one person only and I am this important person.
- I / we hate any type of change. We do not want to learn anything new and get upset at work. Life is too irritating anyway.
- We are past the life phase where one learns new things. It´s over, do not try to teach an old dog new tricks.
- You are not the person who has the right or competence to tell me how I should do my work.
- Are you dissatisfied with my work?
- You are not the first one who tries to mingle in our work style, but you will fail like the others before you.
- In this company/ team, nothing will ever work. New methods will simply enhance the chaos.

Whatever the real meaning(s) behind "This will not work here" is/ are, it touches the change management problem. A new method is not simply a new method. It can mean a new way of thinking, of seeing the world and oneself´s role, a new working style and working speed.

The first step for managing change here is to find out what the real meaning of "This will not work here" is. Asking directly "What does this mean?" can lead to further nebulous arguments that hide the real causes for resistance. Instead, you can ask the following questions to indirectly find out:
- This method is meant to solve the following problem... Do you know any other method that can solve this problem better?
- Could we simplify and adapt the method in a way that it works better?
- Why were the methods you tried earlier unsuccessful?
- What extra tasks would this method cause you to do and what risks do you see?
- Are there single persons who could, should and would use the method first as pilot users?
- Who of you can judge best whether the method makes sense in your environment?

When you know the reason for resistance, you can decide how to introduce the method or also can decide not to try it. There is nothing worse than trying to introduce a new method against the will of the stakeholders and to fail. It is better to propose a method and then to wait whether the seed will grow. It is possible that after some months, in a meeting, the team reanimates the idea and now likes it, after they have got used to it and thought about it.
At least, this is how I convince people. I never expect them to change their mind just because I give them arguments. And I dislike rhethorical tricks because intelligent people after some days realize that they have been tricked. Usually, I also give people time.
This is probably one major problem in change projects: They do not have time. They must force change upon their victims à la "Who is not for us, is against us". However, most people are just undecided or slow. Who of us likes it when someone comes along, points to an awkward self-organisation and tells you that you MUST change. For pure stubborness, the spontaneous reaction is "No!". One is currently struggling elsewhere, solving other problems. It is not so nice to be told that there are even more problems which need attention and action. One can solve only one problem after the other. Additionally to problem-solving, we are still busy doing the daily work.

Have you ever regretted any of your decisions? Or do you find it difficult to make decisions at all?
Let´s try a new way of learning - in life for life.

Every Monday, you receive a handy bit of knowledge about decisions (size of a calendar sheet) and your weekly exercise by e-mail. You learn succinctly the most
important facts about decisions and you practice making goal-oriented decisions, presenting and influencing decisions, and understanding your previous decisions in
life. Professional decisions as well as private ones. Every week, you can ask me questions and get individual feedback.

This course is based on my intense investigation of rational and gut decisions during the last years. Thanks to numerous ligh bulb moments, I now live in peace with my decisions. So can you!

The course starts Monday 30th July and runs for 10 weeks.
It is offered in English and German. For the first 20 subscribers, it costs 10€, for all others 20€.
You can register at: AndreaHerrmann3@gmx.de

I heard that Rousseau - while believing that humans are born as good beings - claimed that humans can not be good in society. Society´s rules are made in a way that damaging others always brings more benefit than helping others. I wonder whether this is also true for one section within human society: a software project.
The word "team" is in fashion not only for project teams but also replacing other terms like the department. Nevertheless, most so-called teams are no teams according to the definition of Humphrey. According to Humphrey, a team is made up of at least two persons who work towards a joint goal, where each person has a defined responsibility and defined tasks.
However, project success is not always the main objective of all team members and even less of all stakeholders. Competition is very high in German enterprises. People do not aim at team success, but always their own success, according to their own criteria. This can mean they want to get home at a defined minute. Then, it is better for them that tasks are not clearly defined and not clearly attributed to the persons. Then, they can "forget" some work and still are not responsible for it. Helping others causes them extra work but no profit. Arranging misunderstandings and forgetting tasks helps them to work slowlier and go home earlier.
Others want to show that they are better than the colleagues and must therefore be promoted faster than these. For these, helping others can also cause damage. If they help someone, this makes him look more competent and efficient than he is. Therefore, it is important for them to help others only under the condition that everyone knows it. Like this, they can establish as an expert AND can establish the other as an idiot by telling everyone how stupid he is. He would never have managed to do his work, without help. I have experienced colleagues telling me simple truths which I already knew and then they ran around and told everyone that I did not even know such simple things. Damaging others is beneficial in software development.
There should be mechanisms and rules which make that it is more profitable for each individual to help the others than damaging them. Team success is not made up of successful sub-projects but of synergy effects, of using all the knowledge available in the team. Damaging a colleague finally means damaging the project and damaging the company. When I was a project manager, I tried to establish such a team culture. Especially, the company culture demanded that at each error the person had to be found who is guilty and must be punished. I refused to do so because I said that in a team, an error is not made by one person alone, but by several. For instance if someone forgets to tell a fact to someone, this someone also might have asked. Who works, makes errors. This is a well-known truth. However, in this company I was told that we want to achieve that no-one makes errors. This is an interesting statement in a company where people get no training for being competent enough for working error-free. They seemed to believe that publicly punishing those who made an error makes them work better, more efficiently than a training. Well, cheaper at least. When an error happened, I looked for causes and solutions. I often said "we". "If you help X, then work package Y finishes earlier and we can deliver earlier all together." (This proposal was the result of a critical path analysis of our network plan.)
Of course, I was not successfull with this strategy. It did not fit into the company culture. I was called a person who avoids conflicts and strives for perfect harmony. Well, yes, avoiding unnessary and destructive conflicts is not so bad, but adds to efficiency. Struggling and fighting detracts energy and time from the productive work. As for the perfect harmony: Solving real problems is fun, therefore I liked the management job. But it is no fun to see adults behave like kindergarden children!

Even the reproach that I avoid conflicts speaks in favour of my assumption that a software project and software company is also made in a way that damaging others is more beneficial than helping others.

Source of the team definition:
W.S. Humphrey: Introduction to the Team Software Process, Addison-Wesley 2000

Regelmäßig finden sich in den Fachmedien Berichte über gescheiterte Projekte. Ein wesentlicher Grund für das Scheitern liegt in unzureichenden Anforderungsdefinitionen. Je komplexer die Projekte sind und je dynamischer sich die Umwelt darstellt, desto wichtiger wird gutes Requirements Engineering und Requirements Management, um systematische Entscheidungshilfen zu geben und ein beschleunigtes Time-to-Market und folglich Wettbewerbsvorteile zu erreichen. Dieses Buch beschreibt für verschiedene Aktivitäten des Projektmanagements, wo und wie Methoden und Verfahren des Requirements Engineering und Management im Projekt zur Anwendung kommen wo überkommene Vorgehensweisen erweitert bzw. verändert werden sollten, wie Projektmanagement bereits (unbewusst) Requirements Engineering und Requirements Management an vielen Stellen einsetzt und dessen Ergebnisse nutzt. Durch bewussten Einsatz dieser Methoden kann das Projektmanagement verbessert werden. Eine Darstellung der Rahmenbedingungen für den optimalen Einsatz von Requirements Engineering rundet das Buch ab.

http://www.springer.com/computer/swe/book/978-3-642-29431-0
http://www.amazon.de/Requirements-Engineering-Projektmanagement-Xpert-press-Fahney/dp/3642294316/ref=sr_1_1?ie=UTF8&qid=1339019854&sr=8-1

Wenn Sie Fragen zu diesem Buch haben: Ich bin Mitautorin und Mitherausgeberin dieses Werks und freue mich über Diskussionen.

Eine Frau, ein Wort... Die letzten Tage war ich auf Trainingslauf. Allerdings habe ich ein Picknick mitgenommen, Schlafsack, Blasenpflaster und all diesen zivilisatorischen Ballast. Wir starteten an der Neckarquelle und wanderten den Fluss entlang, der sich zunächst etwas umständlich durch den schwäbischen Dschungel schlängelt. Ein ausführlicher Reisebericht ist in Arbeit. Nur so viel für dieses Kurz-Text-Medium: Wandern mit 10kg auf dem Rücken ist auch Sport. Die anvisierten 50km pro Tag habe ich leider wegen Materialermüdung nicht so ganz geschafft. Entsprechend bin ich nun ein wenig ramponiert mit Stichen im Knie und Blasen an den Fersen. Aber das motiviert mich nur dazu, in Zukunft noch etwas mehr zu trainieren. Von der Stubenhockerei bin ich ja ganz verweichlicht!
Außer Blasen an den Füßen brachte die Tour mir auch stählerne Muskeln ein und hat den Blick geweitet. Das Wandern erinnert wieder daran, dass jede weite Reise und jede Bergbesteigung aus sehr vielen einzelnen Schritten besteht. Entschleunigung, Weite des Horizonts und Eigenverantwortung sind weitere Stichworte des Wanderers.
Um auf den Auslöser der Tour zurück zu kommen: Dort ist das Ziel, hier stehe ich, mit dem Trainingsplan in der Hand. Was sollte mich aufhalten? :-)