Karmona's Pragmatic Blog

Don't get overconfident… Tiny minds also think alike

Karmona's Pragmatic Blog

Software Projects Anxiety

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

Software Projects Experience Anxiety Disorder* The 1st manned landing on Earth’s Moon was the Apollo 11 mission on July 20, 1969 and the last one was Apollo 17 on December 7, 1972
* Current U.S. Vision for Space Exploration calls for a human landing on the Moon no later than 2019

2019-1972=47 (!!!)

Someone wise once gave this as a metaphorical example for a common engineers disorder, he called experience-anxiety-disorder, claiming that NASA stopped sending manned missions to the moon since they now know much more about the complexity and risk with doing this.

During the early seventies, it was a nice, naive working implementation but when NASA engineers started thinking about the next release they have built a five-decades-project-plan simply because they considered all the technological experience they have gained into large complexity buffers.

The Moral Lesson
Keep-it-simple can-do-approach and don’t over-complicate things with the long-tail-little-details when not needed or the project will take 5 decades to finish.

How do you know you are have an experience-anxiety-disorder?
If someone ask you to add a button to change the database schema and this make you feel a mixture of fear, apprehension, heart palpitations, nausea, chest pain, shortness of breath and headache.

What to do?
Sit down and relax, drink a cup of water and then add the damn button!

Last Long-Tail-Detail
Well… I don’t want to ruin this lovely moral lesson with the long-tail-little-detail but the real facts behind this 47 years gap were politics and money (as always) and not that NASA engineers got a severe experience-anxiety-disorder.

Google Trends (a.k.a. my experiment – part IV – Almost forgot…)

  • Betty Casey
  • Most Haunted Life
  • Piercing & Tattoos
  • Madonna
  • World War III (…)

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

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.

Checkmate

→ 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

Scrum by “Natural Selection”

July 26th, 2007 by Moti Karmona | מוטי קרמונה · 3 Comments

Agile & DilbertAfter 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…

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

The Project Manager

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

PMO & Dilbert

 

 

 

 

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.

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