Some thoughts about Toronto Agile Open space 2016

Here I just try to write down some of my thoughts about yesterday's Toronto Agile Open Space
1. I did another session: it was about the theory of constraints thinking process, I love it because I believe it will bring Agile community 2 important things: Scientific method  and problem solving tools. At the beginning I feel it might be too dry, but Shawn Button and Thanou encouraged me and told me it might be intersting, so I picked one empty space, and lobbied Thanou joined my session, and later 3 more audience showed up (Jim Rootham, Lee from Intelliware and an other TOC guy). I explained them the overview about the 5 thinking process diagram, looked like they got some ideas.
This is the the over view of the TOC thinking process I hand out to the audiences. all my talks are based on it.

 What I learned from this is Just Do It - there is no bad topic or good topics, as long as some one attend your talks, then it is a good one.
Next step what I need to work on:
 - Trying to practice it in daily work, collect all the scenarios I met and write them down into thinking process diagrams, and hopefully I can give them a name if possible. I assume all the software Scrum team will have similar issues I faced, if I created my diagrams, then it will more likely become a general solutions.
 - Share with other Agile coaches.

2. The most important thing I feel so pleased is there are more topics about technical side, for example: Thanou, Peter Yu, Paul, and Shawn Button all facilitated excellent sessions. I really appreciate them drew so many attentions. Also I was surprised that I met a lot more developers in the conference than before. This is definitely a good sign that technical side of agile is resurrecting.
This finding definitely inspired me to focus on the technical side of Agile. In future I will focus on my work on the growing Agile developers. If I have a chance to bring talks in future, my topics will focus on:
- What are the essential skills for the Agile Developers?
- How to become the a successful Agile developers?
- Transform from geek to technical leader
- Create Developers Guild and mentor ship in Scotia bank.
-  Software craftsmanship movement: define the ethics, code of conduct, and disciplines.
- The learning path of a software craftsman
- Mastery: what can we learn from Samaurai, Myamoto Mushashi and Shushi Master?
- Drefus/ Shu-Ha-Ri learning models

- The strategies for refactoring ( Mikado Method for example)

- How to convince people to practice TDD?

Making your calendar half full

During last 2 weeks, I found my calendar was really full, many back to back meetings. I feel busy but not productive.
I found the biggest problem is hard to deal with unplanned things: sometime a developer asked for help, but I was not available at that time according to my calendar; sometime when a meeting need to change, but due to hard to find another time, it had to be cancelled or delay to next week; sometime I found an issue and want to discuss with my Product owner, but she was not available, we have to wait until next week to discuss it.
So making my calendar full is really harmful:

• it is hard to respond to change,
• hard to solve the problem quickly,
• making co-location less useful if everyone is busy with doing different things.
• it focus on activity not outcome, it violates the Scrum's "inspect and adapt" principle.

In future I decide to change my strategy, instead of making me busy, I will try to make my calenar half full:

• only half of my time can be scheduled for meeting in the morning;
• only half of my time can be scheduled for meeting in the afternoon;
• try not to schedule back to back meetings 

Also I will encourage other team member doing the same thing, especially product owner and people with shared roles like me.
and also our scrum team can also considering make the board half full.
I hope it will help me:

• will be more responsive to unexpected situations;
• will have less waiting time on fixing the problems;
• will be more adaptive and more focused;
• will be easier to coordinate with other team members if they are doing the same thing;
• improve the collaboration;
• help me focus more on effectiveness instead of efficiency;
• have more slack time, so I can focus more on learning and researching.

What I learned from the Lean startup training

Earlier this January Our Agile coach Carlos Oliveira did an excellent training session about Lean startup in Scotiabank's Credit Card RapidLab, for me this is eye-opening event, I realize there are so many things needs to digest, to dig deeper. Here I try to capture what I learned.

About Lean startup
Lean startup process is focused on discovery, learning, reducing the uncertainty through the rapid feedback loop. It is more about exploring instead of exploiting; it answers the questions of "Should we build it?" instead of "Can we build it?".
In lean startup, failure is good, failure is valuable, as long as we can learn from the failure; learning itself is valuable, MVP does not have to be valuable to the customer - which means in Scrum, at the end of the Sprint, it is still OK if we delivered something which is only valuable for ourselves learning but no value for customers.

Learning vs building
In lean startup the objective is learning, to learn we need to build first to validate our hypothesis, which is build to learn; in regular development, the objective is building, to build a better software, we need to learn first, which is learn to build. It looks like learning and building can support each other instead of conflict each other if we can embed the lean startup concept into our Scrum process.

Go out of the building, leave your comfort zone
Lean startup encourage us to close to the customer: go out of the building, learn from customer. It means leave your comfort zone, be open minded, leave your predefined opinions, discover different insights and experiences.
For managers, it means manager shouldn't rely on emails, report or spreadsheet, they should go to the team, listen, observe and sense the problem.
For team developers, it means everyone should leave their own familiar domain area, try different tools, lean different languages, take different roles, do it mindfully and deliberately.

In the book Toyota Way, I know an inspiring story about the improving the Sienna by applying principle of "Go and See",  this blog post gives you a brief summary.

How can I apply Lean startup into my daily work
As a technical coach, my customer will be the Scrum team members, my job will help the team apply new tools, technical practices which moving toward the journey of continuous delivery. There are lots of uncertainty and concerns, to reduce the resistance, lean startup is a perfect strategy for me:

• Close to the team members: sit beside them, observe how they work, listen their conversation, sense their pain, work with them, don't wait for them asking for help; go to other teams to get insights,
• Close to the product owners: Attentively participate the Sprint plaining meeting, meet with them regularly, understand their business goals, trying to help solve the product owner's problem first, then ask them to help me.
• Doing experiments as strategy, for example for automated functional tests, I will try to offer different solutions, and compare each solution's pro and cons; for reporting tools, I will try different solutions as well.
• Instead of doing the whole team wide changes, I will focus on small group of people, each time focus on one single solution, focus on one specific area.
• Find early adopters like DevOps Champions within the team to help me.

Some thoughts about learning
Learning is my favourite topic, this Lean startup training inspired me to summarize some quotes about learning:
 - Software is a discovery process
 - Deliberate discovery
 - Learning is the first class task for developers
 - Learning is the constraint
 - Learn early, learn often, learn from failures

It also remind me Alistair  Cockburn's article about "Disciplined Learning", which is a great reference.

Resources:
- Alistair Cockburn's learning patterns
- Toyota Sienna's "Go and See" story, and this

Fearless change - my presentation in Toronto Agile Open Space 2015

