In fact for almost all beings on planet Earth being within close range to each other when communicating is the only form possible. All those beings need to either see, hear or smell their communication partners. All, but humans. Humans have evolved into a species that can leverage two new forms of communication: one is sophisticated verbal communication and the other is communication through symbols.

Throughout our existence, we humans have developed thousands of different languages and usually also a corresponding form of scripture that allows us to record information, share and transmit it or get back to it at a later time. Being able to perform these activities has allowed us to evolve even further mentally and create complex societies and tools.

But why is it so difficult for us to communicate well with only the written word? Isn’t it that the same written word has allowed us to get to where we are now?

Maybe it is because not all of us possess the same skill to read and process the written word?

There is an activity that teaches us the skill to read and process the written word. It is called interpreting literature. The mechanics of this activity can be visualized as in the following diagram.

As the reader I will understand any text from within my own context. Context is the combination of my work/life situation, my education, my acquired believes, my skill of reading in a given language (the language of the text) and whatever else has influence on my understanding of what I read. For the writer there is also his own context and when he writes a text there is the context of the moment when the text is written.

The simpler and the shorter a text is, the less information about its context can be revealed to the reader. Think about Twitter messages. They are limited to 140 characters. People send them out of a situation at work, when they had a thought while walking or talking to a friend or something else. My, limited, observation is that people do take into account that limited context and don’t get into arguments because they understand that they can’t understand well what the person says. So they, when in doubt, assume the best.

In the case of email we don’t have that limitation. We can write very long texts and it may take an hour to write a meaningful email that not only transports what we want to say but also enough context so that the recipient understands why we write and what our situation was.

The challenge now becomes one of reading. Given the writer is good at expressing complex thoughts in a concise manner, if the reader just skims over the text due to time constraints or isn’t really willing to read thoroughly, we have a communication breakdown despite all good intentions and effort. It’s the context of the reader that becomes an impediment to working communication.

I feel that written communication only works when the communication partners are willing to invest and keep an open mind. In the case of literature the writer just puts the text out for anyone interested to read. It’s more a broadcast model. Writer and reader don’t have a tight relationship so there is not much harm being done, if the reader doesn’t understand the text as indented. However, in a work context, a lot of harm is being done when writer and reader don’t understand each other.

We can mitigate the negative effects of our natural inability to communicate well or we can invest into an improvement of our communication skills.

The prevalent recommendation to work within co-located teams to enable face to face communication is such a mitigation strategy. It creates a multi-channel situation for all communication partners but as soon as some leave the room and start relying on less channels the problems show up again.

Agile software development practitioners have shown us many good techniques to create high quality software. Once we start to use the agile mindset outside of software development teams we will need to solve the communication problem.

Software teams can share working software with the rest of the organization. For example, one team can share a library with other teams and the library is their product. They can send an ambassador with the code to the other team for a while to carry the context of the text to their colleagues.

What about when the product is something else than software?

I was just saying ambassador. I’ve seen some thoughts about a lattice organization where each group within the lattice shares a member with neighboring groups.

These people are interested in being shown and taught a process. First you do this, then you continue with that and finally you check that and if it’s right, then you continue here. They like a linear and predictable way of doing things. Show up for work, do the things you have to do and leave.

A while ago I read somewhere that our human brain likes linear processes. First you get hungry, then you find food by doing all these steps and then you will feel happy. If that’s the case, then these people act perfectly normal.

But then creating things – and that includes software – is so much more than finding food or shuffling information from desk to desk. It is an entirely creative activity in which there is no clear separation between right or wrong. There are many wrong ways of doing it but also many right ways of doing it. So knowing and understanding why someone is doing it in a specific way seems to be important. Important because that knowledge may guide you to further learn in the direction of that person or someone else.

What I just called ‘learn in the direction’ is a complicated and probably entirely wrong way of calling this a ‘mindset’.

A mindset is not a belief. It has to do with assumptions and with a point of view. In German there is the term “Weltanschauung”. It means how someone views the world, which is a general philosophy of understanding the world based on assumptions and cultural background.

Something like “Agile” as expressed in the Agile Manifesto is clearly a mindset. It also is a preference. By saying “Individuals and interactions over processes and tools” the speaker makes it clear that he prefers one thing over the other and on request will explain why he does. He will likely not accept the opposite until you convince him that the other provides more benefit.

A mindset is based on experience and teaching. A process is purely based on teaching. You cannot successfully follow a mindset because someone taught you the rules but you can successfully follow a process after being taught the rules.

