Karmona's Pragmatic Blog

Don't get overconfident… Tiny minds also think alike

Karmona's Pragmatic Blog

Strategy Games

January 12th, 2015 by Moti Karmona | מוטי קרמונה · No Comments

StarCraftII

A few things I have learned from *countless* hours playing Strategy Games for more than 35 years (e.g. Chess, Go, Risk, Archon, Warcraft, Red Alert, AoE, Age of Mythology, StarCraft, etc.)

  • Plan a head | Map ALL possible “Candidate Moves” | The idea of candidate moves was first put forth by Grandmaster Alexander Kotov in his book “Think Like a Grandmaster”.
    In it, Kotov recommended looking for several moves that seemed feasible – the so-called candidate moves – and then analyzing those moves one at a time.
  • Adapt | You must adapt very quickly if you want to win
    • OODA loop – Observe, Orient, Decide, and Act (developed by military strategist and USAF Colonel John Boyd) | An entity (whether an individual or an organization) that can process this cycle quickly, observing and reacting to unfolding events more rapidly than an opponent, can “get inside” the opponent’s decision cycle and gain the advantage.
    • “If your enemy is secure at all points, be prepared for him. If he is in superior strength, evade him. If your opponent is temperamental, seek to irritate him. Pretend to be weak, that he may grow arrogant. If he is taking his ease, give him no rest. If his forces are united, separate them. If sovereign and subject are in accord, put division between them. Attack him where he is unprepared, appear where you are not expected” ~ Sun Tzu, The Art of War
    • “It is not the strongest of the species that survives but the most adaptable” ~ Charles Darwin
  • Strategic Patience | “Timing Is Everything” | Sometimes you need time to place your pieces in the proper position before you can attack effectively; a premature attack will backfire.
  • Speed Matters | Have you ever experienced a “Zerg Rush” @ StarCraft? – If you are fast enough, you can win in less than 5 minutes.
  • Know (+ Play) your enemy
    • “To know your Enemy, you must become your Enemy.” ~Sun Tzu, “The Art of War”
    • “In the moment when I truly understand my enemy, understand him well enough to defeat him, then in that very moment I also love him. I think it’s impossible to really understand somebody, what they want, what they believe, and not love them the way they love themselves. And then, in that very moment when I love them… I destroy them” ~Orson Scott Card, “Ender’s Game”
  • The Art of Sacrifice | In his book “The Art of Sacrifice in Chess”, Rudolf Spielmann distinguishes between real and sham sacrifices. A “sham” sacrifice leads to a forced and immediate benefit for the sacrifice… On the other hand, “real” sacrifices, according to Spielmann, are those where the compensation is not immediate but more positional in nature.
  • Sometimes it is worth losing and not to sacrifice the queen ;)
  • Threat is stronger than the execution” ~ Aron Nimzowitsch | The idea is that by threatening an action, you can nudge your opponent in a certain direction. But actually carrying out the threat may cause as many problems for you as for your opponent.
  • “The best form of defense is attack ~ Carl von Clausewitz
  • Determination | “It ain’t over till the fat lady sings” | This is true both ways. Don’t assume you won until the end and don’t assume failure until the last minute | “It is not sufficient that I succeed – all others must fail” ~ Genghis Khan
  • Easy is bad – If it goes too easy, something is wrong
  • Good opponents make you stronger | “That which does not kill us makes us stronger” ~ Friedrich Nietzsche
  • Play the hand you’re dealt | Improve incrementally and be PATIENT. You will have your chance to win many times.
  • Different phases of the game require different skills.
  • Master your Emotions | “An action committed in anger is an action doomed to failure” ~ Genghis Khan
  • Think outside-the-box. You must be creative with surprise moves to defeat a human enemy.
  • Play by the rules. Follow the rules or you might be disqualified.
  • Focus and Mass Matters | Concentrate combat power at the decisive place and time
  • Deception | “All warfare is based on deception. Hence, when we are able to attack, we must seem unable; when using our forces, we must appear inactive; when we are near, we must make the enemy believe we are far away; when far away, we must make him believe we are near” … “Appear weak when you are strong, and strong when you are weak” ~ Sun Tzu, “The Art of War”
  • Synergies Create Better Results | Leveraging the strengths of your armies so that the units are protecting each other while pushing forward is a timeless strategy in RTS games
  • Resources Management is crucial | Queues, priorities and timing can make all the difference with your resource management | “An army marches on its stomach” ~ Napoleon Bonaparte
  • Never mistake tactical success for strategic direction | Make sure that when you’re investing in short-term returns, you’ve also got plans in place to make longer-term strategic investments.
  • A chain is only as strong as its weakest link | Know the strengths and weaknesses of your team. You can’t win alone!
  • Counter-offensive | A strategic offensive taking place after the enemy’s front line troops and reserves have been exhausted, and before the enemy has had the opportunity to assume new defensive positions
  • Economy of Force | Allocate minimum essential combat power to secondary efforts
  • Intel is key | Scouting your enemy is crucial
  • Master the Micro | The best gamers excel in both Macro and Micro | Amazing strategy will not survive mediocre execution and vice versa
  • Study (game) history, because history has a weird tendency to repeat itself

 

 