On June 6th I participated the Toronto Agile Community's open space event. it is a whole day meeting following the format of open space. This is my second time, and I feel more confident to contribute a presentation. My topic is called "Fearless change - how to drive technical changes in large organization". it covered Linda Rising's book "Fearless change", and how I get inspired and applied some patterns to guide me build the RobotFramework community in TELUS. Now I would like to share my experience of this presentation.

Preparation
I treated it seriously because I feel this is a great opportunity of practicing my public speech. Thanks Toastmasters club gave me the courage.
 - A month before the meeting I asked the advice from Joanne Stone, she gave me the positive feedback, also provided some tips.
 - On the day before the meeting, I printed out the 10 copies of 48 patterns list, and 10 copies of the colorful mind maps based on the book.
 - I brought the paper book with me.
 - I brought the mind map of my presentation note.
 - I wrote down the names of the patterns on the Post-It note and brought with me.

Presentation
Before the meeting I met Paul and asked him some advice. also I met my colleague Dimitar, I asked him help me facilitate my presentation. It turns out he was one of my best audience.

During the presentation, I introduced the book of "Fearless change" written by Linda Rising. I tried to provide the answer of this scenario: when you learn a new tool or idea from internet or conference, how you can promote them in your organization, where can you start?  The answer is using the 48 patterns in the book, they are easy to follow, very concrete and actionable. I can apply to anybody who aspired to bring changes to the team or organization, especially those are powerless, no official titles. I gave the example how I use some patterns to guide me build the RobotFramework automation testing framework in TELUS. I covered the following patterns:
- Evangelist
- Just Do it
- Connector
- Early Adopter
- Study Group
- Ask for Help
- Involve everyone
- Dedicated Champion
- Do food

One of my favorite pattern is "Just Do it" - it means don't wait for permission from your boss, just do it, DON"T LET YOUR BOSS KNOW. when you get experience and successful, then tell your boss. My experience is if you ask permission to your boss first, he will ask you several questions: What is the benefit? Pros and cons? How much time/money it will take? But since it is at the beginning, you will not able to answer those questions, then you boss will likely say NO, once  he say NO, then you will not be able to work on it. This is Catch-22 problem, to prove its benefit, you need to do it first; to do it, you need to prove it is valuable. So the solution is "Just Do It"!

Retrospection
The feedback from Dimitar was positive, he likes my topic and hand out of the mind map. I believe I am the only one to prepare the materials hand out to the audience.
I found I can still make it better: firstly I chose the wrong room, which is too far from the main hall, limited my audience; secondly I need to provide more information, like the website of the book, and url of the mind map image, and my personal email address, etc.

Next Steps
I felt very good because I feel I can contribute something to the Agile community. A great starting point. In future I am interested in the following area, and hopefully I will provide more topics for the next year:
- Software Craftsmanship movements and coding dojo
- Self-organizing team, what/why/how
- build learning organization
- build cross functional team
- To sell is human (from Daniel Pink's book)

Resources
1. Linda Rising's book page 
2. The url of fearless change mind map

Review of the talk: "Complexity is Outside of the Code"

Broadcast live streaming video on Ustream

Yesterday I watched the video: "Complexity is Outside of the Code" by Dan North and Jessica Kerr at craft conference 2015.  Here I summarize what I learned.

Learning

• Learning is a first class task.
• Follow the process: explore, evaluate, familiarize, understand and validate
• Lean startup's "build-measure-learn" cycle, nothing should be built without any reason.

business impact <- learn <- measure <- test <- code

Dan uses the Kanban's pull based concept to describe the above concept: for example test pulls the code, business pulls the learn. This drives me to think more about TDD, in TDD we believe we should never start coding without a failing test.(Uncle Bob's 3 laws of TDD),  which is quite similar with the lean startup concept: "nothing should be built without any reason",  in TDD, the failing test is the only reason for coding, which means the failing tests pulls the code, Bingo! Now I understand why Kent beck said TDD is Kanban for code


The Goal of software development

The goal of software development is to sustainably minimize lead time to business impact

Develop a supportive community

• Nurturing a supporting team is vital within software development
• It is OK to point out bad things and not have a solution
• Reduce specialist silos, encourage becoming generalist
• Developing a supportive community, contribute open source to other teams

Resources
http://www.ustream.tv/recorded/61439914
http://www.infoq.com/news/2015/04/north-kerr-complexity-code
http://www.slideshare.net/jessitron/complexity-is-outside-the-code

Book review for "An Agile Adoption and Transformation Survival Guide"

Recently I read an ebook about agile called An Agile Adoption and Transformation Survival Guide from infq.com, it is written by Michael Sahota. It is really a good book, bring lots of useful insights and information.

What I learned most is the author provides the concept of adoption and transformation for agile.

• Adoption is about "doing agile", treats agile as a process or product;
• Transformation is about "being agile", which means we has the agile mindset.

So I learned that adopting agile without agile mindset transformation is doomed to failure. That would explain why Scrum is so difficult to implement in many companies, because most of them just adopt the Scrum practices, but did not transform the agile mindset.

Quote from the author: "Agile is not a Process – it Defines a Culture, Agile Culture is about Collaboration and Cultivation" So we need to create a culture to help us adopt and transform the agile.

This is a very important concept, culture is more important than the practices. Before I learned that agile is not enough just by following its practices, we need to do something more. This time the author explicitly pointed out the concept of transformation, and concept of culture. We can not treat agile as a set of tools, we can just pick one of them like buffet, the more importantly, we need agile mindset change and culture change.

To help you transform from the existing culture to the agile culture, the author provides different paths, patterns and models, that is the reason why it is called "Survival guide".

Another reason I like this book is it brings you lots of useful models, I already know some of them, but I did not realize the author could integrate them such nicely. I just list some of them:

• Schneider culture Model 
• chasm
• hype and disillusionment
• Fearless change
• ADAPT
• Containers, Differences and Changes(CDE)

Summary
This book has lots of information, I highly recommend any serious agile practitioner to read it, you will learn a lot.To make agile successfully, We definitely need change from 'doing agile' to 'being agile'.

Resource

1. Book download link from infoq.com
2. The author's blog about this book
3. The author's web site: agilitrix.com

My worst performance review

Recently my current company started the quarterly performance review. This reminds me my last performance review two years ago in my former company - QuickPlay Media Inc. I believe that was my worst performance review in my life, because of that reason I left that company.

