Category Archives: Learning Organization

This category represents my understanding about wide set of organizations mostly IT companies and oddly others.This also represents my ideas,thoughts about problems faced by many organizations and how I think,organization as a unit can perform better.

Tapari Meetings

Today morning I was checking my Facebook account and came across Harvard Business Review article over “How to Run a Meeting” ( I was overwhelmed by sheer length of the article. I must admit, I hate those long, unfruitful and agenda-less meetings. I think everybody does, isn’t it?

I started wondering, why HBR need to write such a long article on such a simple thing that we assume that everybody knows. It is just matter of checking all peoples’ calendar and sending them meeting invite and put the subject, venue etc. and done. In meeting as well, its straight forward, one person usually be the host, put forth the agenda and we discuss and at the end of the meeting, we share minutes of the meeting and action points. What is such a difficult thing in taking meetings?

The problem is not in taking meetings, it’s all about how we looked at this tool of communication and how effectively it’s been used in corporate world. If you really look again in HBR article, it’s been written in year 1976 and still the advice applies and still HBR fellows thought it is relevant in today’s world. It also means, not much things has been changed since last 40 years. We all, still curse ill-executed meetings. Traditionally executed meetings are always failures and count towards loss of productivity. Can we do something differently? Can we change, how we conduct meetings?

My views had been bit different on how to conduct the meeting thing. I am a big believer of 37 Signal’s philosophy of “Meetings are toxic” but also not able to avoid meetings completely. From last 5-6 years, I have been trying something different for meetings with my teams. After practicing with various teams and with different size companies in India, I think, it has made many of our meetings more productive and kept teams engaged. Most important is, we saved a lot of time which we might have wasted in conducting meetings in traditional sense.

My method is simple. I call it “Tapari meetings”. Together all team-members go for tea/coffee outside the office on nearby Tapari (tea-stall on the streets or around the street corners in India). If you don’t want to go outside office for some reason, then go to office pantry or gather around coffee machine and without any formal settings, start to discuss the topics everyone wanted to discuss. The topics can vary from what we need to do today to anything that is relevant to project/work. If team is like still relevantly new to each other, then you can start with common un-official topics like Sports, bikes, cars or any tourist places or anything. The important point is, team as proceed further with this daily routine, develops their own rules. You do not have to worry about setting rules in stones. My experience is developer and test engineers even nailed difficult bugs just by discussing them in such informal meetings and even executives has taken big decisions this way.

Advantages of such “Tapari Meetings”:

  1. keeps your meetings cheerful and awake. Since people walk to the Tapari (Indian tea-stall on the streets or around the street corners) or coffee machines.
  2. Meeting will run only for the time, people are having their tea/coffee and interested in the discussion.
  3. If you don’t have any set agenda, you don’t waste other people’s time.At least they can have tea-coffee and come back to their place.
  4. Soft issues can also be resolved since there can be “one more cutting de na bhaiyya” (One more tea, please) to sort out the issues.
  5. People only speak to the point and thinking on the feet since they don’t have ppts and any kind of papers.
  6. Since its only meeting where you have to remember things afterword, my observations are, people tend to conclude on action points and not interested in receiving minutes of meetings afterwards.

I understand that there will be few people who will always question about such drastic changes like having meeting outside and without any dashboard, ppts or even paper but I request you to try this method for few weeks and you will see the results.

Failure of our (may be specific to India only) traditional office system is highlighted when we think work only happens when people are at desk. Surprisingly, even president of USA and Prime Minister of India can work out their deals while having tea and walk. Do you think, your work is more important and more complex than theirs?

Let me know your thoughts.


Book Notes: “The Phoenix project: A Novel about IT, DevOps, and helping Your Business Win”

From so many days, I have not posted anything since I was almost like a lost but now wait is over. Over the last weekend and this weekend, I managed to read through a really interesting book and that is “The Phoenix project: A Novel about IT, DevOps, and helping Your Business Win” by Gene Kim,Kevin Behr and George spafford.

The book almost falls in line with the way Eliyahu Goldratt’s “The Goal” but the twist here is it is applied to IT industry. The book is written with fast paced plot of a sinking organization which almost has chaotic IT and business relationships and how it overcome the obstacles and continually improves with the help of laid out principles (Three ways) in the book.

I have read “The Goal” way before I was able to digest the material/principles laid out and always struggled to correlate it with IT industry but ‘Phoenix Project’ does excellent job here. For my future reference & time saving purpose, I had put down below notes which are taken from the book.

  • When there are Chaos. Start prioritizing and estimating work. While doing so, you cannot stay away from fighting fires.
  • Knowing is better than not knowing things.
  • Stay Focused at wider goals.
  • WIP is a silent killer. Therefore, one of the most critical mechanisms in the management of any plant is job and materials release. Without it , you can’t control WIP. WIP= work in progress.
  • Apparently event undisciplined mobs can get lucky too.
  • Read Air Traffic Control Books, Highlight on ubiquitous terminology used between air traffic controller and pilots of aircrafts. Signify accidents of plane crashes that happens. – Useful for DDD.
  • Whiteboards, paper, physical movements and physical presence *engages * people and increases their *involvement* in their projects thus increasing success rate of projects.
  • As a consultant, my goal is to observe and seek to understand.
  • Project is getting delayed, all tasks by Dev team are marked as completed and QAs are still finding twice as many broken features/defects as are getting fixed. – Classic situation of badly run project.
  • Processes are supposed to protect people from Distractions and help them deliver their core objectives.
  • “I think” this might have happened or the I think the bugs are because of such and such thing. Such statements are sure signs of the problems that goes un noticed. It shows that we are flying without compass (data) and map (direction).
  • Interesting term J ! FUBAR = Fucked up beyond all recognition.
  • Management gut check from my team.
  • There are four types of work in IT Operations: 1. Business Projects 2. Internal IT projects 3. Changes and maintenance work 4. Unplanned work
  • Prioritization will help till one point but we need to identify what our constraint (real bottleneck in entire flow of operations) is and guard it from unscheduled work as well as keep it busy on top priority work.
  • Focus on Work centers. A work center is made up of a man, machine, methods and measures.
  • After chaos and constraints are figured out, work on single most important item/project which is required for survival.
  • Once you get some success around, plan for all projects which does not involve constraints/ constrained work centers.
  • Improving daily work is even more important than doing daily work.
  • Ensure that we’re continually putting tension into the system, so that we’re continually reinforcing habits and improving something. Resilience engineering tells us that we should routinely inject faults into the system, doing them frequently, to make them less painful. This is called as improvement kata.
  • Repetition creates habits and habits enable mastery.
  • Our goal is to maximize flow.
  • You win when you protect the organization from putting the meaningless work into the IT system. You win even more when you can take meaningless work out of the IT system.
  • Avoid scoping errors.
  • Create work centers and lanes of work.
  • Understand Upstream and Downstream processes?
  • Color coding of cards:
    • Purple cards for changes supporting one of the top five business projects; otherwise, they are yellow.
    • The Green cards are for internal IT improvement projects. [Give 20% of cycle time to these]
    • Pink cards are blocked tasks that are needs to be reviewed twice a day.

Make sure that there is a right balance of purple and green cards in work

  • Improving something anywhere not at the constraint is an illusion.
  • How to prioritize projects?
    • Do they increase the flow of project work through IT organization?
    • Do they increase operational stability or decrease the time required to detect and recover from outages or security breaches?
    • Do they increase specified constraint’s capacity?
  • Projects that decrease your organizations/major project’s throughput, swamp the most constrained resource in organization, decrease scalability, availability , survivability, sustainability, security, supportability should be prioritized on low or entirely discarded, if possible.
  • Managing the IT operations production schedule is one of the job for IT Operations top management.
  • Wait Time = % of resource busy / % of resource time idle
  • Wait time depend upon resource utilization.I.e. if a resource is 90% busy then wait time is 90% / 10% = 9 units of time i.e. 9 hours.
  • Create Constant feedback loops from IT operations back to development, designing quality into the product at the early stages.
  • You might have deployed an amazing technology (virtualization/cloud), but because you haven’t changed the way you work, you haven’t actually diminished the limitation.
  • The flow of work goes in one direction only: forward.
  • Takt time=Cycle time needed in order to keep up with customer demand. If any operation in the flow of work takes longer than the takt time, you will not be able to keep up with customer demand. So in IT, if your deployment time or environment setup time is greater than cycle time you will have a problem.
  • DevOps is more and more important and their unified goal is to serve business goals. So, instead of fighting with each other, they need to be more collaborative.
  • Read book: Continuous Delivery by Jez Humble and Dave Farley.
  • Business agility is not about just raw speed. It’s about how good you are at detecting and responding changes in the market and being able to take larger and more calculated risks. It’s about continual experimentation.
  • Read about Scott cook’s experiments in Intuit.
  • The way to beat competition is out-experiment them.
  • Features are always a gamble. Only ten percent will get the desired benefits. So the faster you can get those features to market and test them. Incidentally, you also pay back the business faster for the use of capital, which means the business starts making money faster.
  • For above reason, you need to target ten or more deploys per day in production environment.
  • Value Stream Mapping is quite useful tool for discovering activities that are adding value and those which are waste.
  • BIGGEST LEARNING FOR ME: DESIGN YOUR SYSTEMS FOR IT OPERATIONS!! Build as many possible feature knobs and controls with which we can switch on and switch off the features. Learn Dark launches, canary releases as soon as possible.
  • To routinely improve things, inject large faults in the system. It’s been followed in Apple mac OS and Netflix as well. These projects are called as “Simian Army Chaos Monkey”. Read more on these experiments and improvements. This creates culture that reinforces the value of taking risks and learning from failures and the need for repetition and practice to create mastery.
  • IT is not merely a department, it is pervasive like electricity.
  • In order to survive, the business and IT can’t make decisions exclusive of each other.

This has been a good read in so many months probably years. I look forward to read further through number of books such as Toyota Production System, DevOps cookbook, all lean literature and practice Improvement kata’s.

Combination Therapy for Requirements using BDD and UML


Generally, we write requirements in use case structure. Use case structure gives us all elements required but by design , it is a vague format which are devised around use case diagrams. Every software professional has its own flavor of writing use cases. Even the sections of use case structure varies person to person.The intrinsic details of the parts of use case specially use case description, preconditions and post conditions etc] are vaguely defined. Writing use cases in clear format is also a skill and that depends upon the person who is responsible for collecting requirements.Use case are still useful in mature kind of organization but it is not so much effective way when we do not want to have upfront big designs. So dilemma here is how to collect the requirements and the new approach should be better than standard use case structures and should be fairly objective.

