I have been reading a lot of Steven R. Covey’s works lately and one of my friends is trying to champion Scrum at work.  Marinating in these two has started to clarify some nebulous issues with Agile for me.  They are not crystal clear, they just aren’t as muddy.  Take Steven’s article Taproot of Trust and read the first line:

Efforts to empower employees and to align systems will be forever frustrated in cultures of low or no trust.

That right there says a lot; especially for Agile.  Agile is built on empowerment, raising the question: in a organization of low trust Agile will fail?  It will if the issues of low trust are not addressed and addressed first.  This raises the question: how does Agile affect/create/enable/encourage trust?  Well lets make sure that we are all on the same page as far as “trust”.  Again from the Taproot of Trust:

Trustworthiness is the foundation of trust. Trust is the emotional bank account between two people, which enables two parties to have a win-win performance agreement. If two people trust each other, based on the trustworthiness of each other, they can then enjoy clear communication, empathy, synergy, and productive interdependency. If one is incompetent, training and development can help. But if one has a character flaw, he or she must make and keep promises to increase internal security, improve skills, and rebuild relationships of trust. Trust or the lack of it is at the root of the success or failure in relationships and in the bottom-line results of business, industry, education, and government.

And now trustworthiness:

Trustworthiness is based on character (what you are as a person) and competence (what you can do). If you have faith in my character but not in my competence, you still wouldn’t trust me.

Many good, honest people gradually lose their professional trustworthiness because they allow themselves to become “obsolete” inside their organizations. Without character and competence, we won’t be considered trustworthy. Nor will we show much wisdom in our choices and decisions. Without meaningful, ongoing professional development, there is little trustworthiness or trust.

Now back to the question: how does Agile affect/create/enable/encourage trust?  Maybe it would help to reword the question.  How does Agile affect/create/enable/encourage people to make deposits into their bank account of trust?  I think the greatest things that Agile promotes related to trust are:

• Visibility
• Small Iterative Commitments
• Frequent Deliveries
• Automated Tests

I think one of the best places to re-enforce this is the daily standup.

This is the final post in my series on OOD class principles and testability. It has included:

• Single Responsibility Principle and Testability

• The Interface Segregation Principle and Testability

• Dependency Inversion Principle and Testability

• Open Closed Principle and Testability

• Liskov Substitution Principle and Testability

• The Law of Demeter and Testability

There was a pit stop at YAGNI and Testability as it had some bearing on the OCP. It was all kicked of by Benefits of Testability. Which was inspired by Dr. Stefan Jungmayr’s dissertation Improving testability of object oriented system.

BTW Stefan’s site http://www.testability.de/ is a great resource (English Translation).

Here is a table that I think quickly summarizes how, when followed, the principles relate to the three aspects of testability.

Yes-less = Because the surface area and or type population of the test subject has been reduced, there is less to: observe, control, or understand.

Yes-less /w doubles = The benefits of Yes-less are gain only by using test doubles (e.g. mock) and interaction based testing.

Yes-reuse = Because test fixtures can be reused to test all subtypes.

After studying the table I noticed two things. It pays to have less to work with in a test. That is to say that when there are very few types and members involved in a test it will be easier to understand. It is easier to observer and control less than more. When you can’t have less it pays to have a test double.

It seems there two general fulcrums that you have to control testability. They are decreasing the surface area and type population or introducing test doubles. As well, they help in increasing the effectiveness of unit tests by eliminating failure points other than the test subject.

Straight from the source:

THERE SHOULD NEVER BE MORE THAN ONE REASON FOR A
CLASS TO CHANGE.

What is a Responsibility?
In the context of the Single Responsibility Principle (SRP) we define a responsibility to be “a reason for change.” If you can think of more than one motive for changing a class, then that class has more than one responsibility. This is sometimes hard to see. We are accustomed to thinking of responsibility in groups.

The SRP is one of the simplest of the principle, and one of the hardest to get right. Conjoining responsibilities is something that we do naturally. Finding and separating those responsibilities from one another is much of what software design is really about.

SRP has the broadest relationship to testability out of all the OOD principles. It relates to all aspects of testability; Observability, Controllability, Understandability. To test something you must be able to observe or sense that it did what it was supposed to do. To test something you must be able to control or manipulate it. Control is needed at the very least to instigate it to do the thing that you desire to test. In the case of unit tests and some other testing the control will be used to isolate the test subject. To test something you must be able to know: What needs to be controlled and observed. How to control what needs to be controlled. Lastly what the out come should be.

The fewer the responsibilities of the test subject the less that needs to be; observed, controlled, and understood. Chances are the fewer the responsibilities the less surface area the test subject will have. As well the less need to have interactions with other types. This reduces coupling and the type population tied to the test subject. All this effects testability.