The whole process was terrible, some time when I recalled it, I still feel angry, ridiculous, and nonsense. I will try to write it down because I want to remove it from my mind.

 I remembered 2 years ago in QuickPlay, my performance review  process was terrible: the review was totally depends on manager, there was no quarterly checkup, no objective metrics, each employee's performance is relies on the manager's impression. If she likes you and give you a good project, then you will get a better performance, on the other side, if you work on a project which is outside the scope of your boss, then you are doomed, because he/she did not know how you worked. This is totally unfair game, and for each employee it is the only time you have a chance to get promoted or salary increase.
 My manager's name was Donna, unfortunately I did not work on her project, and also she did not like the way I was working, I am not the guy always say YES to the boss, I have my own brain and I have my own principles. I know that I might not get a better rate, but I did not expect that my final rate was so worse.

I can feel her bad attitude at the beginning, because my meeting was cancelled and rescheduled so many time, finally it was delayed for 3 months! This was totally unprofessional for a manager, and she never show some apology to me for that.

During the performance review, I can feel she did not like me, the meeting is one way instead of 2 ways. She controlled the talking, most of the time she was talking and I was listening, actually I would say she was announcing, and did not give me any chance to explain. I prepared lots of my thoughts, but none of them were discussed. She tried to give me a low rate for every check point based on her bias, she tried to prove I am a bad developer. because I did not follow her order just once, and she wanted to punish me. It looked like she collected all my mistakes quietly in the behind, save them for one year, then presented all of them to me. Is this a good way for a manager? This is totally wrong, a manager's job is try to improve her team members, once she found an issue, she should take action right away, either criticize him or help him to realize his problem, help him to fix the problem. A manager's job is to correct developer's mistakes, not collecting mistakes. Manager is not like police, her job is just issuing an parking ticket. She need to figure out why the employee made an mistake, provide solution, and make sure the employee is improved. We are human and easy to make mistakes, that is the reason why we need managers.

The main issue she mentioned was I got negative attitude, because I report a issue of my colleagues quite angry. I agree I did not have good attitude at that moment, but so what? You should focus on the issue first.  I found very bad issues and I feel I need to stand out and want manager to fix it. I exposed the problem in the team, and this is a good chance to fix them. My manager should ask why I had a bad attitude, because she need to find the root cause and fix it, I believe the manager's job is to fix the issue among the developers. I don't think hiding/cover up the issue to your colleague is good, avoiding conflict is teamwork, and just focus on remaining the surface of agreement is a healthy team. Unfortunately my manager even did not want solve this issue, looked at what she said: "Why did you say bad to him? Because he did not say anything bad to you." What? I don't know what to say it.

It was really made me angry was for all of her comments/feedbacks, I did not know how to solve them. When I tried to analyze them and want to improve them, I found they were all no actionable, which drive me crazy. I know the solution was: follow her order, always say YES, you should not have your own ideas, just compliance, that is it!

It made me into deeper thinking: what is a good employee? Just always say YES, always nice to other people, not to stand out when finding a problem? Of course NOT.

This performance review totally lost its purpose: set goal, identify the issues and improve them; it becomes a means of manager to control her team members. It will look for compliance. It becomes a tool of governance, not for management.


I understand this would be the common issue of the command-and-control management style, the result will be always the same: mediocrity, compliance, lack of innovation.

Now I am happy in my current company, we do performance review, but quite different: we have 360 degree peer review, and quarterly review. Which are much better than before. I feel I was so lucky because I don't need to do that terrible review any more.

Why I decided to take Scrum training?

Yesterday I registered an Certified Scrum Master training.  I choose the seminar on Jan 12, 2012  from Berteig Consulting.  Actually I am not so interested in SCRUM, rather I am super fan of Lean/Kanban, XP and software craftsmanship.
I have a bias on SCRUM because I feel its process is oversimplified, and focus on manager side only, ignores developer side; and it lack the whole picture of Lean and flexibility of Kanban. Another reason is so far I did not find a good SCRUM example in my past experience, so I really doubt the its performance.
The third reason is recently I found many articles which pointed out the issues of SCRUM.

As a many years of working experience as a software developer, I really doubt a certificate is useful.  I don't think that you will become an SCRUM master just for 2 days training, which means master Agile philosophy is too easy.

But recently I changed my mind, and decided to get a SCRUM Master certificate. You may wonder why I changed my mind so quickly.

Why learn Scrum?
1. I realized that the current IT situation is that  Scrum is still the de-facto process, even though Lean/Kanban is really hot inside the Agile community, but outside of the community, Scrum is still the most popular one. I will say 90% of the IT managers does not know Kanban. They are  more familiar with SCRUM.  If you have a Scrum training or get a certificate, it will be helpful for your career path. My long term goal is Agile coach, so I hope I can use CSM as a business card to help me find better jobs.

2. I hope the CSM certificate can help me make changes in my company. 6 month earlier, I tried to suggest to my managers thinking of using Lean/Kanban, they are familiar with Scrum, but not Kanban. I found I get stuck, because I don't know how to persuade them, since neither I have Kanban experience, nor I have Scrum certificate. Now there are 3 Scrum Master in our company. I hope if I have a Scrum certificate, then I could use their familiar "Scrum" language to communicate, then it would be easier for me help the company to transform from Scrum to Lean/Kanban.

What do I want to know about Scrum?

• Clear the misunderstandings about Scrum;
• Focus on the principles and philosophy behind Scrum;
• Figure out the fundamental assumption which support Scrum;
• Find out the good and bad parts of Scrum;

Cynefin framework and software code

Recently I read some article about Cynefin framework, it is really inspiring. As the diagram shows, cynefin framework categorize the problems in to 4 domains:

• simple
• complicated
• complex
• chaotic

For different domain, the approach and strategy are quite different.
Today I would like to analyze the software code using cynefin framework.

Which domain does software belong to?
In General I will say software belongs to complex domain. One reason is software product environment changes so fast, the other reason is its entropy nature: always grow from simple to complex. Software product is so hard to predict and plan. That is the reason why we choose agile methodology: we follow TDD, keep refactoring, iterative developing and continuous integration. These methods are to deal with rapid the software's rapid changing context.
Let's compare the complex domain with agile practices:

complex, in which the relationship between cause and effect can only be perceived in retrospect, but not in advance, the approach is to Probe - Sense - Respond and we can sense emergent practice.

Here The probe - sense - Respond is same as TDD and iterative development, since we don't understand the domain, so we have to rely on immediate feedback.
And the emergent practice and retrospection, which is the same as refactoring, refactoring itself is emergent practice.

We can also conclude that the reason why waterfall does not working is because they assume the problem domain in software is always in simple domain.  