Acquiring a mindset requires to understand the Why of all the things the other carriers of said mindset do. In the case of a process understanding why you do something is not really important. You can still use it and be successful.

A mindset will grow stronger and become more and you will defend it more and more once you make enough positive experiences of applying it. That is when a mindset starts to morph into a belief. A process is easily abandoned. After all it is just a bunch of rules to follow and after changing employers you can quickly learn to deal with a new set of rules.

“Agile” – with uppercase A – can be a process. It can be working in iterations with all the ceremony before and after. It can be the XP flavor with things like TDD. Or something else that people have come up with. “agile” with lowercase A – is – just by looking at the word itself – an attribute.

“Being agile” is different from “doing Agile”.

By being agile I am able to react to change easily without loosing my balance. I can do this because I have solid grounding due to my experience in my profession. I have my preferences for how I do things and what I use to perform my work based on experience. I want to know for whom I do something because I want to tailor what I do towards that person. My agile mindset defines who I am, what I do and how I do it.

The programmer is the subject and writing tests is the object. The outcome of this activity is well tested software.

According to Activity Theory there are rules, community, the division of labor, as well as the mediating artifacts that influence an activity. They themselves, are also influenced by the activity.

Let’s go through rules, community and division of labor first.

If there are no rules in place that demand writing tests, then nobody is being forced to do it. In the case of an organization with a traditional test approach (QA after the fact) there might be a rule that requires the team to deliver something that works or else the team will get back a report with a huge number of defects from the QA people. The rule may come in the form of bad performance reports or similar. If that’s the case, then there would be an incentive to writing tests to prevent defects.

In the case of the organization with the traditional test approach the community within the organization does not promote writing tests first. There may be a few people here and there but the community at large does not do it. So there is no good example for doing it. “Others don’t, why should I?” may be the question some programmers ask themselves in silence.

A huge influencer is the existing way of how labor is divided within the organization. If there are strongly separated groups and membership in these groups is static – based on job description -, then a programmer will not want to do the job of testers. He may be actively prevented from doing someone else’s job. In an extreme case he may do work outside of his job description and, who knows, could be accused of violating his work contract. How far this goes is also dependent on the rules and the community factors within the organization.

The fourth element that influences subject and object and is influenced by them is the mediating artifact. For a programmer this refers to the tools he uses to perform his work but also to things like the runtime environment or where software gets deployed too. Things like the version control system, how a build runs, etc. – all that is a mediating artefact. It’s basically everything that he uses to make software. Those artifacts are also influenced by the community within the organization and what is being used to make software does shape the community.

If at some point important decisions about tools were made and those tools don’t make testing easy, then a community will have evolved where testing first is seen as too difficult and not worth to pursue. A change of those tools might be very difficult, because the community is heavily invested into those tools, as the tools have influence onto rules and the division of labor within the organization.

I will stop here exploring this any further, as this is meant only as a little experiment. However, I hope that it shows how Activity Theory can be used to explain observed behavior. I believe that it can further be used to identify those factors that stand most in the way of making changes that allow the desired activity to happen.

As Activity Theory also takes into account for which reason, the motive, people perform an activity and helps to identify goal-based actions that contribute to the activity, there seems to be another handle for change.

As soon as we were going right, things started to change. Suddenly he wanted to go faster again. So I let him and apparently moving his feet faster made him calm down.

There is that interesting phenomenon of the two hemispheres of the horses brain. They are interconnected but horses can focus on two different things at the same time. They can watch a potential threat on one side and be curious about something else on the other.

According to Parelli right-brain horses tend to be submissive, fearful, not confident, nervous and reactive. That pretty much describes Maximiliano in his current stage of development. He can’t stand still easily, panics easily because of a perceived threat and is always very alert. That does qualify him enough so that I say he is a right-brain extrovert.

Today we were in the aisle between the stalls and it was feeding time. All the other horses got excited because there were food coming their way. What did Maximiliano do? He jumped in the air. All four feet went up and somehow he managed to do a jump while keeping in position. I was holding him with the lead rope and after a quick “hey!” he calmed down. But still… So that’s another point for begin a right-brain extrovert: over reactive.

Max, on the other hand, seems to be just the opposite. He is dominant, brave (approaches new object without fear to investigate), confident and pretty calm. He does tolerate many things too. There is hardly anything that worries or frightens him. Now I see that a left-brain introvert also gets easily bored, is pushy and has a tendency to buck or charge. Also they are stubborn and food focused and lazy. Well… That again is a pretty accurate description of little Max.

