There is something called standard work, but

As I prepare for my talk at agile 2011 I am re-reading Workplace Management by Taiichi Ohno and what a pleasure it is to re-read this book.

The first chapter talks about being wrong and accepting when you are wrong. Taiichi Ohno goes on to say:

Engineers in particular tend to hold on tightly to things they have said or to their ideas. Engineers are often said to be inflexible or stubborn but i think it is important for them to quickly correct themselves, just as the wise mend their ways. If you think “What I said was mistaken” you should clearly say “I was wrong”. Without this attitude your subordinates and the people on the gemba will not do things for you.

How refreshing is that attitude. In our current work culture though we are taught not to accept when we are wrong. We say and pay lip service to the idea of accepting when one is wrong.

But time and again we notice executives, engineers etc adhere to what they have said. How many times have we noticed an executive say that they would like to see some metric and keep asking for that metric even when it was proven that metric was wrong. Engineers go thru reviews at the end of the year where they are told how many times they were right and how many times they were wrong. Got forbid if they accepted they were wrong, they can say bye bye to the bonus.

The measures employed by organizations create individuals that are rigid in there belief, even when they know they are wrong. I don’t think it is there fault, but that of a system that scoffs at them when they accept they were wrong. Once they are burned by being honest they realize there is no point and start to calcify in there thinking.

Now I am no Confucius who inspired this thinking for Taiichi Ohno. I have been guilty of adhering to my rigid ideas as well. But with every opportunity I try and mend my ways and learn to say when I was wrong. Obviously I learn when I was wrong by trying my suggestions. So heres hoping to becoming wiser.

http://program2011.agilealliance.org/?s=ravindar+gujral

I have had this feeling for a long time that software industry, the industry I am part of is full of highly egotistical individuals. We seem to say that software is a craft but at the same time like to believe that individuals should come out of the womb with understanding what is genetic algorithm or some similar complex algorithm. More often than not I meet software engineers who love to talk in complex patterns just to show how smart they are and god forbid if you don’t understand what they are saying, you are quickly tagged as a lightweight. It just seems so very silly.

Just like wall street creates unnecessary complex vernacular, the silicon valley and the software industry does the same as well. Just like wall street is running towards the latest and the greatest thing in the market, so is true for the software industry. There is an air of superiority amongst members of this industry. Everyone very easily forgets how it was for them when they first started using computers, that they learned the craft and that someone helped them when they were starting out. This holds true for when people are learning a new language/environment or method of programming. People learn things and then suddenly start treating every new guy coming into the field as an idiot.

The other issue is that because everyone has a computer they believe they understand what it means to write software. We have an influx of too many MBA’s, generalist who apply generalist rules to build software. They don’t have the basic understanding that this is a craft. They bring the same stupid judging rules to judge software engineers.

Software is a team sport. Sadly this is something that is not taught when this craft is taught to individuals. What is taught is that you have to know everything and be a lone warrior. These very same individuals may end up writing some great piece of application, but add them to a team and they are like nepam for the team. There ego destroys the team. I don’t care if you are a super star but if your ego gets in the working of a team, I would rather not have you on the team. For this very reason I like to hire young graduates who have not yet acquired the air of superiority and are willing to look stupid and learn and also teach. I have found the best teams are the ones where everyone acknowledges that we are all learning this craft and are willing to teach each other tricks of the trade.

If software is a craft shouldn’t we be looking for individuals who show tendencies in learning a new craft, an open mind and the ability to be diligent and willingness to learn when they don’t know what is going on. I can only wish that this industry was filled with less egotistical individuals, but sadly we have a long way to go.

http://ecorner.stanford.edu/authorMaterialInfo.html?mid=2290&fileId=8013

Some of the topics we will be presenting at upcoming conferences

http://submit2011.agilealliance.org/node/8873

http://submit2011.agilealliance.org/node/8872

http://submit2011.agilealliance.org/node/11431

So far some of the conferences I will be at are XP Day in Madrid and Lean Software and Systems in California.

I recently came across this post by Andy: Three Things I don’t like in agile community. I really understand and like his observations. Below is my commentary.

1. Dogmatism
Agile is about adaptive, creative approach to complex work yet amazingly average agilists are the most dogmatic people I know. If you read their blogs and follow their tweets you will soon see dogmas being proclaimed and anathemas being cast on heretics who don’t agree……..

I would agree with what Andy is saying here. More often than not I end up talking to someone that proclaims that such and such method(scrum, xp etc) is the solution to all the problems. I find that in most cases these individuals have not really worked in varying environments and worst still have not read enough. They have used one approach/practice/method that has worked and now they think this can be applied everywhere. What they don’t realize is that at the end of the day it is about delivering value and providing success (Organizational, technical and personal). To do this you have to change mindset and behaviour. It is not an exaggeration to say that this is about a state of mind. Coaches that are dogmatic suffer from “Ignorant Pattern Application”, which is what we see in software development, someone that has read GOF book and worked with a pattern wants to apply that pattern everywhere.

For example I have seen Scrum enthusiasts insist that a support team that is dealing with customer issues insist on committing a priority at the start of a 2-4 week sprint and then force the customers to wait or to adhere to this priority whilst the customer suffers.

For my part I have always maintained that there are no silver bullets. One has to be open and adaptive when dealing with challenges. I have always believed that there are basic practices in one’s toolset that come with experience and application of various practices and methods. What also comes with this experience is the understanding of what tools/practices work in what circumstances(where/when/what time frame). But alas there is a lack of agilistas that have this kind of built in experience.

2. Sectarianism
Kanban, Scrum, XP – everyone follows their own method, and basically says others are useless or at least not as good. It is like if we had separate sects, each following its guru or gurus – and shunning others. Again, this is in the face of core principles of agile…….

Again I have to agree with Andy. It is sad to see this happen. I work with clients and often find them saying that they are following scrum/xp etc and the coach they had before has told them this is the best solution to all there problems. Not just that sadly the coach before I arrived has brain washed them to the point that when I suggest a synergy the invariable response is “but the book(for practice x) does not say that”. More often than not I have to sigh! when I hear that. It seems we have an abundance of coaches like these that do not want to cross pollinate there knowledge. This is a function of the coach that has only worked in one kind of environment and thus feels every problem needs there one dimensional approach to finding a solution.

3. Domination by consultants

Most if not all agilists that write, teach and coach do only this and have not run a software project (or a business) hands on for quite a while. This is all natural, especially given how much money was there in it for those who were in the movement early enough. But it has some bad side effects – dogmatism and sectarianism are amongst them……

I work as a consultant and do see this often, no pun intended. For this very reason I believe that one has to be constantly involved for long periods. I am always conscious of this and thus make an effort to be involved from conception to at-least one delivery cycle if not more. Also I did not even think of becoming a consultant until I had at-least a decade of leading teams and finding what works and how teams evolve. And also I don’t believe I can remain a consultant for long if I don’t engage for long term efforts.

You can bring in consultants that have actually been involved in long term projects and will provide the value you seek. There are coaches that run workshops and they can be a good vehicle to learn concepts and understand basics. If you need more practical knowledge you can get a consultant that was involved in a large project before they come and help you. But yes the community does suffer from coaches that get involved for short periods or have not been part of a delivery effort recently. I think this is a trade-off.

Andy I understand your frustration but I can assure you that there are a select few of us that have been in large organizations or have run teams of various sizes and are talking based on experience. If you see a coach being dogmatic/sectarian/non-practical understand that you can still look around and not be bound by there one dimensional approach.