How about other domains?
If we don't care code base and let it grows, then code base will becomes more and more complex until it becomes chaotic. As a developer we all have the experience of working with messy legacy code base: the messy code is hared to understand, hard to maintain; you fix one issue, then will generate another issue unexpectedly; the software is unstable, a small change will cause a big issue; the issue is always unpredictable;nobody understand the system; we spent all the time putting fires. Which is totally unstable and uncontrollable. These symptoms fit nicely with the chaotic domain model.

But if we keep writing clean code, the code are easy to understand, easy to maintain, easy to change. In agile world writing clean code also means simple design. So this  will fit nicely in simple or complicated domain. Since they are both ordered. so they are manageable and controllable. That is software's ultimate goal -  flexibility, maintainability and reusability. So we will say clean code will help the software reduce the complexity.

Why clean code will help reduce the complexity?
The following tools and method help us writing clean code:

• SOLID principles
• high cohesion/loose couple
• Design patterns
• DRY principle
• LoD principle
• Refactoring

Lets' dig them deeper:
- Break the unnecessary dependencies

   Uncle Bob once said writing software is all about dependency management. SOLID principle, high cohesion/loose couple means reducing dependencies. We all know that the more interactions between objects, the more complex the software will be, so reducing the dependencies means making the software simpler.
- Set Rules and Constraints
  Design patterns basically is describing the rules of the relationship between objects in a specific context. To make software reusable, stable and manageable, we do not allow objects interact each other randomly, they have to follow certain rules. This is quite similar in human society, we have to maintain the orders via laws, rules or regulations. 

- Encapsulate changes

   One of the advantage of design patterns is how it deals with change: encapsulate changes. Which means when we identify a concept which it changes, then we encapsulate it by putting it into a class.  we don't want them randomly change. we put them in a box, isolate them. Once we put those details evil in the box, then we can understand or control the system by using abstraction. Then the system becomes stable, manageable and controllable

Conclusion

• In General software belongs to complex domain. The agile practices are the right practices to solve the complex domain problems;
• Writing clean code will help us reduce the complexity, will move from complex to simple/complicated domain;
• Writing messy code will increase the complexity, will move from complex into chaotic domain, this is what we are trying to avoid.

Strategy
So our strategy will be constantly refactoring our code base, keep code clean, avoid messy code.

Resources

1. Cognitive Edge
2. Systems Thinking and the Cynefin Framework
3. Video by Dave Snowden - Practice without sound theory will not scale

3 types of work - yesterday, today and tomorrow

I found it is useful to describe software developer's daily job into 3 different types: yesterday, today and tomorrow.
Yesterday: bug fix, maintenance job. since this kind of job is based on the product which is supposed to be finished, so I describe it as yesterday.
Today: developing phase, the work on the product is under development,
Tomorrow: some research and R&D work.
These 3 different type has different nature, and they need different mindset and strategy to deal with them.
Let me dig them into deeper.

Yesterday's work
Yesterday's work are bug fixing and maintenance job. This kind of job is putting off fire, they are urgent, and undeniable. We need to fix them ASAP.

Yesterday's work has no value or negative value, because customer already paid us up front, this work is support and service. This kind of job is not adding value, but removing the negative value.
The more time and effort we spend on the yesterday's work, the less value remained for us. The cost of fixing a bug in production phase is much expensive than fixing it in developing phase( today's work).

Yesterday's work is quite stressful. A minor issue delayed in yesterday will cause higher priority work. Yesterday's job is quite critical for time. we just need the job get done, there is no time for refactoring, no time to focus on better design. There is no room for developer to improve the system (code base, design, code quality etc) at this stage.

If there are too many yesterday's work, then this is not a good signal: It means we have a large amount of technical debts from today's work, it means bad design and careless decision.
So yesterday's job is highly dependent on today's work.
Ideally we should keep the number of yesterday's work as low as possible.

Today's work
Today's work is about current realistic issues. Today's work is the tasks which is belong to developing phase. We develop a new feature which is our customer wanted, so this job will bring values. They are urgent and important, but some features can be negotiable. Customer will focus on feature than time, so the time is not so critical as Yesterday's work.
Developer has lots of room to improve the system, he can have time to improve the design, refactoring.

The strategy of today's work will be - Build quality in. Focus on quality over time. If we focus on quality at this phase, then time must be shorten on maintain phase.
Quality means more than functionality, also means maintainability and readability.  We should focus on simple design, write clean code, keep refactoring. and do not easily leak the bug to maintenance phase.

Tomorrow's work
Tomorrow's work is focused on research and innovation. It will bring us potential value in future, so I call it tomorrow's work, means work for tomorrow.

It for a long term goal, we might not realize its value at present. it's important but not so urgent.

Tomorrow's job is like investment. there is a risk, we don't know how much value it will bring us.

Usually the priority of tomorrow's work is less than yesterday and today, if there are too many work spending on yesterday and today, then there is no time for us on investment. But if we did a good job on today's work, then we need less time on yesterday, then we have more time spending on tomorrow.

Mapping to First thing first
I found these 3 types of work map perfectly with Stephen Covey's first thing first :
Yesterday - Urgent but not important
today - Urgent and important
tomorrow - Not urgent but important

Conclusion
Yesterday is your debt, today is your earning, tomorrow is your investment.
We need to focus on today's work, keep improving the quality of today's work.
If we want to be productive, we need to balance these 3 types of work wisely.

Code is constraint

Last week I watched Michael Feathers presentation: Code blindness.This is a great presentation, and it inspired me to think deeper.

Before I think code is important from the programmer's perspective: craftsmanship, and professionalism. But it seems quite far to the managers. They don't know understand it and don't know how to connect this with their daily management.

Today I would try to think from manager's perspective: borrowing the idea from theory of constraints, I will say code is just another constraint, like other constraints manager usually considering: time, budget, people. More specifically code quality will impact developers productivity and on time delivery.

We know that the clean code base will easier to understand, easy to make change, and easy to maintain,but bad code base will hard to understand, hard to change, and hard to maintain, which greatly slow down developer's productivity.To avoid this happens, we have to deliberately keep code lean.

There are two main metaphor to support the clean code:

• Metaphor of technical debt: code base is like technical debt, we have to pay off first by taking effort to refactoring, otherwise it will become harder and harder to change and maintain in future, so refactoring is the interest we pay for the debt.
• Metaphor of software entropy: code base is like entropy, by nature it will gradually go to messy, we have to constantly refactoring and keep our codebase clean.