Today the two spent some time in the indoor arena. There was little Max pushing around the much bigger Maximiliano who was trying to get away from the little bugger. Max played the dominant horse biting the other one a bit to make him move. At one point – I was standing in the center of the arena – Maximiliano got bored of the game and went to me – like seeking refuge. So I grabbed his halter and ordered the approaching Max to stop and go away, which he did. We were clearly playing the game of finding out what our pecking order is. Little Max got the message and went to play elsewhere and Maximiliano apparently was happy to be with me instead of with pushy Max.

So it appears that I have two horses with exactly the opposite personality. Now, that’s fun. It certainly is a great opportunity for my own education. We shall see how it turns out in the long run.

Peruvian Paso horses move in a different way than other horses. Regular – non-gaited – horses walk, trot, canter and then gallop. Peruvians walk, then go into a faster walk called paso llano, followed by another much faster walk called sobreandando and then eventually gallop. With my Peruvian Paso mare Topacio in Panama I was fortunate enough to enjoy this walking horse sensation. It is like flying. You just go faster and faster but still it’s a very smooth and relaxing ride. There is no abrupt change between the different speeds. This video shows nicely how it looks like.

Maximiliano – even during round-penning – wants to go at the paso llano. The paso llano is the gait that allows these horse to cover long distances without getting tired. So he must feel most comfortable at that pace. Still it is important to teach him at a slower walk. Simply because the faster he moves, the more abrupt – and dangerous – misunderstandings can materialize.

We need to work on that next. Step by step.

Max on the other hand is a totally different character. He is like a young child with too much energy. He is just about 3 years old. When I took him out for a lesson he needed to disburse all that extra energy. So he started to jump around and was unwilling to go in circles. That of course cannot be tolerated. He needs to learn to respect humans and be calm around them. So it took about 10 minutes to get that clear between us. “You don’t want to behave? I make you run.” always works. After that he was a different horse trotting around in the circle and changing directions following my hand signals.

Since his relocation I have not ridden Maximiliano. However, that’s not really a bad thing. I did some research into his previous life (would be great, if a horse could speak) and I believe it is really true that he was just started some 5 or 6 months ago. Everything else must have been pure handling and not really any kind of training.

So I decided to treat him accordingly and have been working a lot on desensitizing and confidence building with lots of rubbing. He now follows me around a path next to a larger body of water, steps into puddles and mud and keeps walking calmly. Yesterday we were even practicing ‘do not move when I mount’ with a helicopter in the air.

Instead of mounting for real I have been spending time to touch, rub and tap every part of his body. Initially he had given me a stronger reaction when my boot touched him behind the saddle. I have not repeated the exact same thing yet but I have been tapping there with my hands intensively and he does not move. So that seems cured.

I also made an interesting discovery. He was always moving away from me when I approached him to mount. It was because he wanted to move his hindquarters away from me. So we ‘discussed’ the matter and ‘agreed’ that approaching with my arms raised means “I want to mount” while with the arms lowered it means “move your butt”. It did not take long ;-)

To put in a good foundation I was repeating the exercise of just getting into the stirrups and bend over the saddle from both sides over the last few days. We did it indoors and outdoors.

Next will be to actually mount and practice actual riding. When he was not worried and fearful he was reacting very well to light cues such as moving my body weight in the saddle. It is really great to be able to slight move my weight to the left and the horse turns left.

There is so much bad software out there. But then there are people and companies that really understand how to make good really software and – in some cases hardware too. These people truly understand what it means to develop software. Hint: it is much more than writing the code.

Since the NATO conference on Software Engineering in 1968, which took place in Garmisch, Germany, numerous methodologies and processes for software development have been created. Most led people astray. Who knows why that is. But then it’s good to see that the good ideas are still around. That includes Test-Driven Development, which was envisioned at the NATO conference in 1968, and also the good ideas from Smalltalk, which is from the early 1970s.

Since then the topic of Human-Computer Interaction (HCI) has been research extensively and approaches such as User-Centered Design (UCD) came out of that. Although the focus on the user was a very good one what the user actually wants to do kept a bit in the background. Somehow a lot of UCD seems to be about how the user interacts with the shiny widgets on the screen. Many visual designers have contributed great looking interfaces but still too much software does not what the user wants from it.

