This post is about Agile, not football. I like to use analogies so please, please don't crucify me!
The football analogy
In 1983, at Superbowl XVII, the Washington Redskins beat the Miami Dolphins. It was a game my wife, who was born in the Washington DC area, reminds me of every time the Washington Redskins play a game. Mind you, I'm usually not watching the games. I'm off pondering what I would do if zombies tried to storm our home. Do I have enough plywood and nails? Do we have enough ammunition? But I digress.
So, what was unique about this particular team that made them so successful? Was it their head coach, Joe Gibbs? Was it the coaching staff, the team, or all of the above? Was it a simple process or detailed approach? I guess if they knew what the magic formula was, they would have repeated the winning season over and over again. Unfortunately, life doesn't work like that and neither do projects or football teams. The Washington Redskins have won only 2 Super Bowls since. Gibbs retired from the team. Then, over a decade later, Joe Gibbs returned to the team, determined to take them back to the Super Bowl. As part of his strategy, he hired Al Saunders as the offensive coordinator. What I found interesting was Al Saunders' offensive playbook reportedly had approximately 700 pages of various plays. Seriously!? 700 pages! Why would you think detailing play scenarios ad nauseum in a 700 page playbook would give you better results than having the team follow a few basic rules and then empowering them to make decisions on the field?
PMI PMBOK
The PMI Project Management Body of Knowledge (PMBOK® Guide) Fourth Edition has 506 pages. Some look at it like a cryptic instructional manual to all thing project management. Some merely look at it as something to reference from time to time, when someone asks "well, what does the PMBOK say?" And some look at it as the obstacle between them and obtaining the PMP credential.
Now, I don't think for a minute, if you try to follow the PMBOK to the letter, you are guaranteeing project success. That may be the reason you see "Expert Judgment" listed so many times in the inputs-outputs.
Agile Manifesto
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity--the art of maximizing the amount of work not done--is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.