Karmona`s Pragmatic Blog

1^st Warning: Chaotic post below

Software project are chaotic system and are highly sensitive to their initial conditions (a.k.a. the butterfly effect) and dynamics (e.g. wrong design, vague requirements, team professionalism etc.).

To master (/control) a software project you must be able to breathe (/smoke ;-) the project - inhale the chaotic butterfly movements around you and exhale with the needed adjustments or you will be crushed on the nearest project failure shore with zillions of butterfly excuses.

2^nd Warning: Smoking software project is bad for you health

After a decade of software projects smoking I find myself easily doing a background-surfing on the chaotic edges of my projects like I drive my car in the same daily well known route back from work but since I am part of the same chaotic system I am trying to control, I know that my background-surfing is like forgetting my own butterfly wings.

Software project smoking isn’t a social event and can’t be easily shared but it is also one of the key factors in projects surfing – If you will not be able to share your surf experience with your team, your own butterfly wings will bring the next tsunami.

3^rd Warning: Don’t practice management if you don’t like the butterflies

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 Semingo).

• 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!

Chronicle 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.

Checkmate

The term “déjà vu” describes the experience of feeling that one has witnessed or experienced a new situation previously.

“We have all some experience of a feeling, that comes over us occasionally, of what we are saying and doing having been said and done before, in a remote time – of our having been surrounded, dim ages ago, by the same faces, objects, and circumstances – of our knowing perfectly what will be said next, as if we suddenly remember it!” - Charles Dickens

In recent years, déjà vu has been subjected to serious psychological and neurophysiological research. The most likely explanation of déjà vu is that it is not an act of “precognition” or “prophecy”, but rather an anomaly of memory; it is the impression that an experience is “being recalled” which may result from an overlap between the neurological systems responsible for short-term memory and those responsible for long-term memory.

In other words, “déjà vu” is yet another careless data inconsistency situation due to poor synchronization mechanism and hectic multithreaded race-condition incidents a.k.a. “Dark-Voodoo” bugs (e.g. “déjà vu” ;-)

—

There are many ways in which the deja experience may manifest: deja entendu - already heard; deja eprouve - already experienced; deja fait - already done; deja pense - already thought; deja raconte - already recounted; deja senti - already felt, smelt; deja su - already known (intellectually); deja trouve - already found (met); déjà vécu - already lived; deja voulu - already desired; deja arrive - already happened; deja connu - already known (personal knowing); deja dit - already said/spoken (content of speech); deja goute - already tasted; deja lu - already read; deja parle - already spoken (act of speech); deja pressenti - already sensed; deja rencontre - already met; deja reve - already dreamt; deja visite - already visited and my recent favorite invention: déjà posté – already posted…

Before getting into the Java vs. Net battle lets start with some other options ;-)

If you like challenges then you must try the brainfuck language which was created by Urban Dominik Muller and noted for its extreme minimalism - 240 bytes compiler download here

e.g. you can easily print “Hello World!” and a newline to the screen with the line below:

++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.——.——–.>+.>.

If you favor comments then you might consider using CPL which was created out of a need for advance commenting features, not found in any other existing programming language (e.g. nested comments…) @ http://sourceforge.net/projects/c-p-l/So…

Without copy-pasting a word - I think the best references to the Java vs. Net debate are:

• http://www.oreillynet.com/pub/a/oreilly/java/news/farley_0800.html
• http://www.adtmag.com/print.aspx?id=10993
• & nothing like a good flammable Slashdot discussion to get under-the-hood of this debate…

…Personally, after many years of Java-Java; I really like .Net-ing for the past year… especially after watching Steve Balmer, “Developers dance” @ http://youtube.com/watch?v=NSIMeRtVebM

After watching many Agile project failures and during most of my adult-software-life you could easily bumped into me saying (with agile critiques link referencing embedded :-)
“Agile can only fit hello- world project scale… It is a bad excuse for weak management, development chaos, poor planning capabilities, lousy communication skills and lazy “we don’t need documentation” programmers - There is no silver bullet for handling software but those agile manifesto guys really found the silver bullet buzzword for making money with the scrum-master for dummies certifications…”

…Then came Scrum by “Natural Selection”:

“It is not the strongest of the species that survive, nor the most intelligent, but the ones most responsive to change” - Charles Darwin’s Origin of Species (1859)

…So I have evolved by Natural Selection to Agile and I can’t really go back to over-planned fantasy Gantt charts that try to capture every feature in advance and predict we will finish the project exactly in 666 days …

Why “Agile”?
For using all the right buzzwords e.g. Flexibility; Transparency; Short-term predictability; Long term vision ;-)

Why “Scrum“?
Scrum provides the mechanism for making the people and process problems apparent so they can be solved - It encompasses almost any good engineering technique; very simple, not overly prescriptive and relatively small set of interrelated practices and rules which can be learned quickly and is able to produce productivity gains almost immediately.

Why not???
The main reason as I see it now, is that it is extremely simple but very hard to implement successfully* - Mainly because short iteration cycles, rapid changes and transparency brings project management headache and programmer life to extreme optimization while traditional development processes (e.g. waterfall) give you the misleading euphoria** for very long time-frames (e.g. ~666 days in the above example ;-) inside the traditional project lifecycle

e.g. Transparency forces accountability, responsibility, prioritization discussions, trade-offs, and often scope reduction. Scrum requires that managers behave differently than in the past. Instead of reviewing status reports, managers should attend Sprint reviews and retrospectives. Instead of waiting for team members to prepare and present updates, management should go to the project room and see the project’s task board and burn down chart.

Scrum isn’t a silver bullet* but a simple yet powerful encapsulation of Peopleware mindset, project management patterns and development best practices which can put you on a good starting point when you face the software challenge…

—————————-
* Friendly reminder: no silver bullet in successful software management
** Although I did see few cases where a mixture of skilled project management & legendary engineers have managed to bypass that inherent misleading euphoria while allegedly practicing traditional development process but my claim is that if you look very closely they were actually practicing 90% scrum without even knowing it…

A project manager is a professional* in the field of project management.

A project manager’s main duty is to ensure the success of a project by minimizing risk throughout the lifetime of the project.
This is done through a variety of methods, both formal and informal**. A project manager will usually have to ask penetrating** questions, detect unstated** assumptions, and resolve interpersonal conflicts**, as well as use more systematic management skills.

According to Wikipedia statistics: 69% of project failures*** are due to lack and/or improper implementation of project management methodologies.

I didn’t have the pleasure of being a project manager but I did see some good project manager implementations and this is my recommendation:

Risk Management - Identifying, managing and mitigating project risk

Issues Management - Identifying, tracking managing and resolving project issues

Reporting - Proactively disseminating project information to all stakeholder s(a good web based project dashboard will do the trick)

Quality Management

Scope Management - Proactively managing scope to ensure that only what was agreed to is delivered, unless changes are approved through scope management

Forecasting project trends - Defining and collecting metrics to give a sense for how the project is progressing and whether the deliverables produced are acceptable

Tracking - Managing the overall work-plan to ensure work is assigned and completed on time and within budget

Monitor resources (e.g. allocation, movement, skill matrix, roles and responsibilities)

Define Development Methodology

Managing integrations & dependencies (documentation, shared infrastructure etc.)

Configuration Management

Standardization, rationalization and training of processes & procedures (e.g. customer escalations & patches, customer enhancement request, beta or EA plans etc.)

Manage projects postmortem reviews

There are many things to be said on the project manger role and I know god is in the details Kalish but I was told that my blog posts should be much shorter so I will end it here and I reserve the right to post about it again if needed… (e.g. Scrum-Master vs. PMO post will come real soon)

Good Luck Yonit! ;-)

————————————————————————-
* The term “Professional” should imply that this role isn’t trivial or intuitive as it might sounds or implemented in many organizations

** All the ‘bold**’ words should have “rang the complexity bell” - it will never be easy (or straight forward) and will require a bundle of emotional intelligence

*** When according to the same statistics 90% of projects do not meet time/cost/quality targets.

In game theory, the prisoner’s dilemma is a game in which two players may each “cooperate” with or “defect” (i.e. betray) the other player. In this game, as in all game theory, the only concern of each individual player (”prisoner”) is maximizing his/her own payoff, without any concern for the other player’s payoff. In the classic form of this game, cooperating is strictly dominated by defecting, so that the only possible equilibrium for the game is for all players to defect. In simpler terms, no matter what the other player does, one player will always gain a greater payoff by playing defect. Since in any situation playing defect is more beneficial than cooperating, all rational players will play defect.

The unique equilibrium for this game is a Pareto-suboptimal solution—that is, rational choice leads the two players to both play defect even though each player’s individual reward would be greater if they both played cooperate. In equilibrium, each prisoner chooses to defect even though both would be better off by cooperating, hence the dilemma.

Note: Please read more about it in Wikipedia since there is much more information there then I want to copy-edited-paste into this blog… (especially after reading Kalish’s last blog post)

—The prisoner dilemma is mainly about trust, cooperation and honest communication…

During an interview (back on June 2003) XP founder, Kent Beck was asked when XP is not appropriate?
Beck answered that “It’s more the social or business environment. If your organization punishes honest communications and you start to communicate honestly, you’ll be destroyed.”

So… if a team member cooperates (”communicates honestly”) while the environment competes (”punishes honest communications”).
In terms of the prisoner’s dilemma, this is the worst situation for the cooperator, and so, it is expected that no one will cooperate in such an environment.
Sounds familiar? Did you happen to work in a place where warnings (a.k.a. red flags) tagged you as a complainer? (also connected to the Stockdale Paradox post) or end up with assigned person tripping all over your problem space, trying to figure it out, while you try to implement the solution (When to approach your supervisor with a problem).

It is known fact that Agile methodologies enhances trust among team members by encouraging (as working standard) honest communication and cooperation with Daily Standup Meetings, TDD, Collective Ownership, Pair Programming, Sustainable Pace, Planning Game etc.
Leading me to claim that Agile leads teams into cooperation-cooperation situations and this is exactly where you want to be in your next police interrogation… ;-)

Don’t be caught…

The Stockdale paradox refers to Admiral Jim Stockdale, who was the highest ranking United States military officer in the “Hanoi Hilton” prisoner-of-war camp during the height of the Vietnam War. Tortured over 20 times during his eight-year imprisonment from 1965 to 1973… in Jim Collins book “Good to Great” chapter 4 page 83 (which is by no-doubt a must book) he is quoting Stockdale saying: “You must never confuse faith that you will prevail in the end - which you can never afford to lose - with the discipline to confront the most brutal facts of your current reality, whatever they might be.”

The Stockdale Paradox have much deeper implications than I present in this post and I am only using it to shed some light on The Pessimistic Developer Paradigm

I truly believe that in software projects, the pessimistic developer will win 80% of the software “battles” over an optimistic one (which is more than enough for me as a true believer in the pareto principle).

Don’t be confused with the semantics of what I am saying; we are not talking about this-can’t-be-done developers! - the best developers will keep an “optimistic attitude” (a.k.a. can-do spirit) with an “pessimistic mindset” (a.k.a. what could possibly go wrong?)

A “pessimistic mindset” will bring you to double-check, anticipate and be pro-active in mitigation of possible points of failures.

Saul Lieberman said ”The difference between a smart man and a wise one is this: A smart man can work his way out of a difficulty that the wise man will not get into in the first place”

I heard it many times and saw it in real life more than once so don’t “kill” the pessimistic messengers in your organization…

Keep being pessimist in the tacticalities (I want to patent this term :-) and insure your strategic success.