There is also a second angle to this use case discussion. Requirements have bigger impact on business and cost part of IT projects. Many times, due to not so clear communication between IT vendor and client over the requirements, this cost of lot of rework and hence the cost to client.From client’s viewpoint ,it is difficult to understand use case type of language and there is a chance to miss out or assume requirements/scenarios ,which becomes cost(in terms of money or time) for them afterword. Situation becomes bad in fixed cost projects. I had experienced this bitter pill many times.


So the solution I am proposing here is , Behavior Driven Development [BDD] kind of requirements collection for even the people who are not practicing BDD. From past few months,I am sort of wandering in TDD,BDD forest. Now I am going ahead with nBehave and Specflow and Gherkin which has changed whole lot of things for me on coding front.

I totally understand that BDD can’t be fully rolled out in some scenarios/in some organizations[no silver bullet!, lack of expertise, no enthusiasm to learn, cost of learning curve and transformation etc] but I am sure that, we can at least move to BDD style of requirement writing which is kind of closer to silver bullet:). See the following example. I had directly taken this example from Dan North’s blog. BTW, Dan is pioneer in BDD and I guess, he is the first who coined the term "BDD". He has also compared use case format with BDD style. Here I think, interesting angle from my side is merge both of them to take advantage from both styles of requirements collection.