So we can get the conclusion: code can be asset if it is clean; and can be debt as well if it is messy.

So far we know that code is very important to developer's productivity, it should be consider as a constraint by the manager. But I found many managers are totally unaware of this issue:
They just assume developers are all professional and their code will always good enough;
They only care the schedule, only care something get done, but does not care if the code is well maintained or not.
And since managers unaware or ignore this issue, they might make decisions to make code base even messier, for example,
- they will pressure developer to push them make quick-and-dirty fix, which cause the long term issue;
- They do not care for the code, so they measure the performance only by task been finished, not by how good the code is written, so we can imagine developer will not actively care for the code.

Code is important, but if you unaware or ignore it, then you will not manage it.
If you don't manage it, then you will finally lost the control and then we will get real problems.
When you have the problems, but you don't understand the root cause is code quality, then you probably trying to solve the issue in a wrong way.
I heard so many times from managers said something like "we need to work harder", "we should work more careful", which are totally useless slogans.

Suggestions

1. Manager should aware the code quality's importance, bring the connection between good code quality to developer's productivity and developing schedule.
2. Manager should cover code quality into their daily management, right now there are so many different tools to do code analysis and measurement.
3. Manager should create a culture to encourage software craftsmanship, clean code is a foundation of good software product,  clean code fit nicely the "build quality in" lean principle.

Making developer multitasking is a bad idea

Following is copied from a job description for a mobile software developer from my previous employer QuickPlay Media:

"Well organized with the ability to effectively manage multiple projects simultaneously. Extensive experience in a fast-paced deadline-oriented environment".

When I first look at it, I was really surprised by the word "multiple" and "simultaneously", it is pretty obvious that they requires developers to be able to do multitasking jobs. Today I would like to dig this topic a little bit.

What does "manage multiple projects simultaneously" exactly mean?
- Working project A for 5 minutes, then working on prjoect B another 5 minutes, and project C for another 5 minutes?
- Or when you are working on project A, then interrupt by project B, you have to suspend the project A, then switch to project B;
- Does it mean the developer has more project working simultaneously, the better for his performance review?
- Does multitasking really improve the productivity? get faster delivery?

This idea is totally wrong
In the last 2 years I read a lot books about agile and software craftsmanship, so I am quite confident to say this is totally wrong, it will only make things worst!

Fist it is against human nature. Human is not machine, he is non-linear, a person can only focus on one thing at a time. Interrupt and context switching is very expensive. The book Pragmatic Thinking & learning and  peopleware cover this topic, and explain why managing focus is so important to maintain a higher productivity. and that is the reason why the Pomodoro technique will force you only focus on one task in each 25 minute session. Managing people's focus is the key of improving his productivity.

Second it is against the agile principles and and other proven theories. The goal of agile is to deliver the product as fast as possible, but the interesting thing is the agile trying to reach this goal by limiting the Working-In-Progress items (WIP).  Scrum is trying to limit WIP in one iteration, WIP is called inventory in Lean, which is a waste and should be limited. Limiting WIP is the key concept of Kanban technology. and in theory of constraints also proved that putting to many task in the queue will only slow down the productivity.The reason is pretty obvious, think about this scenario, if you have 3 projects, each will take one week. If you work sequentially, you will deliver one project after 1 week, 2 projects after 2 weeks, and you will get 3 projects after 3 weeks. But if you work simultaneously, you will get any project done until after 3 weeks, but considering the context switch cost, it will take you longer time to finish all 3 projects. So based on Scrum, or Lean/Kanban, or Theory of Contraints,  working simultaneously will not deliver fast, it will only delay the delivery time.

Third is it is a shift burden to from mangers to developers. Managing backlog is manager's responsibility, but requiring developer multitasking means putting some more backlogs into developers. It might looks better for managers, but actually it is bad, since those extra backlogs are either under working or putting into developer's own backlog. This is actually hide the visibility, which is even harder for manager to track the progress. I can feel that the multitasking is a solution which managers are trying to solve too many backlogs, but it is a bad idea, since it only move the backlog from manager layer to developer layer, which making things even worse; the manager should figure out the root cause and find a true solution to increase the burden down rate or increasing the productivity. I like to call this issue is leaky management issue(copied the idea from leaky abstraction from OO design), because it is supposed to be solved in the management layer, but it leaks to the developer layer.

Based on the above analysis, I can feel multitasking will generate following result:
developer will have low productivity, projects will get more delayed, developer have to work harder and over time; since more projects get delayed, so manger put more projects to developer to work simultaneously, then becomes a positive feedback loop, which will make things even worse...

Summary
I feel very sad for my old colleagues, because they are not treated well;  and I feel sorry for my ex-managers, because they are unaware of the basic principle of agile. To make a developer working efficiently, the only thing is trying to make him to work on one thing only. I strongly suggest QuickPlay to remove multitasking in its job requirements, but removing that from managers minds are much harder.

Becoming generalist - dealing with constraints in software development

Recently I read the fascinating book - the goal, it is really an eye opener for me. I learned the theory of constraints from the book. Everything of TOC looks like common sense, but the conclusion is really striking.

TOC tells us the importance of bottle neck (constraint). We need to identify it, and protect it. In the example of manufacturing assembly line, to make sure the task in bottle neck is the highest priority, other jobs even have to be idle instead of working, otherwise it will make the whole productivity even worse!

I believe TOC can apply to software development as well: because the software developing also needs a series dependent activities. And similar to manufacturing, software development also has constraints(bottlenecks), it might be in: test,coding,deploy,maintenance. On the other side, compared to manufacturing, software development is people centered vs. machine centered; most of the constraints is about people; software process is lot easier to change compare to assembly line.
In software industry, we could have a big advantage over manufacturing: to deal with bottleneck, we don't need put other people to sit in idle, we can put more people working on the bottle neck! But this advantage depends on a requirement - if our developers are generalists.

If every developer in a team is a generalist, which would be a great help to maintain a high productivity, then we can deal with almost any constraint, since when there is a bottleneck, we can put more people on it. So the developing flow will be well controlled in a high productivity speed.

Becoming a generalist raise the bar for developers: we are not just a geek who focus on a single area, we are not only J2EE developers, but we also need to fix the bug of a J2ME application; we might need to mange data base as DBA; or improve the build system by writing Ant or shell script.

Becoming a generalist is really challenging, and much harder than focusing on one single area. But based on my experience, software developing job is not a rocket science, every technology can be learned if given an enough time. Technology is not a problem for becoming a generalist, the problem is attitude and mindset. We need to be open minded, be flexible, and ready to wear different hat at different context.

