July 26th, 2007 by Moti Karmona | מוטי קרמונה · 3 Comments
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 …
For using all the right buzzwords e.g. Flexibility; Transparency; Short-term predictability; Long term vision ;-)
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.
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…
Tags: Agile · Development · Planning · Project Management · Scrum · Software Management
July 16th, 2007 by Moti Karmona | מוטי קרמונה · 3 Comments
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…
Tags: Agile · Development · Pareto