A while back I stumbled upon Activity Theory and what has been called Activity-Centered Design since the mid 1990s. I started to research it and it made perfect sense to me to combine those ideas with Acceptance Test-Driven Development and other agile practices and techniques.

The book Smarter Software with Activity-Centered Design explains how to use Activity Theory to create software that makes sense to the user and really solves his problems. Yes, I know… That’s what everybody says. At least it’s the goal. We’ll see what the critics will say in a while.

Because short feedback loops are so important I have opted against my initial idea of finding a well-known publisher and am self-publishing. That allows me to update the book frequently and instead of having a small group of editors or only one, who may not be an expert on the subject, my editors is all of you my readers. The book will initially be available as PDF, ePub and MOBO (Computer and eBook readers) at LeanPub. Once the content has stabilized at bit better it will be made available at Amazon and eventually there will be a print edition.

As this is a software development book there is, of course, source code. For that I will use GitHub with public repositories. That also allows those who are interested in collaborating to fork the sample projects and send pull requests with their contributions. That’s going to be fun :-)

Further is there a dedicated website at http://activitycentereddesign.com and also a corresponding Google Groups, which is open to anyone interested.

I’m excited about all of this and I welcome you to check out the links I have provided.

Imagine you are the owner of a chain of restaurants with about 800 locations. One day during travel you discover a restaurant where they have little computers with touch screens on every table, which the patrons can use to order from the menu. You are so intrigued by that that you want to introduce this to your own chain of restaurants. Besides bringing food faster to the table you also envision benefits for your supply chain management.

“We are not a software company”

Your organization is a chain of restaurants. Everybody has a hospitality background and their only connection to software is that they use computers and several programs day in and day out to send email, write letters, do accounting, print checks for the patrons and run statistics. Most of these programs are quite easy to use but some require some training for up to a day. It’s probably safe to say that nobody knows how to actually make software but then some of your managers report how their sons and daughters are taught about computers and programming in school so it doesn’t seem to be so challenging. Sure, kids in school don’t work on large programs but the basics are certainly the same – isn’t it?

Reasons to keep it in-house

Because you view this new initiative as being so critical to the success of your business you decide that you should not contract an outside party for the development of it. You fear that this new thing may get into the hands of your competition too soon. Instead of awarding a contract to an established software development company you decide to hire a number of programmers and create the solution in-house.

Things to consider

Ideas are worth nothing. It’s the execution that counts. You can ask around at Venture Capital companies and they will tell you that they get hundreds of proposals and never would consider signing any form of non-disclosure agreement.

A company implementing software on behalf of their clients has no incentive to disclose one client’s idea to another client or to the public. Doing so would destroy their reputation and their company. There is nothing to gain for them. And don’t forget “ideas are worth nothing”. Even, if the contractor would disclose your idea to a competitor, it doesn’t really help the competitor. He still has to implement a lot of other things in his organization around the idea of the software solution to really take advantage of your idea.

Software development is a difficult undertaking. It is a risky and expensive business that requires a lot of experience and knowledge. Anyone can tinker with code and get something done. It is not difficult to learn how to write a script or even a Java program (or whatever other language one might choose). However, the development of a maintainable software solution that solves a business problem in the right way is a totally different thing.

By keeping software development of any dimension – if you write one line of code, you are basically already doing it – in-house, you have made the decision to learn how to develop software. As with any learning it will take time to master the subject. And while you learn a subject, you shouldn’t be delivering any critical work products created using the subject of your studies. Plus – and that’s more important in a business context – all that learning takes a lot of time. While you learn your competition may be working on the implementation of a similar idea and in the end succeed at executing their idea while you are still learning how to execute your own.

“We hire qualified software developers” I hear you say. Really? How can you know who is qualified? How can you judge someone’s skill without knowing much about their field? If you still want to keep development in-house, the best you can do is to hire a qualified advisor so that this person basically sets up your internal software development shop. But are you prepared to spend the money that such a venture requires. You are basically creating another company from scratch. And for how long? How will that new company – you may call it “department” – live?

I think that unless you are willing to transform your company into a software company you should find a qualified software development company and let these guys do their job. It is much easier to figure out who has successfully created software you like by looking at what they did for other clients than to build an organization from scratch.

Those I respect I will probably approach in such a way that it shows how much I respect them. I may feel compelled to not approach them at all or at least not frequently. I may even be a bit afraid and worried when interacting with them. Not out of fear but because I don’t want to appear as a foul in front of them. Them respecting me might also be part of what I wish for and what I don’t want to loose.