A generalist has following benefits:

• Doing different jobs, give developer a chance to learn different new technology and tools, learn by doing will make you learn faster.
• Have chance to know the big picture of your work.
• Better for team work and collaboration
• Improve your competence and marketability, since you can put more stuff on your resume.
• More changes to become linchpin and less likely being laid off, who wants to fire a developer who can do multiple jobs?

I will suggest our managers should encourage developers to become generalist. For example, he can deliberately assign different jobs for one developer; rotate developer to another team; foster pair programming and mentoring, etc.

Can software be estimated?

As a software developer, I am always asked by project managers:How long do you think you need to finish project X or fix  issue Y? Most of the time I feel annoyed and guilty, because usually I don't really know the answer but I have to give them  a number - which is far from accurate.

I believe how to get a good estimation is one of the major issue for all the developer and managers. An accurate estimation help manager control and plan the project, which make sense. But it is based on an assumption: the software can be estimated. Is this assumption really true? Let's investigate it.
First, if we assume software is estimatable, => then we can see software is predictable, => then we can plan ahead, => waterfall model. We all know that waterfall and CMM is not workable, try to harden the software project is myth.
Next, let's check the software development model. From Lean/Agile software development we know that software is a discovery process, an explorative process, a theory building process, an process of reducing ignorance level. In summary, it is a learning process, the problem solving process itself is also a learning process.  That is why agile uses iterative, feedback process. Which means at the beginning you know very little, you only understand the problem when you solve the problem at the end. So how could you estimate or predict at the beginning? How could you give an accurate estimation at the beginning? You can predict only if you know all the variables, but in software development, there are so many unknown variables: third party library issues, platform compatible issues, IDE, target constraints, etc and other issues you might not aware(you don't know you don't know). So based on analysis the above , we can say estimation in software is impossible.

Let's look at another question: can we estimate bug fix? Bug fix is also a learning process, especially when you are assigned a bug which code base is not written by you. You need to take time to understand the bug, reproduce the issue, understand the code base, familiar with the context, all this stuff are learning process and takes time. How can we estimate this time, because this is really case by case. And we all know that bug fix is actually we spend 90% of time on finding the bug, another 10% time on fixing the bug. Once we found the bug, we know how to fix it. So we can only see we can estimate the bug only after we found the bug, but at this moment it is pointless to give an estimation since we already solve the 90% of the problem.

I would like to share my own experience:In an iterative development process,  there is no need to estimate, just do it. Before I start fixing a bug, I knew nothing; the time I know the estimation answer is when I solve the issue, so the process of finding the answer of estimation is the same process of solving the problem. So at this case why we need the estimation?

 So we know that software nature is impossible to estimate and needless to estimate. But why project managers need it? Maybe they don't have technical background and still trying to use the concept of waterfall methodology; or maybe the psychological reason: human usually not comfortable with uncertainty and needs for closure .

Forcing estimation cause some worse consequences:

• Force developer to plan up front, which will fallback to waterfall;
• Developer faces the pressure to lie, and give the wrong number, which cause,
• Wrong measurement is worse than no measurement. Like weather forecast.

What can we do when the project manager ask you estimation next time:

•  Live with the uncertainty, that is the nature of the software development;
• To be honest, tell them you don't know yet, you only estimate what you can deliver after the current iteration;
• Timebox the estimation, spend 30 minutes to investigate the problem, you should know if you can finish it by the end of the day or not. Avoid yak-shaving.

Learning the theory of Constraint - "The goal" Review

Yesterday I finished the book:The Goal: A Process of Ongoing Improvement. The book is so fascinating, when I read it, I can not put it down, just like reading one of Agatha Christine's books. I never imagine that a business book can be written like this.
What I am most interested is the principle described in book: the theory of constrains. Here I copied some key points from the TOC WIKI:


Key assumption
The underlying premise of Theory of Constraints is that organizations can be measured and controlled by variations on three measures: throughput, operational expense, and inventory.
Throughput is the rate at which the system generates money through sales.
Inventory is all the money that the system has invested in purchasing things which it intends to sell.
Operational expense is all the money the system spends in order to turn inventory into throughput.
"The Goal" itself is to "make money". All other benefits are derived, in one way or another, from that single primary goal.

The five focusing steps
Theory of Constraints is based on the premise that the rate of goal achievement is limited by at least one constraining process. Only by increasing flow through the constraint can overall throughput be increased.Assuming the goal of the organization has been articulated (e.g., "Make money now and in the future") the steps are:

1. Identify the constraint (the resource or policy that prevents the organization from obtaining more of the goal)
2. Decide how to exploit the constraint (get the most capacity out of the constrained process)
3. Subordinate all other processes to above decision (align the whole system or organization to support the decision made above)
4. Elevate the constraint (make other major changes needed to break the constraint)
5. If, as a result of these steps, the constraint has moved, return to Step 1. Don't let inertia become the constraint.

Applying to software development
This book is about manufacturing, but I found it can be easily applied to the software development. And I found it is very similar with Kanban method: Kanban help us visualize the bottleneck, improve the productivity by limiting the Work-In-Progress. Which is exactly the same as the theory of constraints. I feel that the TOC can be regarded as the scientific theory behind the Kanban system. Before when I learn Kanaban, I just accept the principles and conclusion from the Kanban, but I never thought of why it is like this or that,  Since this book uses lots of examples and step by step from question to conclusion. Now I understand more about Kanban. So I can say Kanban is an implementation of TOC.
If you knows Lean/Agile, you will find there are lots of concepts shared between lean and TOC:

• lead time
• Inventory is bad
• WIP (Work-In-Progress)
• small batch increase the productivity
• local optimization is not working only optimize the whole works.
• The dependent event queue can be mapped to the value stream map, or Kanban Queue.

Even the subtitle of the book - "A Process of Ongoing Improvement", which is perfectly match one of the lean philosophy - Kaizen, which means continuous improvement.

I just found David J. Anderson's book: Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results. I haven't read that, but based on the title, it must be about applying the TOC into software development. In his recent blog post: REFLECTIONS ON THE PASSING OF ELI GOLDRATT,  he describe how TOC inspired him for his book and Kanban system.
Actually when I read this article from twitter last week, and this is the reason to let me read the book of "The goal".

And I found this youtube video is interesting: Standing on the Shoulder of Giants by Eliyahu M. Goldratt, Godratt talks about the TOC, Kanban and Toyota Production System.