In BDD, The requirements are collected in story form like:

Title (one line describing the story)


As a [role]

I want [feature]

So that [benefit]

Acceptance Criteria: (presented as Scenarios)

Scenario 1: Title

Given [context] And [some more context]…

When [event]

Then [outcome] And [another outcome]…

Scenario 2: …


Story: Account Holder withdraws cash

As an Account Holder

I want to withdraw cash from an ATM

So that I can get money when the bank is closed

Scenario 1: Account has sufficient funds

Given the account balance is \$100 And the card is valid And the machine contains enough money

When the Account Holder requests \$20

Then the ATM should dispense \$20 And the account balance should be \$80 And the card should be returned

Scenario 2: Account has insufficient funds

Given the account balance is \$10 And the card is valid And the machine contains enough money

When the Account Holder requests \$20

Then the ATM should not dispense any money And the ATM should say there are insufficient funds And the account balance should be \$20 And the card should be returned

Scenario 3: Card has been disabled

Given the card is disabled

When the Account Holder requests \$20

Then the ATM should retain the card

And the ATM should say the card has been retained

Scenario 4: The ATM has insufficient funds

I think Along with story, if we have mockup/screenshot[off course with Balsamiq mockups! ] of proposed screen and control, data type range chart we used to have with our existing UML format, we can move towards clear requirements.