→ No CommentsTags: Leadership · Planning · Psychology · Strategy

Underestimation is Underestimated

April 19th, 2010 by Moti Karmona | מוטי קרמונה · 8 Comments

Underestimation is Underestimated (a.k.a. Overestimation is Overestimated)

Sometimes it seems like we have an underestimation gene embedded really deep in our cognition but for some “obvious” reason (e.g. underestimation! :) most manager will rather “fight” overestimation and *not* underestimation.

Disclaimer: I have originally estimated this post will take ~33 min but it took me ~240% more time… (this is why I prefer to tweet lately ;)

Six annoying facts about our (/homo sapiens) planning or estimation “skills”:

  • We are basically optimistic and have strong desire to please
  • We tend to have incomplete recall of previous experience
  • We tend to have focus bias when estimating e.g. estimating only the coding phase estimations which is only ~14-37% of the required work
  • We tend to postpone what we can a.k.a. “The Student Syndrome”  (Eliyahu M. Goldratt, Critical Chain)
  • “It always takes longer than you expect, even when you take into account Hofstadter’s Law (Douglas Hofstadter, Godel, Escher, Bach: An Eternal Golden Braid)
  • We tend to underestimate task completion times – a.k.a. The planning fallacy

Overestimation is Overestimated

“The developers say that this project will take 6 months… I think there’s some padding in their estimates and some fat that can be squeezed out of them…we also need to instill a sense of urgency in the development team… so I’m going to insist on a 3-month schedule. I don’t really believe the project can be completed in 3 months, but that’s what I’m going to present to the developers. If I’m right, the developers might deliver in 4 or 5 months. Worst case, the developers will deliver in the 6 months they originally estimated” (Does this ring *any* bell???)

Four reasons on managers tendency to “fight” overestimations:

  • Underestimation (see above :) | “The feature estimation seems bloated” | “Isn’t it 20 min work?” | “Just add another index to the %$^&ing table?” | “It is only one more button…”
  • Unreasonable time constraint | “We need this feature yesterday” | “Nothing is impossible for the man who doesn’t have to do it himself” (A. H. Weiler)
  • True belief that Parkinson’s “Law” is really a law – “Work expands so as to fill the time available for its completion”
  • “The Student Syndrome”  (see above)

So… if feature estimation seems bloated, managers and other project stakeholders fear that Parkinson’s Law and the Student Syndrome would kick in and therefore consciously squeeze the estimates to try to control it (a.k.a. “The Parkinson’s Squeeze”) and when we squeeze where it isn’t needed or was squeezed already, it immediately lead to… UNDERESTIMATION (!!!)

Underestimation is Underestimated

Underestimation creates numerous problems – some obvious, some not so obvious.

  • Reduced effectiveness of project plans – Low estimates undermine effective planning by feeding bad assumptions into plans for specific activities. They can cause planning errors in the team size, such as planning to use a team that’s smaller than it should be. They can undermine the ability to coordinate among groups – if the groups aren’t ready when they said they would be, other groups won’t be able to integrate with their work. If the estimation errors caused the plans to be off by only 5% or 10%, those errors wouldn’t cause any significant problems but numerous studies have found that software estimates are often inaccurate by 100% or more (see above). When the planning assumptions are wrong by this magnitude, the average project’s plans are based on assumptions that are so far off that the plans are virtually useless.
  • Statistically reduced chance of on-time completion – Developers typically estimate 20% to 30% lower than their actual effort. Merely using their normal estimates makes the project plans optimistic. Reducing their estimates even further simply reduces the chances of on-time completion even more.
  • Poor technical foundation leads to worse-than-nominal results. A low estimate can cause you to spend too little time on upstream activities such as requirements and design. If you don’t put enough focus on requirements and design, you’ll get to redo your requirements and redo your design later in the project – at greater cost than if you’d done those activities well in the first place. This ultimately makes your project take much longer than it would have taken with an accurate estimate.
  • Destructive late-project dynamics make the project worse than nominal Once a project gets into “late” status, project teams engage in numerous activities that they don’t need to engage in during an “on-time” project… below are some examples when the important characteristic of each of these activities is that they don’t need to occur at all when a project is meeting its goals, these extra activities drain time away from productive work on the project and make it take longer than it would if it were estimated and planned accurately
    • More status meetings with upper management to discuss how to get the project back on track
    • Frequent re-estimation, late in the project, to determine just when the project will be completed.
    • Apologizing to key customers for missing delivery dates (including attending meetings with those customers).
    • Preparing interim releases to support customer demos, trade shows, and so on. If the software were ready on time, the software itself could be used, and no interim release would be necessary.
    • More discussions about which requirements absolutely must be added because the project has been underway so long.
    • Fixing problems arising from quick and dirty workarounds that were implemented earlier in response to the schedule pressure.

