Revolution is social invention

I'm planning to write a series of blogs regarding systems thinking. To research this topic, I came across the various blogs of Ron Davidson - where I found this quote:

"If I were to ask you to name some technological inventions that helped us to become modern, you could probably name quite a few – things like the printing press, the steam engine, the automobile and the computer. But if I were to ask you what social inventions helped us to become modern, you might pause. We are less inclined to think of things like schools and universities, banks and corporations as inventions and yet they are. Our social institutions and customs are at least as different from what they had in medieval times as is our technology.

When a technology inventor comes up with a radically new product, they call it an innovation. When a social inventor like Martin Luther or Thomas Jefferson comes up with a radically new institution, they call it revolution."

At ThoughtWorks we talk about "Revolutionizing the IT Industry". When we say this, we are not just talking about new tools or new methods, but about an innovation in thinking within the industry itself - and in the organisations that use IT in their business.

Business Benefit

In Agile software development, we often say that a story is about describing business value. This might seem pedantic, but I've come to think that is wrong.

What a story is doing is describing business benefit. This is the benefit a business will get if they implement the story, and might include any of the following:

• Reduction in cost.
• Increase in revenue.
• Compliance to regulations.
• Increase in productivity.
• Learning and new knowledge created.
• Removal of risk.

Obviously, obtaining any of the benefit of a story will require work. This is the cost, and consists of:

• The cost to develop. This can be predicted from the estimate and the velocity of the team.
• The cost to support. This is ongoing cost that will have to be paid to support the feature described by the story (eg. hardware, regular maintenance / manual intervention, etc).
  

Knowing both benefit and cost, we can then determine value. In simple terms, value can be described as a relationship between benefit and cost:

value = benefit / cost

Value can be increased by either increasing the benefit or decreasing the cost. Thinking about benefit and value in these terms makes it much easier to understand prioritisation of stories - you simply do the story that has the highest value first.

Principles of Feedback

One of the most powerful ways you can effect improvement is via feedback. I definitely consider that any team that actively engages in regular effective feedback is likely to be much more effective than one that does not.

So what is effective feedback anyway? At ThoughtWorks, we believe feedback should be given for only two reasons:

1. To strengthen confidence of the recipient
2. To improve effectiveness of the recipient

If feedback is being given for any other reason, it's likely that it's not feedback but rather criticism.

As a giver of feedback, you should observe the following principles:

• Feedback is for the benefit of the recipient only - be receptive to their needs.
  
• Focus on key behaviors (not assumed attitudes or values).
• Be specific - give examples of observed behavior.
• Be non-judgmental.
• Be balanced (positive and negative).
• Ensure the feedback is manageable (not too many points or details all at once)
• Ask permission to give feedback and find appropriate timing.

As a receiver of feedback, you should observe the following principles:

• Actively solicit feedback - feedback is your real chance to improve, so seek it out early and often.
  
• Assume that the person giving feedback is trying to help you.
  
• Listen - hear both positive and negative.
• Ask questions to clarify what is being said - make notes.
• Require behavioral feedback - if feedback is about attitudes or values, ask for specific examples of observed behavior.
  
• Acknowledge - confirm that you have heard and understood.
• Do not defend - reflect and look for themes.
• You do not have to act on feedback.
  
• Accept feedback as the (legitimate) view of the person offering it.
• Be open to doing something different - you can ask what it might be.
• Say when you have had enough.
• Thank the giver of your feedback.
  

Twelve Principles of Managing Change

Today, whilst reading up on systems thinking, I stumbled over the "Twelve Principles of Managing Change":

1. Thought processes and relationship dynamics are fundamental if change is to be successful.
2. Change only happens when each person makes a decision to implement the change.
3. People fear change it "happens" to them.
4. Given the freedom to do so, people will build quality into their work as a matter of personal pride.
5. Traditional organizational systems treat people like children and expect them to act like adults.
6. "Truth" is more important during periods of change and uncertainty than "good news."
7. Trust is earned by those who demonstrate consistent behavior and clearly defined values.
8. People who work are capable of doing much more than they are doing.
9. The intrinsic rewards of a project are often more important than the material rewards and recognition.
10. A clearly defined vision of the end result enables all the people to define the most efficient path for accomplishing the results.
11. The more input people have into defining the changes that will affect their work, the more they will take ownership for the results.
12. To change the individual, change the system.
    

In software consulting, we're constantly dealing with change. I've been sub-consciously aware of many of these principles already, but it's nice to see someone has written them down.

Do the smallest thing that adds value

So I've finally started a blog. I've put this off for a long time and I finally realised it's because I'm a hypocrite.

Everytime I think about setting up a blog, my thought process goes through the following steps:

1. I want a blog (to inflict my thoughts on the world).
2. I have my own domain (leishman.org) so I would really like people to find my blog using a hostname in this domain. This would be easy if I had my own hosting.
3. Oh - I've also been thinking about playing with some rails apps and other technologies and it would also be great if I had my own hosting to run these on.
4. So I better find my own hosting provider.
5. There's a billion different hosting providers out there, so I better survey my friends/colleagues to figure out what is flavour of the month.
6. After getting a dozen different opinions, I need to google them all and decide between them (based on cost, features, reliability, etc).
7. Then I need to sign up and set up my blogging software and start blogging.

I usually get as far as step 6 where I spend a few hours researching. After this I've always remained undecided and just put it off until a few months later - at which point I start again from step 1.

What I'm forgetting in this project is something that I spend every day at work thinking about and evangelising. As a consultant for ThoughtWorks, I too often come across customers with a big list of 'needs' (aka requirements) that they believe they want done. A traditional (and naive) approach is to accept this and go off to work on delivering all these needs and not report back until they've all been satisfied. At which point the needs of the customer have, in many cases, partially or even totally changed - or you've used up all their money before giving them anything of value in return.

Instead, what I do is try and understand what single 'need' I can deliver for the customer, right away, that is as small as possible and still gives them value in return. By quickly delivering something to them I mitigate the problem of changing 'needs' and I start giving value as early as possible. We call this "Do[ing] the smallest thing that adds value". And to encourage not spending effort now to add in extra stuff because it might be useful in future (if needs don't change) we use the term YAGNI (You Ain't Going To Need It).

I'm getting myself stuck because I'm speculating about things I might need in the future and I'm spending time and effort dealing with these speculated needs when I don't get any immediately obtainable benefit. Maybe I'll never get around to needing somewhere to host rails apps. When dealing with myself as a customer, I forgot YAGNI.

Now I've finally realised my mistake. So I've decided to "do the smallest thing that adds value", which is just step 1 - get a blog. I've gone to blogger.com and signed up for a simple, free blog and 15 minutes later here I am. Does it satisfy all of my 'needs' as I currently imagine them? No - definitely not. Does it give me value? Yes - here is my first blog entry.

And, now that I have some value, it's time to look at step 2 (using my own domain name).