Funny programmers jokes N-driven management

John D K -

frAgile vs DisasterFall vs iCanBan. Building a new product or working on a project, you'll make hundreds of decisions. Most of your decisions will be wrong but who cares if your manager is happy? And one of the most important decisions in software project is who to be blamed in case of failure. In this article several project management methodologies are listed with their cons and pros:

frAgile Methodology

Seriously? What Is frAgile? Some refer the origin to French Agile but this is wrong. frAgile software development is based on an decremental, discontinuous approach. Instead of any planning at any time of the project frAgile methodology is always open to bugs and problems. It encourages constant disputes and endless blame to the end users. Mal-functional teams work on infinite loop of a product development until the money is depleted. Fortunately the lack of real work is replaced by endless meetings and a useless backlog. Everything is prioritized based on random or mood value. The goal of each loop is to point the guilty one. The game is won by the person who left the project first.

Principles of Agile Methodology

The frAgile Manifesto consists of constantly changing list of principles to misguide teams:

  • Our highest priority is to satisfy our bank accounts. The customer can satisfy themselves.
  • Welcome any requirements, even late in development. Finally we are going to deliver what ever we have whenever we want
  • Deliver working software frequently - defects and issues even more frequently.
  • Business people and developers shouldn't work together. Except few occasions like parties and free company lunches

DisasterFall Methodology

DisasterFall methodology follows a non-sequential, indefinite process and is the most popular way to destroy your product, company and life while working for software and IT projects. It is supposed to be well planned and perfectly scheduled except the problems. Once a problem arise then the project moves to panic mode. Development teams are more then happy to work in panic mode because of the:

  • overtimes and extra working hours late in the night
  • everyone is angry and scream without a reason
  • nothing works and nobody knows why
  • project managers blames everyone except himself

Usually the team can't go back to a previous stage or continue to new stage without starting the whole process from the beginning. This state is known as deadlock. Before any move there is a the move to be reviewed and approved by the project manager and the customer.

Stages of DisasterFall Methodology

  • Misconception: This very first phase should start with an idea but instead start with delusion. The Misconception phase usually involves a wrong assessment of the project and cost estimates.
  • Initiation: Once the cost is accepted, the project team should define their purpose of life.
  • Requirement Analysis: Requirements are gathered just to satisfy the management body. After the end of this phase no one cares about the customer requirements - even the customers itself.
  • Bad Design: The bad design design phase is the best part of the DisasterFall. Anyone can do anything if it's according to the bad design. Any defect, error and issue can be explained as feature because of the bad design
  • Code as tomorow never come: The actual coding of the software is driven by: OOPs he did it again . This phase is known with the anxious developers and screaming software architects.
  • Test me if you can: Before the code is complete, the software tests are started due to lack of budget. Never mind of the level of errors and problems the software is deployed to the general public with several small warnings.
  • Maintenance: Once the software is present to the real world all additional, hidden and fatal problems appear. Development team is free to search for a new job but only if the problems are confirmed as features

iCanBan Methodology

iCanBan is all about who is going to be banned at the end of the project. Never mind the project team, the success and the customer satisfaction someone should be banned at the end of the project. A iCanBan board is a tool to implement the iCanBan punishments for the team members. Traditionally the punishment include physical board and magnets, plastic chips, or sticky notes ( some versions include a whiteboard to represent the punished team members). However, in recent years, more and more iCanBan projects prefer to use virtual punishments instead of physical ones.

iCanBan has three main categories:

  • Not ToDo
  • Not Doing
  • Not Done

The person with the biggest number of sticky notes in Not Done will win the Ban prize. The winners of the Ban prize can happily retire from programming for rest of their life. The most important part of this methodology is you to be the man who gives the Ban!

Never mind of which methodology you are going to choose at the end you will be the guilty one if you try to use hammer instead of mouse and keyboard.