This will benefit in following ways:

  1. It will help to gain common understanding between client and IT Vendor,about what has been covered as requirements and what has not.
  2. Client will find easy to go through requirements since requirements are written in very structured fashion and in plain English.
  3. Organization wide, requirements will be captured in same fashion and we can really estimate based on stories and find how simple or complex the story is based upon no. and complexity of scenarios it had. Hence its really easy for going with statistical process control for estimation.
  4. Change Requests are dealt with adding/removing/updating the feature/story/scenarios.My observation here is they only change the scenarios. In very rare cases, features or stories are changed.
  5. Testing team will reap the greater benefits here since they can write these stories as per their understanding and take part in RE process in very active way like finding out the missing/not clear scenarios etc.
  6. Testing team do not have to write any other test cases, This can serve as live requirements as well as test cases for them.
  7. Unit Testing for Developers will be easy since now they clearly know what kind of scenarios they have to cover which is bit difficult and time consuming in Use case format.

Let me know your thoughts, specially BDD and UML experts…

Many good points are noted as what should be in story by BDD pioneer Dan north in his post (

It’s really refreshing for me to see the BDD light. I will cover an example of my solution and more on requirements collection thought process that I follow, in next post.


Share this post :

Programmer’s Bad Habits II

Continuing part I of this series, here are some more things to add to bad habits or common fallacies and traps of programmers that are holding them from performing well.

1. Carry over the dead code/experiments/comments with you.

Go to any system/project’s codebase that is more than a year old and you will get to know what this means. You see the comment that says “Sales Invoice in next five lines” and more than 20 lines of code that is commented out and another 10 lines code that are currently working as you debug…and nobody can explain what that old commented code does but they don’t dare to clean that up.

2. I can’t fix another programmer’s code, rather I will rewrite it.

Ah! This is a classic and I admit that I had been also got hold of it in my early carrier. One programmer never says good things about another programmer’s code. I think this is in our gene and sometimes even if I think of this ,I think programmers in somewhere deep down their minds wanted a perfect world and each one has their own version J of it. Anyway, what all I can suggest is they can read martin fowler’s classic ‘refactoring’ book and this notion will go away.

3. The world can be written only with “if-else” and “for” loops and method reuse.

Junior junkie who can code for days and night and fresh from colleges or worse spent one or two years in some company can write entire systems in if-else and for loops and some procedure reuse. I think some or the other way this has a root cause of “failing to unlearn what we had learned first”. Most of these guys had learned C language as their first programming language and may found they were good at it or they presume that they are good at it. Biggest mistake our schools and some local book authors has did is they are teaching procedural and object oriented programming language the same way.

These authors had not thought over the object oriented principles, rather their focus is teaching upon the tooling of object orientation like inheritance and polymorphism and unfortunately this is the case in India which has got some credibility in IT.

4. Testing is inferior to programming. It is not what true programmer’s do. Testing is THEIR (Test Engineer’s) JOB.

I spent my early years of career in small start-ups where we don’t have luxury of appointing a separate test engineer. Whatever we write, we have to make sure that we are doing it correctly and the result of it is though I have got respect for the test engineers since I realized that say after testing for basic flows and validation errors it is very difficult to think of something different that can break the system. In regard of this thought I had learned some testing basics from various websites and still those are very handy even as a programmer.

Nowadays, While working with midsized firm and continually reading about TDD all I am realizing is, programmers had a misconception that they can write a code that had errors and they can just give it to test engineer to clear even basic things like spelling mistakes.

It is shameful that people do not want to test their own code and worst of all rely on some other individual for correcting their own mistakes.

The notion of TDD is good but their also our cleaver programmer (as well as some lousy test engineers) friends tell us the list of excuses like schedule, how can I write the test when there is no development etc.

5. Code review means somebody should check their code line by line for all aspects and point out the mistakes that they had made.

Yes, it is insane but I had seen some managers and some programmers have such ridiculous expectations from code reviews. First thing is programmer should be responsible for the code he/she is writing and not the other fellow who is helping it out to make that code better.

Code reviews should be conducted on sample basis and with the help of some tools likes of static code analysis etc. Checking the mere code conventions should not be the only intent of review. It would be more beneficial that code reviewer should do some firsthand refactoring and in that process programmer would learn things and two about the code as well as this leads to better design.

6. Creating a build means compiling the code.

For the people who have not been in the agile/product development have this misconception that compiling the code is the thing that makes the build process.

These people are missing so many steps that makes build process. I even really doubt that these people consider build as a process.

Many times project requires code signing ,obfuscation of code, replacing connection strings from test environment to production environment ,building for various platforms likes of Windows,*nix or 32 bit,64 bit as well as routine tasks as zipping the release, pushing the release over ftp, emailing about the release to stakeholders etc.

The people ignorant about the build process should really search for the continuous integration and trivial toolset of it which includes brilliant TFS, cruise control, Hudson, rake, NAnt etc.

These fallacies and traps are costing our customers millions and we should recognize it. In my opinion the root cause of these is the way SME’s hiring the resources, further on lack of training and setting the culture to sub standards.

The more I go deeper, I think the waterfall thinking model is still lurking people to write bad code and managers had their fear to adopt the bottom up management approach and what we need is agile mindset and learning organization.

“Learning is not child’s play; we cannot learn without pain.”
– Aristotle

Share this post :

Programmer’s Bad Habits

“Good habits are formed; bad habits we fall into.”

There are much literature that has been written on habits or misconceptions that gets acquired by human beings and how it become hard to leave, especially if those habits or concepts are considered as bad. Bad habits as we all know, seems easy and “quick” solutions that are acquired, mostly unconsciously. But good habits are hard to acquire but gives long lasting benefits to us.

As a developers/programmers or architects, we also acquire habits/misconceptions in our work that consciously or unconsciously imposed seems “quick and easy” solutions to our programming problems. I wanted to throw some light on such bad habits of us-developers…I had also gone through some of these bad habits but thankfully dropped them in my journey to become good dev. Some people may also term them as “anti patterns”, but I am not very comfortable about the word ‘anti-pattern” ;maybe I explain my reasons of terminology in some other post, but now let’s focus on these bad habits or misconceptions.

1. Ignore the warnings, while compilation since they are not causing any problems.

I had seen this many times and I hate this. Some colleague of mine calls me up says that s/he couldn’t find the bug in their program and even after spending a couple of hours and tried all the things s/he can do…

First thing I would try is, I rebuild codebase and see if they had any compilation errors or warnings…and here we go..many warnings yelling for attention!! When questioned about the warnings, the usual answer I hear is “oh! They are not causing any problem so we just ignored them”…and when I see the warnings..Most of the unfound reasons of the bugs are lying in warnings that are in front of the programmers but they can’t see it.

I am not suggesting that you convert all those warning messages into error messages, but warnings are generally-the sign of future or runtime error places and signaling towards inefficiencies in code ;so treat them like errors and work on those.

2. If code is compiling, it is working code.

If you give some junior any requirement and say them that “ok, you need to code this feature/use case etc.” and just watch them. They just start writing the code at the blink of the eye and eager to show their worthiness. But the unfortunate part is next, and that is when they say I am done with the feature/s after their code is getting compiled. Hey Guys! Wake up… writing a compiling code is just a first step and hell…you are not done…Your code has not even passed those unit tests and how you dare to say that your are done.

3. Code once written and running should never be touched.

I generally deal with legacy not in C/C++ terms but have reengineered systems those are in VB 6, .NET 1.1, and likes.

In my opinion, legacy should be termed as “system with inefficiencies even it’s written with latest and greatest likes of .Net 3.5.” Unfortunately that is not the de-facto definition.

Most of the developers and even sometimes project managers have this nausea that if the code has written and that is running that should never be touched.

They say, hey! That is running and as per specifications, why you want to change it or make it better [they see as, this idiot is fooling us by wasting hours on thing that is already done!!] What they miss out is; it is like rusting of the iron. If the code can be improved even a bit by any means, it should be done. It is like you see a piece of rusting iron in your vehicle and still you do not do anything and run your vehicle until any accident occurs.

Damn, that kind of code can carry any characteristic like rigid to requirement changes , fragile like showing strange behavior like fixing bug in one part of code throws the strange error in some other part of the code which is not even related with first. So, the point here is ,we need to remove the inefficiencies.

4. New features can only be floated out by writing tons of new code.

This is really hard to realize that we had picked up such misconception and even harder to come out of this!!

For example, during one re-engineering project, I realized that our architecture is giving ability to product that the client can sell different modules/subsystems to the end users as on need basis and we communicated this to product owner and he liked that idea and which in turn given the product the new revenue stream.We have delivered a feature that is making a strong business sense for product owner without adding extra code!!

All this becomes possible not because we have added some more code for such business feature but cleverly re-architecting the system.

Oh! This post is somewhat getting bigger,I am sorry to break the continuum but just like ‘short methods’ is a good idiom to follow in code, I am keeping this post small and write it in chunks as a true agile developer 🙂

Till then Happy Thinking!

Hope to see you next time…


Share this post :

Hiring Developers

Recruitment is the most important thing in learning organization. It can change the every aspect of your organization. You hire right people with right attitude, give them chance to flourish and they can turn your SME into fast, responsive well oiled machine which is ready to adapt to any kind of business challenge. In fact I think this is so crucial that if I am the CEO then, I must have taken part into interviews of prospective hire.

Nowadays developers know all fancy and shiny things and their resumes are flooded with the buzzwords such as web 2.0, WPF,WF ;but very few have mastered the art of computer science. I think basic developer should not fall into the trap of these buzzwords and go for building the sustainable portfolio. If you are a polyglot programmer that is good thing in today’s market, but you should be really a master of at least one technology.

Many Developers try to pretend to know everything that existed in the world that might be from MS-Office [don’t laugh! I had seen such resumes where people come for senior developer post and they even mentioned MS-Office in Skill set!] to WPF and WCF.

These are really jargon driven people who just think that they are commodity stocks.

In my opinion what senior developers should possess is;they should be at least good in algorithms. Not some Google’s page rank kind of algorithms but just real ground work algorithms like searching sorting and building up stack queues will be good enough.

Second most important thing is ,they should not be so much affectionate to some language’s syntactical curry rather I dare to say that even if they can write some good pseudo code I am fine with them.

Concept Implementation and differentiation is also good area where senior developers could look at. Inheritance, polymorphism implementation in various OO languages like C++, PHP, C# or Java should be known.

Last but not the least they should possess some good hobby that they really care about. Yes, this is crucial to look at from wide angle into life and things that falls beside computer knowledge. It will surely help them to grow into a good leader or good team player.

Share this post :

Why Your Agile Project Can Not Be A Success

  1. You think agile is iterative waterfall.
  2. Somebody from your top management told you to use “agile” methodology on your project.
  3. You think Product Backlog = project plan,iteration = milestone , scrum-master = project manager,sprint retrospective = project status meeting and agile discipline = micromanagement.
  4. The sales team decreased your estimates because they believe you can work faster.
  5. You use same estimation techniques for waterfall and agile project.
  6. Project estimates magically match the budget.
  7. You have project manager on the project who is in charge of everything.
  8. Every Friday, your project team work on data collection and prepare metrics for your project managers.
  9. Your team do not have scrum master.
  10. Scrum Master do not participate in coding and testing.
  11. Your Scrum Master do not understand the acronyms DRY, YAGNI, or KISS.
  12. You had all the requirements predefined in specification document and you think project will be get executed according to specification.
  13. You think design activities are ,a time to fully and accurately define designs and models in great detail and programming as a simple translation of these to code.
  14. You try to plan a project in great detail from start to finish.You try to speculatively predict all the iterations and what should happen in each one.
  15. Your managers swear by Microsoft project.
  16. Your managers haven’t read “Peopleware” and “Mythical man Month”.
  17. You do not know anything about your team’s “velocity”.
  18. Your project teams don’t have burn down charts.
  19. You define all the architecture upfront at the start of the project.
  20. You have only one iteration.
  21. You think refactoring as a rework.
  22. The last book read by your senior developer is “Mastering VB 6.0”.
  23. Your software architect work in silos.
  24. There is no or minimal feedback and adaptation;users are not continuously engaged in evaluation and feedback.
  25. You think  “Test engineers”  cannot be introduced from day one of project since no code is developed.
  26. Everyday your developers work until Midnight everyday.
  27. You think software quality means creating some CMM compliance documents.
  28. Your QA team does not know how to code.
  29. Your test engineers could not code.
  30. You have specialized roles on your project teams like developers,test engineers,project managers.
  31. Your developers do not practice J/N Unit.
  32. You see deviations from requirements or design during later steps ,as failure or concerns in not having sufficiently skillful or through.Next time,you try harder to get it right.

If despite all these odds, if somebody is claiming that their projects are successful then I have no doubt that there are some software heroes working in their organization;who might be thinking of leaving that organization 😉