Recently I stumbled upon John Maeda’s book: The Laws of Simplicity.

He has a very interesting take on Simplicity. In this book he describes:

TEN LAWS

1. Reduce – The simplest way to achieve simplicity is through thoughtful reduction.
2. Organize – Organization makes a system of many appear fewer.
3. Time – Savings in time feel like simplicity.
4. Learn – Knowledge makes everything simpler.
5. Differences – Simplicity and complexity need each other.
6. Context – What lies in the periphery of simplicity is definitely not peripheral.
7. Emotion – More emotions are better than less.
8. Trust – In simplicity we trust.
9. Failure – Some things can never be made simple.
10. The One – Simplicity is about subtracting the obvious, and adding the meaningful.

THREE KEYS

• Away – More appears like less by simply moving it far, far away.
• Open – Openness simplifies complexity.
• Power – Use less, gain more.

I found some slides which are also interesting:

What do you do when your team/company is all excited to be “agile”, while your customers want to operate in the traditional, heavy-weight, documentation-driven approach? Every now and then I run into Customers or companies dealing with Customers who insists on writing pages of requirement document, with specifications as vague as the night sky, insist on accurate estimates (oxymoron) on turnaround time at the moment of document handover and to not be involved again until they receive the software they asked for?*

IMHO this is one of the biggest issues teams face when they want to use more Agile ways to deliver software. I’ve been in similar situation and sometimes have been able to influence the customers to collaborate more. Sometimes I’ve not been able to. Following tricks have worked for me in the past:

1) First and foremost, it’s worth understanding why they are opting for this approach. In most cases it turns out that they don’t trust the software team and hence they want to push all the risk to the software development side. May be they have burnt their hands in the past. May be their hands are tied. Or may be they are just ignorant of the fact that this is an extremely sub-optimal way to build software. Seeing the world from their point of view, helps me understand where they are coming from. If one is able to see the underlying driving factor and break that bubble, things can get lot more constructive. For Ex: if Risk is the underlying factor, showing them how risky their approach is, can turn things around.

2) Sometimes during the scope discussion of the project, I’m able to highlight things that they’ve not thought through. Sometimes I’m able to hit the nail where it hurts the most. Immediately, the customer moves from a stand where they were saying “We know it all, just build this” to “This piece, we are not sure and it might need a little more work, but rest of the stuff you should be able to plan & estimate”. Slowly through these discussions (couple of hours) you highlight enough such instance, to point out the fact that, there are lots of uncertainties. Also you highlight the fact that we can make assumptions and move on, but it could lead to rather adventurous ending. At this point, I pull some of the biggest project failure case studies and show them how adventurous the ending might be.

3) Sometimes, I start off saying,

I’m sorry, I’m not good enough for this job. You need an expert, who have implemented the same project many times before and is extremely desperate for work to agree to your terms of project execution or you need someone who is an expert at acting to make you feel like they are in control.

I also add saying,

It does not appear to me that your are building a software project for the first time. So if you look back at your past experience, how has this approach of building software really worked for you? Be true to yourself. Were you happy with the results? Did you feel it could have been lot faster and costed a lot less? Also did you feel the team could have come up with lot of innovative, valuable ideas in the project?

Sometimes these questions shake them up a little. At this point, they want to hear more. Its very likely that you’ve touched upon some of their fears and pain points.

4) I also bring to their attention that, I’ve worked for a lot of companies who will go with the traditional model, but put a serious (expensive) change request process. They know that on an average sized project 20-40% requirements will change as the project continues. (There are graphs that show this very clearly.) Software companies typically use this approach as a way to teach their customers a lesson. And on subsequent projects or mid-way through the project, the customer agrees to collaborate more instead of tossing it over the wall. If the customer still does not agree, heck what, you make good money through the strict change request process.

5) At this point, hopefully they are slightly more open to listening to you. So I propose that we start-off with a week or 2 week inception phase to flush out some of the uncertainties and to bring everyone on the same page, so we all can agree upon the common goals. Depending on how important this project is, we price the project inception piece of work accordingly. Sometimes even free. During the inception phase, we do some brainstorming about what we need to build, how it’s going to affect/help endusers and businesses, we build some models, we build some working prototypes, etc. This helps the customers experience the value of collaboration. (It’s like the trailer of the movie.) In my experience so far, most customers see the value, we are able to build some trust and respect for each other and we are really set to build a project using agile methods.

6) After all this, if they still don’t see the point, I tell myself,

Life is too short to waste time on such projects. Time to find a new project/customer. In fact life is too short to build products for others. Its high-time I build my own products.

Interestingly, I’ve had some customers who understand all of this stuff and tell me that the main reason they don’t want to collaborate is, they fear they might get attached to the project. And will not be able to take objective calls. This is a valid point. When I cook something, it always tastes good. Even if it does not, I keep trying to make it taste better. Hard to draw the line. In case of software projects, we can work out strategies so customers are able to collaborate but still take objective calls when they need to.

* This question was asked by Stephen Walters on the Agile Alliance LinkedIn Group.

What do we, as agile Coaches, value? What is our value system?

I value:

• Respect and Trust
• Transparency and Open communication
  • This works both ways. As a coach you want to show them that its OK not to know something. You certainly don’t know everything. But you are willing to learn.
• Safe-fail experiments
• Being hands-on and in the groove 
  • Second-hand information and knowledge can only take you so far
• Down-to-earth, humble attitude
  • Being one amongst them.
• Joy of improving things one baby-step at a time
• Motivation and self driven
  • Lead by Example
• Continuous learning and putting ourselves out of our comfort zone
  • I care, I’m here to help make things better and learn in the process. I’m not here only for the money.
• And so on…

As a coach, my goal is to help people evolve their thinking to be more “agile/adaptive”. Building great software is only a part of it. Agile/Lean thinking applies and shows in lots of ways even outside software. And in lots of cases I’ve seen that when people start applying these values in other parts of their daily lives, they get a much broader and deeper understanding of this thinking process.

Few years ago, when I was a consultant at ThoughtWorks, people used to ask me, what was my job like. I would respond saying, “My job is to set up small ‘safe-fail‘ experiments for my team.” Learning from one’s mistake in a controlled, safe environment is the best form of learning according to me till date. It has a much long lasting impact. Almost always, this really helped me evolve my understanding of how agility can manifest itself.

When it comes to Coaching, there are different styles. What style you can use depends on:

• Your strengths and weaknesses. By your personality. 
• The team & individuals you are coaching.
• Whether you are going in as a coach or they (the team) is coming to you for coaching.
• The short-term and long-term needs of the team
• And so on….

Over and above all, to be effective at coaching, one needs to win the trust of the team. Trust is very important. If the team does not feel safe in your presence, then you can’t be effective at coaching. I strongly emphasize on building trust and gaining respect quickly. This in-fact would be my first goal as a coach.

No amount of process can fill-in for lack of trust. IMHO one needs to focus on building trust and creating an environment with low viscosity, process will automatically fall in place.