Karmona Pragmatic Blog

To my humble opinion they are very much alike but Scrum do take project management to the extreme (like everything else) so the bottom line for me is that:

Scrum Master = Extreme Project Manager

…

(short post and without internal references this time but I couldn’t resist the bold stuff ;-)

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…

Since I have just started blogging I find myself managing a blog-backlog; so… in the name of transparency and simplicity, I am going to keep my backlog inside the blog (a.k.a. “the backlog inside paradigm”)

(Last updated on 26-07-07)
Game Theory & Agile Development
Green Managers
The Project Manager
PMO vs. Scrum-Master
Short History / Scrumming
3rd Party Software Usage
Managing Shitty Legacy Code
How to end a research…?
Silver Bullet Software Foundation
Edsger Wybe Dijkstra (GOTO)
Scrum by “Natural Selection” / Agile-Shmegile [Scrum-Master Jar Jar :-) ; Agile Methods - Beyond the Hype ; Critique on XP ; Does XP/Scrum Violate the “Agile Manifesto”? ; Good Agile, Bad Agile ; Extreme Programming Considered Harmful for Reliable Software Development ]
Running Managers
Jim Collins, Level 5 Managers
People People People
BHAG
Jim Collins, Hedgehog
Development Methodologies – Best Practices
Development Methodologies – Shared Dilemmas

This post is going to change so don’t get used to it but feel free to comment if you want to order something for my next post sprint…

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.

“The major problems of our work are not so much technological as sociological in nature.” (Peopleware, 1987)

I think that human capital is the silver bullet* for successful software projects – productivity, personalities, teamwork and group dynamics will make or break a project.

Picking the right people is maybe the most important managerial task so on your next interviews please remember** that knowledge can be easily acquired but personality is there to stay.

Don’t spend 90% of your interview time on knowledge when personality (and potential) is the real key for successful recruitment.

——————————————————–
* Although “Peopleware” have a full chapter on how there is no silver bullet… but I partially agree since I never said it will be easy to get to the human capital silver bullet…
** Also remember: Somewhere today a project is failing… and I can personally guarantee that people were somehow involved in its failure!

Green Managers – Five top common mistakes with two cent tips.

Vision???
Managing is more then juggling day-to-day tasks – Make a difference, lead to change… Construct a vision, set goals and encourage innovation.Delegation-less: “Never mind, I will do it…”
Simply start delegating like hell!

Sagemet – (Hebrew Slang, The sickness of a green officer in IDF) – You don’t let yourself be human and you fall in-love with your new title.
Remember, management title does not elicit automatic respect and obedience and just because you are the boss doesn’t mean you can’t be human – Feel free to laugh, show emotion and you can even make an occasional mistake ;-)

Mr. Know-all – You think you know everything.
Be sure you don’t know everything is maybe is maybe the most important part of getting into new managerial position. Listen to the people around you and keep an open mind.

Ooops, employees…
As a manager you must remember the three most important success factors: 1. People 2. People and surprisingly enough 3. People
Listen to your employees, take the time to know them, empower them, tell people what you want, not how to do it, don’t put policies ahead of people etc.

Good Luck!

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…

2 weeks ago, I have decided to leave a promising (& cozy) career @ Mercury to join a challenging new-born start-up.

As most of you already know, moving between jobs is an hectic yet purifying transition which can only resemble a month of tantric yoga (which I didn’t have the pleasure to experience yet)

So stay tuned since more details will follow only after I will finish the transition period (~September)…

—
Dear Mercury familia, thank you all for the amazing ride! it was a privilege to work with you and I wish you all the best… keep in touch.

The Pareto principle (a.k.a. the 80-20 rule, the law of the vital few and the principle of factor sparsity) states that, for many events, 80% of the effects comes from 20% of the causes. (e.g. Your wife might claim that you wear 20% of your closet clothes about 80% of the time… ;-)

I will argue that pareto principle conceals one of the most important princples in software (and not only in software) management – Don’t try to do more. Just do more of the right things!

exempli gratia

* Don’t invest too your time in dark software corners since the same principle will catch you with investing 80% of your force with only 20% value (e.g. What will happen if someone disconnect the database network cable 1 minute before DST transition… etc.)

* Don’t over design since you will bump into the 80% investment for only 20% value again – Don’t drill the holes for air-condition system before you have one, since you might find yourself a bunch of holes in the wall…

* While planning, always ask yourself if you can do more for less and try to find that thin-gray-line that cross the 21% effort for the 81% value* - try to identify how to invest minimal effort (~20%) to create enough (~80%) business value.

* In performance tuning you want to find the silver bullet that with minimal effort (let’s say 20%) solve 80% of your issues (a.k.a. low hanging fruits)

* Workforce wise – Jack Welch’s vitality model has been described as a “20-70-10″ system. The “top 20″ percent of the workforce is most productive, and 70% (the “vital 70″) work adequately. The other 10% (“bottom 10″) are non-producers and should be fired. Rank-and-yank ideologues credit Welch’s rank-and-yank system with a 28-fold increase in earnings (and a 5-fold increase in revenue) at GE between 1981 and 2001 – Obviously, this is a tremendously competitive model of organization and all criticisms of both the morality and (in)effectiveness of such a Dog Eat Dog method of social cohesion apply but as a manager you must take this in mind since reality and statistics (law of large numbers) do show that the “top 20″ percent of the workforce is most productive and is doing 80% of the work…

I would even dare claiming that, perfectionism is a strong indication for weak leadership!

——————————————–
* Note: I was told that everyone knows this principle but the question is how to do it… so my tip (and I promise to post more around this dilemma) is to handle this with-in the scoping of the feature or module; efficient scoping should get very fast to ROI (look for the items with low ROI) and risk analysis (look for the items in high risk and try to understand where the risk come from) and soon after the tradeoff discussion which is the perfect time to take the hard “cutting” decisions and for doing this you must have someone in the room with deep customer understanding; e.g. In most systems it is very “easy” to cut enterprise-readiness features to simplify development (I18N, Security, Upgrade, Scalability, High Availability, Distribution, Monitoring etc.) and many of those features can be added later if needed with no real overhead (warning: you must know what you are doing to make it work so don’t try this at home if you don’t have professionals with you);

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.