If you're into dice-driven board games chances are that you'll love MAD. If nothing else it's hilariously funny, confusing and completely insane all rolled into one. The objective of the game? You have to be the first one to lose all your MAD funny-money before someone else looses all of theirs. The funny feel of the game reflects right on it's cover which has funny pictures and a remark, "What, me worry?".
The board game comes with a printed document which is supposed to be your 'proof of purchase' with a warning inscribed very prominently:
|
DON'T PANIC: |
The game is insanely funny; it is by far the funniest board games I've played till date. In-spite of the warning you will invariable see yourself get into really funny arguments with other players over interpretations of what the cards and board spaces mean.
The game has nothing to do with software development, but overall, the game is a very apt representation of the confusion and chaos that happens in game of software development.
- The customer thinks he knows what he wants.
- You think the customer knows what he wants.
- You have meetings with customers in attempt to try and understand what he thinks he wants.
- You think you know what the customer wants.
- The customer thinks you know what he wants.
- Neither you nor the customer knows what is it that he really wants and how you'll get there.
- You convince the customer that you know exactly what he wants.
Then added opponents of software development start attacking from multiple directions and before you know it, something creepy and weird happens: Everyone Panics.
MAD, the board game begins with the same practical, pragmatic advice that Douglas Adams had picked for his famous book, The Hitchhiker's Guide to the Galaxy:
As far as software development is concerned panic contributes as much to the failure of the projects as much as any other factor.
Chad Myer Provides added insight into why every project usually goes into panic mode:
|
There is a point in every project - well, every project I've ever been a part of in one shape or another - where panic starts. I'm not quite sure what starts it every time, but the ones that I do know of have all been about money and 'burn rate' and I'm willing to bet that all of them (even the ones that were not made known to me) are about that. The point of Agile, in my opinion, is to allow visibility and more frequent opportunity for decision points for the stakeholder for just these types of moments. The appropriate response, when this moment of panic is about to ensue is for everyone, especially the stakeholder, to put on their big boy pants and start making the hard decisions about what to cut. The inappropriate response - oh there are many, but they boil down to this - is to start mistrusting the developers and start assuming they're lazy SOBs who have been cleverly avoiding work throughout the whole project. Looking back, nearly every single time the panic season started, this was the demeanor the stakeholders took. Instantly the project went sour, all pace was destroyed, morale tanked, some people went into psycho 100hr/wk work mode to prove the stakeholders wrong, others proved them right by giving up and not doing anything. Ultimately, the project died a rather undignified and flaming death. Failure resulted (or perhaps success didn't happen to the degree to which it needed to happen), the team burned out and most left while the stakeholder was stuck with a failure product and all their critical brain trust gone or demoralized. |
Ever been a part of a project where the panic button is pressed because the team is failing and someone realizes that it's failing because of lack of policing mechanisms? If you've been a part of any such projects in your life you're probably related to what Chad is saying here. If you, dear reader, have been through this experience, you probably know the feeling and can smell this panic button being pressed based on incidents that start happening. Office timings are made stringent, holidays and leaves are canceled, emails lose their touch of basic niceness, dead-lines for every single task are asked, micro management begins and everything starts failing apart.
I've seen quite a few Agile projects fail when the panic situation becomes public knowledge. After all, transparency is the biggest blessing and curse of Agile or simply an open culture in general. It brings the chaos and panic right on your face, forcing the weak hearted to either abandon it or press the panic button and replace the fundamental premise of trust on which Agile Projects are built are managed with policing measures and mechanisms.
I've often seen individuals accuse agile as being an excuse for being sloppy, but agile, by far, requires a huge deal of talent and discipline within, the development team and entire organization. In fact it requires more talent and discipline than any other process I've seen in my life. Chad in his post explains:
|
This is it, there's no turning back. Everyone on the team - stakeholder and producer alike - must trust each other to make the hard decisions and cut what they must to make the plan happen. You must resist the urge to bear down, roll up your sleeves and do everything wrong as fast as you can and ruin everything you've strived for. It's during the hard, trying times that discipline pays its debt. Soldiers don't go to boot camp to learn how to salute during peace time, they go there to learn how to be disciplined when the bullets are whizzing past your ears. |
All of Agile is about forcing you to take the correct and sometimes hard decisions sooner than later. It won't give you a cozy feel of the 'green status report' when things are not fine. Software development is much harder than losing all your money in MAD. Before you start the software development game, the least you can do is remember the rules from MAD:
|
DON'T PANIC: |
If you are a young and budding manager, developer or whatever-it-is-that-you-are, I leave you with one humble thought, that you can put on your not-to-do list. Take the hard decisions if you must, cut down on features if you must, motivate and train your team to work independently if you must; whatever you do; don't police and don't panic; because that is what spreads like wild fire and causes everything to fall apart.
Comments are closed.