I realized I need to read this book one more time. the TOC is so powerful, but I still have lots of questions, like:
- How can we apply it into our daily software development?
- How to find the bottleneck?
- What are the measurements we need?

Hope I can find the answers from the goal, kanban and Lean.

How I improved my company's build system - build automation

Last 2 weeks I haven't check twitter, did not go to infoQ, all my spare time is focused on one thing: improve the build system, the goal - one button click triggered the build and deploy automation.
This goal is finally achieved last week. Now the build system is scheduled deployment once a day, the automation jobs include following:

1. check out source code from CVS;
2. build client and server artifacts;
3. generate the change log
4. update the wiki and download page
5. upload the artifact into server and downloading repository
6. execute the server deploy script
7. send new release email 

Before only step 1) and 2) are automatic using the ANT script. All other steps are manual, I found this kind of job is boring,painful and quit easy to make mistakes.

I have the idea for build automation for a long time, especially I was inspired by the book "Continuous Delivery" and "Pragmatic Project automation".  My plan to implement the build automation is pretty simple: simulate the human deployment behaviour, implement an ANT target for each manual step. It sound easy, but when I actually did it, it was harder than imagined. But I finally I made it.
Right now everyday we will automatically release a new build, this is a milestone and a great improvement. I feel so happy and so proud of it.

The tools I used
- ANT,  I used scp, filterset, filterchain, sshexec, cvschangelog, I found Ant has lots of gem.
- Groovy, I used AntBuilder to integrate with the existing ANT task, parsing XML, generating text file, quite neat.
- Jenkins,  everyone recommend Hudson/Jenkins CI server, when I used it, it is so easy to use, and has lots of useful plugins. I use Jenkins to schedule and trigger the build.
- ViewVC, a very good tool to browse CVS source code from web, I configure the ViewVC in Jenkins, Jenkins will provide the actually source code link in the changes page.

What I learned

• Pay more attention to your feeling. If you feel boring and painful, don't just complain, try to find a way to improve it. This is a good chance to improve your self, my previous blog describe this.
• A good developer must be able to delegate the dirty jobs to the computers, it would be shame for a good developer to do the repetitive manual jobs over and over.
• I implemented the automatic build script based on the manual process, so I learned: if you can define a repeatable step by step manual process, then you can automate it by program.
• I finished this job usually in down time, I finished one small piece each time, so the improvement for the legacy system has to be emergent.

Next Actions
This is only the first step, there are way more things needs to be done, my next steps will be:
- Add Unit Test and Regression test automation
- Add the code quality analysis report
- Use Ivy for dependency management
- Use Puppet to manage the configuration

Deming's philosophy - the root of Lean

In the Agile community, almost every one talking about Toyota's Lean technology. When we talking about lean, we can not ignore Deming, since Japanese learned a lot from Deming and goes further and have today's Lean.
Yesterday I spent some time watch Deming's videos on youtube:
W. Edwards Deming - Part 1,  Part 2,  Part 3
Dr. Deming - The 5 Deadly Diseases 1984

From these videos, you will easily find some of the lean principles do get from Deming, like: continuous improvement, eliminate wast, build quality in, respect people, optimize whole, focus on long-term goal, etc.I realize that the core of his philosophy is: respecting people, people first.

Here I copied his 14 points and 5 deadly diseases about management.
Deming's 14 points:

1. Create constancy of purpose.
2. Adopt the new philosophy.
3. Cease dependence on mass inspection.Eliminate the need for massive inspection by building quality into the product in the first place.
4. Minimize total cost when dealing with suppliers.
5. Improve continuously products, services, and processes.
6. Institute training on the job.
7. Adopt and institute leadership.
8. Drive out fear.
9. Break down barriers between departments.
10. Eliminate management by slogan and exhortation.
11. Eliminate numerical quotas and goals.
12. Eliminate barriers to joy in work.
13. Institute a program of education and self-improvement for everyone.
14. Put everyone to work on the transformation of the organization.

Deming's Five Deadly Diseases

1) Lack of Constancy of Purpose
- No planning for the future
- Lack of short term definition and goals
2) Emphasis on Short Term Profits
- Worship of the quarterly dividends
- Sacrificing long term growth of the organization
3) Annual Rating of Performance
- Arbitrary and unjust system
- Demoralizing to employees
- Nourishes short term performance
- Annihilates team work, encourages fear
4) Mobility of Management
- No roots in the company
- No Knowledge of the company
- No understanding of problems of company
5) Use of Visible Figures Only
- No use of figures that are unknown or unknowable, i.e., customer or employee satisfaction
- Encouraged by business schools

From the above, you will find these problems are quite common today, we need a long time to go to adopted his philosophy, this is why I am pessimistic about lean, because I feel the largest problem for lean is coming from managers, not from software developers.

Why learning philosophy is so important?
Some one might ask: we can just follow the practices or process, why we need to learn the philosophy?
I think if technology is good and worth doing, it must have some good principles or philosophy behind the concrete technologies. Once you understand the behind philosophy, you can master the technology, you will not be confused by the different variation or context. And also the detailed technologies or practices are context based, they are easily changed or deprecated with the time and context change; but principle/philosophy is different, they are abstract and can transcend the detailed context, the philosophy can be so powerful that they can apply to different context without change. That is why the art of war and the book of five ring is still useful today, because their principles are general and timeless. This is the meaning of Tao, that is why I am so obsessed by the principle and philosophy. The philosophy is hard to mastered, I remembered the author of The Toyota Way once mentioned, many companies adopted the Toyota production System, but Toyota find few companies really understand the behind philosophy. That is my suggestion, when you learn lean, you still need to understand the behind philosophy. If you just do the lean practices without knowing the philosophy, I am sure you will not do Lean correctly; you can do lean correctly only if you fully understand the lean philosophy.
Here I would like Quote What Deming said:(from his wiki)

"Once the individual understands the system of profound knowledge, he will apply its principles in every kind of relationship with other people. He will have a basis for judgment of his own decisions and for transformation of the organizations that he belongs to. The individual, once transformed, will:

• Set an example;
• Be a good listener, but will not compromise;
• Continually teach other people; and

Help people to pull away from their current practices and beliefs and move into the new philosophy without a feeling of guilt about the past."

Try Pomodoro

Today I finished the book of "Pomodoro Technique Illustrated". Actually I heard of the Pomodoro in last year, but I did not think it seriously, until recently Dan North recommend it in his last two talks, so I decided to look at it. Through over a week's learning and practicing, I like it, it is simple, straight forward, and powerful.