Tip of the day
Never intentionally underestimate. The penalty for underestimation is more severe than the penalty for overestimation. Address concerns about overestimation through control, tracking and *mentoring* but not by bias.

****************************************

More related posts (a.k.a. people who read this post also read these posts)

→ 8 CommentsTags: Management · Planning · Project Management · Psychology · Software Management

The Cone of Uncertainty in Pastel

April 18th, 2010 by Moti Karmona | מוטי קרמונה · No Comments

“The further a project progressed, the more accurate the estimates for the remaining effort and time became”
(Barry Boehm, “Software Engineering Economics“, 1981)
 
NASA also came to the same conclusion that in the beginning of the project life cycle (i.e. before gathering of requirements) estimations have in general an uncertainty of factor 4. This means that the actual duration can be 4 times or 1/4th of the first estimations…
 
I felt very free to add my own interpretation of the different point-of-views with cool pastel colors as a sneak-peak cool-beta-preview of my next post.

Make sense?
 

 

→ No CommentsTags: Development · Management · Planning · Project Management · Software Management

Software Release On-Time

February 22nd, 2008 by Moti Karmona | מוטי קרמונה · No Comments

The British merchant ship Madagascar

“The British merchant ship Madagascar set sail from Melbourne in August 1853, headed for London and carrying 60,000 ounces of gold dust. – She was never seen again…” (http://www.futilitycloset.com/2008/01/29/overdue/)

Well… Saying “no more gold dust” is the only way I know to close a software release on-time…

P.S. Did you noticed that the Mona Lisa has no eyebrows. (http://www.futilitycloset.com/2008/02/12/trivium-16/)

→ No CommentsTags: Management · Planning · Project Management · Software Management

Pragmatic Time Estimation

November 8th, 2007 by Moti Karmona | מוטי קרמונה · 1 Comment

Software Project Management Life CycleMy rough estimation is that the number of software project managers in the world is smaller in (at least) one scale from the conceived time-estimation techniques and this post is my humble four-cents contribution on how to do pragmatic time estimation for software projects (just finished one in Delver).

  • Start with the mother of all lists to store your Product Manager wish list– We use eScrum Product-Backlog to store our work-items
  • Prioritized them – We use 0-Yesterday; 1-Must; 2-Important; 3-Nice-to-Have and 4-“Forget-About-It”… ;-)
  • Get relative estimations on all items
    • Granularity is the bronze-bullet for time estimations – Strive to the finest grained possible in reasonable time-frame  e.g. We usually aim for 2-5 days granularity in 2-3 days of time-boxed-estimation-period since the finest granularity in planning without reasonable time-box might take twice the time of doing the planned work (a.k.a. The Estimation Paradox)
    • Experience can turn your bronze bullet into silver one (ye ye, a silver one) – Relative estimation is calculated relatively upon a common scale of known work items from the team history e.g. We use Scrum “Story Points” and constantly measure the team velocity for time estimation adjustments
    • Fibonacci sequence (0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89 etc.) can be used to “embed” the complexity and risk of rough (with insufficient drilldown) estimations e.g. if your estimation granularity for specific task reach ~40 days then your pragmatic estimation should be around 55 days (= the closest Fibonacci sequence) since it is reasonable to believe your (insufficient) granularity conceals risk, complexity and unknowns issues which requires Fibonacci-like-“buffering”
    • Strive to synchronize your time estimation techniques into very simple one – different time estimation conventions in the same development team is the 2nd reason for time delays. (I will give 0.95$ grant if you can guess what the 1st reason)
    • I know I am different but personally, I do prefer to have “pragmatic hours” vs. the normal Agile “ideal hours” and to start the project when 1 “Story Point” =  1 “Pragmatic Day” so long everyone understand this will change as soon as you start the project and then you need to return to velocity tracking to calculate the end
    • Don’t be naïve (a.k.a. “Ideal  Days”) with two known flavors:
      • Optimistic time estimations,  assuming 24*7 of concentrated programming ability with no outside interference (a.k.a. no such thing)
      • “Stupid” hand-waiving time estimations a.k.a. It is only 10 min to code this (but ~5 days to Integrate, Review, Design, Test, Schema and DAL changes, I18N support, Styling etc.)
  • Get the rough project estimation = Sum of all product backlog story points / 22 (work days in month) / Number of relevant people
    • Usually this calculation will show you don’t have enough time for the project (even without project dependencies buffer which can be added later)
    • Start the “Tradeoff Game” – Try to cut items (content) based on the relative ROI
    • Revalidate your priorities since they will be the main tool (beside dependencies) for creating the project work plan.

As I see it, estimating software projects in a realistic time-frame is a statistic prediction of chaotic, time-delay-series of events and will never be straightforward nor easy so you can only do your best in the estimation and then track the project as it goes and make the needed adaptation on the way upon crystal clear project priorities.

Good Luck!

→ 1 CommentTags: Agile · Delver · Development · Management · Planning · Project Management · Scrum · Software Management