With the fools it is much easier. I don’t really care about what they think of me and I don’t care who they are and what they do. They are just fools and not really of any concern to me. So when I have to approach them I do it as I could care less.

Besides the fools there is another category of people I might not respect. It’s those about whom I think they are working for me because they have to. Or even stronger: those who have to serve me. It doesn’t really matter why.

My own perception affects my interaction with those around me. In the context of work in larger organizations it is also the perception of my department or its leaders that affects how we can interact with the members of other departments.

I may view myself as being part of “the business” and define what a software system should do. Being part of or close to those who run the actual business puts me in some sort of position of power – simply because I define the work others are supposed to do. At least I may think of it that way.

Now in an act of human weakness I have found a large group of people essentially working for me: the programmers in the IT department. It’s “them” who have to deliver what “we” define. And speaking of business… They better do it on time and within the budget “we” have defined. Of course with high quality or else “we” won’t respect those programmers as professionals.

Change is a good thing – isn’t it?

No. Not really. By virtue of being part of “the business” I have earned myself a position of some influence and there is probably also some kind of job security for me. I am needed. I am translating and interfacing between the programmers and the other members of the business side in our organization.

Why would I want to change that? There is no incentive for me. Or is there?

Someone tells me that I should collaborate more with the programmers and testers. To help them create the right software. Why? I have already defined what “we” need and they should just build it as I have described. Their stuff usually doesn’t work the first time, which is probably due to sloppy testing and hence I blame the testers too. Because of that I have to waste a lot of time going and back forth anyway. I have my own reputation to defend and I can’t really babysit “them”.

New opportunities

On the other hand there might be new opportunities for me. If I can find a few of really smart programmers and testers I can trust, then maybe what seemed too risky for me and my career in this organization may turn into an opportunity. Sure, “they” still work for me but in a much closer way than before. I might try to sit with them and tell them examples of what the software should do. They have been telling me that they can use my examples as automated tests to verify their code. If that’s true, then I would really get what I have defined. That might boost my career in our organization. People may recognize my contributions. That doesn’t sound too bad. I should probably try it but first I need to find programmers and testers whom I can trust.

My Peruvian Paso gelding Maximiliano is progressing in his training. Now that he has lost his fear a bit and it is safe to actually be on his back I have been working on cues with him. Teaching him things has really helped to establish a good relationship.

He has been respectful from the beginning. Whenever we are together in a small space and he wants to turn around he never turns his back to me. That’s quite important, because the hind legs are the horses weapons and I definitely want those to point away from me. However, that’s not always possible and so he does a remarkable thing. He puts all his body weight on the hind quarters and then pivots around. That’s like saying “see, like this I really can’t kick”. I do appreciate that. He also knows that I like to see his face and so when I move so does he. Good Boy!

At the breeding farm in Virginia he had learned to turn left and right, go and stop. But that was just a start and it was in the bozal. While in Panama I made good experience with a bitless bridle that creates pressure on the horse’s cheek instead of pulling the mouse. There is no piece of metal in the mouth either, which makes it easier to eat and drink with the bridle on.

Maximiliano understood the pressure on the cheek immediately and is moving left when the pressure is on the right. But then who wants to pull on the reins all the time. He is so sensitive and reacts to every little thing. Why pull and yank and do all that heavy stuff? With such a sensitive horse a heavy hand would actually be dangerous.

Instead of pulling the reins we have worked on leg cues instead. I put more weight in the left stirrup and he turns left. More weight in the right stirrup means turns right. That feels natural to the rider and keeps you on the horse when doing sharp turns because your center of gravity is moved into the curve. For some reason it works much better to the left than to the right but he really tries to please and get it. Progress is good. Good boy!

The last time we trained it was a bit windy and so he spooked here and there because of the wind. However, he did not run away. He kind of asks whether he should run and if I stay calm and move him into a circle, he calms down and stops moving.

Unfortunately I lost an opportunity for a wonderful trail ride in the snow. I was afraid that he might spook because of snow falling of a tree branch or something else unknown to him. I feel we need to work a bit more on our trust relationship so that he becomes more secure and safer to ride.

What has changed dramatically from before is his behavior when I want to catch him. Before he was always trying to avoid me when there was space to move away. Now I can walk up to him and he stays and let me touch him. It’s not yet perfect but the more I just catch and release him, the more he just waits for me to come back.

Getting there. Good Boy!