The Pomodoro technique is pretty simple:
- Choose one single activity from your TO DO List;
- Set clock to 25 minutes focused on a single activity for 25 minutes, during this time-boxed 25 minutes,  you only have one activity, and one goal: finish it.
- After 25 minutes, take 5 minutes break;
- Choose the next most important activity, start again;

The Pomodoro is timeboxed, focus on single activity and single goal. It helps you prioritize your task, help you keep focused and remain high productivity.
It emphasize on execution, getting things done, and NOW. I found it is similar as Getting Things Done, but comparing with GTD, I like Pomodoro because it is quite hands on and easy to implement,  actually I have not finished the GTD book  yet. It focus on only one thing at a time, and its emphasize on NOW remind me the ZEN philosophy.

From Agile perspective, Pomodoro like a personal agile methodology, or specifically it very similar as SCRUM, I would rather say it as personal SCRUM, because you can treat each Pomodoro as SCRUM sprint, and the inventory as SCRUM backlog. And quite similar, in SCRUM, you can not change your task during each sprint; while you can not change your task during each Pomodoro. Pomodoro also focus on planning,processing, tracking,retrospective, so it is really agile.

I only started Pomodoro for only a week, I like it because it provide you the awareness the time,prioritizing and single minded; before it is quite easy to yak shaving, or get distracted. The Pomodoro provides a mechanism to let you get focused and remain higher rhythm, then improve your productivity.

Some notes from the book:

- time-boxed, single activity,single goal
- 5 stages: Planing, Tracking, Processing, Visualizing - retrospective
- Deming-Shewart cycle: plan, do, check, act
- Tools: TODO Today Sheet, Activity Inventory,Record Sheet
- Pomodoro will first Prioritize, then focus on the most important activity (like scrum)
- Pomodoro need to see the big picture before you decide what to do
- it is goal oriented
- it has immediate feedback

Interruptions
- principle: neither switch activities nor stop an activity in the middle of a Pomodoro.
- avoid LIFO
- avoid BPUF

Deal with internal interruptions
- Strategy: Accept, Record and continue
- Write it into Unplanned & Urgent
- never switch activities in the middle of Pomodoro: "Once a Pomodoro begins, it has to ring."

Deal with external interruptions
- Strategy: inform, negotiate,schedule,call back

Resources:
I use my iphone as a timer, but I want to use it as vibrate only, but I could not find a vibrate only ringtone, try this link, it tells you how to set the silence only ringtone

Some thoughts about Conway's law

One of my best learned from QCon San Francisco is Conway's Law, I heard it at least 3 times from different talks, especially from Michael Feather's talk. It is so striking, I never aware this before. Here is the definition of the Conway's law:

organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations

In short, you can understand Conway's law like this:

• The software design structure is constrained or shaped by the company's physical structure;
• Your code structure mirrors your organization's structure.

This concept is quite interesting and so striking, it forced me into further thinking:

Constraints
Based on Conway's law, we can conclude:

• Good organization's structure generate good software architecture, bad organization's structure generates bad software architecture;
• The messy code base reflect its organization's messy management, the clean code base reflects the organization's clear structure;
• Management structure is quite similar as the code structure, for example, some manager like to control everything and focused on details, he does not know how to delegate, just like the "GOD Object" anti-pattern in the software development.
• The software manager's style, like/dislike and skills may also constraints the software product;
• Developer's own skills, knowledge, communication skills and ignorance level, etc, may also constraint the software product. We need to be aware of these constraints.

Conway's law in the other way
Can we good developer influence/improve organization by applying the good practices/patterns/principles?  For example, As a developer we knows how powerful the design patterns and SOLID principles to the OO design, and manager can apply those patterns to improve/refactoring the organization structure. Actually I have the idea long time ago: manage a company is like managing software, if you are a good developer you can be a good CEO or manager. We can use the software technologies to manage the company team. Although the context is quite different, they both solve the similar problems: How to manage dependency, how to make the team or software product more adaptable. 
This seems has a higher requirement for the manager, since I seldom see a manager who has a strong developer background. I really experienced how difficult it is to communicate with a non-technical background manager, it is really frustrating, and so hard to explain the issue, some time you have to translate it into an real life example to make it easy to understand. Think about it, it is so hard to let the manager to understand an issue, how could he actively find out the issue that developer himself does not aware? This is definitely an example of the Conway's law.

More about "Drive"

I just by accident read Martin Fowler's article: Can Not Measure Productivity.  The author concluded that you can not measure developer's productivity, because the output is not measurable. Even if you try to measure the performance by using the wrong metrics, things even become worse. In the article, he recommend a book called Measuring and Managing Performance in Organizations, written by Robert Austin. but it seems it is not published any more, I just found a slide of the book., and a brief introduction of the book. 

Quotes from the book introduction:

Because people often react with unanticipated sophistication when they are being measured,measurement-based management systems can become dysfunctional,interfering with achievement of intended results. Fortunately, as the author shows, measurement dysfunction follows a pattern that can be identified and avoided.

 Here I got some quotes from the slide:

        "A system of incentives is dysfunctional if the resulting effort allocation provides less value to the customer than when there is no supervision.” (Austin)

Measurement versus Delegation

• Full Supervision: incentives via measurement

  – Relies on extrinsic motivators

    • Money

    • Continued employment

    • “Forcing Contract”

• No Supervision: incentives via “delegation”

  – Relies on intrinsic motivators

    • Pride of workmanship, joy in being part of the team

    • Identification with the company’s values and goals

    • Desire to please the customer

Intrinsic versus Extrinsic Motivators

• Intrinsic motivators are much more powerful

• But appear to be overridden by extrinsic motivators

• Japanese versus American management styles

  – Japanese rely heavily on delegation

  – But it is cheaper for them

  – It is both a strength and a weakness

• Delegation may not be cost effective either

• Sometimes neither style works

  – “Large software development firm”

Summary

• You may think you have full supervision

• But you are almost certainly wrong

• The ship’s wheel is not directly connected to the rudder

• Austin versus Deming

  – W. Edwards Deming, Out of the Crisis, MIT Press, 2000

  – Former BTL lead Japanese quality movement in 1980s

  – Methodology summarized in his “Fourteen Points”

So based on the text above, we can conclude that the book of "Measuring and Managing Performance in Organizations" share the same concept with the book of "Drive", use different perspective, it proves that people's performance and productivity is unmeasurable, the manager should not rely on external performance incentive, but should rely on people's intrinsic motive. It also proved that this idea share with Deming's 14 point. Interesting.

Another useful link: 

 http://www.slideshare.net/RobMyers64/metrics-in-an-agile-world