February 1st, 2008 by Moti Karmona | מוטי קרמונה · No Comments
Updates from “Rabbit-Hole”
We came out of stealth mode at Demo Conference…
We have a new Facebook page @ http://www.facebook.com/pages/Herseliya-Israel/Delver/7851012277, our IT operation is ready …and we are still looking for Smart people to join us…
January 4th, 2008 by Moti Karmona | מוטי קרמונה · No Comments
“Oh dear! Oh dear! I shall be too late!” (Alice’s Adventures in Wonderland)
I am currently deep down the Rabbit-Hole…
Cya after the Delver* Alpha ;-)
November 18th, 2007 by Moti Karmona | מוטי קרמונה · No Comments
Delver is looking for great people to join our A-Team (Excuse my “eighties”)
Please email us (jobs @ delver. com) with resumes if you are ready for the delver challenge.
November 8th, 2007 by Moti Karmona | מוטי קרמונה · 1 Comment
My 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.
Tags: Agile · Delver · Development · Management · Planning · Project Management · Scrum · Software Management
November 3rd, 2007 by Moti Karmona | מוטי קרמונה · 1 Comment
My boss have returned from the recent techcrunch with a “brand new multimedia and Internet-enabled quad-band GSM EDGE-supported” iPhone and missed (yet again) the trendy next generation iPhone Killer gadget – iPoor @ http://ipoor.org
Tags: Delver · Simplicity