Karmona's Pragmatic Blog

Don't get overconfident… Tiny minds also think alike

Karmona's Pragmatic Blog

Scrum and Your Mother-In-Law

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

Flintstone Mother-In-LawKen Schwaber was quoted giving this mind-blowing Scrum / mother-in-law allegory:

“imagine that your mother-in-law believed her daughter could do better… and then imagine that she moved in with you… that’s what Scrum is like”

Think about it…

Assuming we shouldn’t aim to completely avoid all errors in software development (since this is an inherent part of any human creation) but rather to spot them as quickly as possible before they become real problems.

And… since Scrum is indeed a very good “tool” to bring the problems in-your-face without any mercy in a daily manner.

So without even getting into the continuous improvement possibilities with mother-in-laws, I really liked the Mother-In-Law allegory :)

By the way, with great anticipation I have proudly joined the Haiku contest @ the famous Ktorium – Wish me luck! :)

→ No CommentsTags: Agile · People · Project Management · Scrum · 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

Scrum Clan

October 9th, 2007 by Moti Karmona | מוטי קרמונה · No Comments

Pasha Bitz is a Scrum-LoverOren and I, have decided to form an invite-only Scrum Clan.
We would like to tag Pasha Bitz (snapshot attached) as the 3rd clan member.

Pasha, please choose carefully, you can only tag one Scrum-Lover like yourself to this distinguish clan….

Good Luck!

P.S. The web 2.0 tag was added to this post since it is a genuine-user-generated-content-post especially made for Pasha

Google Trends (a.k.a. my experiment – part III)

  • Clytie Lane
  • Moon Bloodgood
  • Deceptively Delicious
  • Rotten Neighbor
  • Melinda England

→ No CommentsTags: Agile · Delver · Scrum

Chronicle of a Death Foretold

September 20th, 2007 by Moti Karmona | מוטי קרמונה · No Comments

Chronicle of a Death Foretold = Waterfall Shmoterfall = Checkmate in 10 movesChronicle of a Death Foretold = Waterfall Shmoterfall = Checkmate in 10 moves
* Note: I did see, participate and lead some successful waterfall projects (mainly due to some adoption of agile methodologies ;-) and this is my view of the projects which failed…

  1. Release scoping start with marketing high-level-copy-paste-from-last-year-marketing-presentations MRD in ~1 month delay
  2. 1 month of quick lets-write-all-the-features-we-can PRD – This is also the last time you hear from the product manager until the next milestone-demo-crisis.
  3. High level design for a couple of weeks which sum-up to a Very Rough Time Guesstimate a.k.a. VeRTiGo
  4. Release time-frame is set ~1 year ahead with the needed VeRTiGo “squeezing” and high level time-frame is determined:
    • 2 months of the waste above and last release leftover
    • 1-2 months of Planning (functional and technical design)
    • 4-5 months of Development – with ~3 Major Milestones
    • 3 months of QA & stabilization
    • 1 month of Project Buffer
  5. Very soon the development teams are scattered like lonely wolfs – everyone for himself until the next integration or major milestones months away.
  6. First milestone is ending with:
    • 20% of the content is really Done a.k.a. “Even a Blind Chicken Finds a Kernel of Corn Now and Then”
    • 50% is “done” with dirty bugy code, low quality, performance issues with missing or wrong functionality
    • 30% is just not ready
  7. Developers and low level management remind themselves yet again to put more buffers…
  8. The PMO suggest (in relax and trusting tone) to postpone the milestone or remove content.
  9. Management doesn’t get in panic (they have seen it before ;-) and decide not to decide: “Let’s see if we can cut the drawback in the next Milestone” a.k.a. The classic do {} while(timeRemaining > Last Milestone)
  10. Next milestone has much more content and the pressure builds up… until the last milestone blaming game which usually ends up with ~2 month delay and half of the planned content.


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

Internet Service Outage-Lie-of-the-Day

September 10th, 2007 by Moti Karmona | מוטי קרמונה · No Comments

Dilbert on Network Outage

Almost a month ago, I have moved to my own hosted blog due to google blogger outage.

Last week (September 3rd ~00:00), I was visiting BlogCatalog and I got the Internet Service Outage-Lie-of-the-Day: “Database Error – We’re sorry, but our database servers are currently overloaded. Please enjoy a cup of coffee and then try refreshing this page – Blog Catalog” [BlogCatalog Outage September 3rd – 2007] … so I followed the site recommendation and I have enjoyed a great cup of Italian coffee but I was very sorry to see that it didn’t helped the BlogCatalog database to recover…

These days, we are working intensively on the last sprint goals; One of the goals was to finish the architectural design of our unique internet service.

So… Yesterday we where guesstimating (until the very late hours of the night) on the scale needed for this service and started mapping the IT topology, Database implementation and software back-end options that are viable to support it.

Dilbert plan to Network Outage

I have a lot to say on the process, technology challenges and options for my future posts and I can sum it up now saying: We all hope that by taking the right decisions when reaching a critical-architectural-junction these days, we will be able to enjoy a good cup of Italian coffee while our databases are down for maintenance… but we also know that simple risk management on our guesstimates is also to be prepared for rainy days with a good enough Internet Service Outage-Lie-of-the-Day ;-)

→ No CommentsTags: Blogging · Delver · Internet · Planning · Scrum