The Fall of Agile?

Switching gears a bit from the last post, I recommend you read "The Decline and Fall of Agile".

I agree it is a common misconception that Agile is easy, that Scrum will solve all your problems. That daily scrums and sprints are the path to the rapid delivery of high value software. Many people and organizations say they implement Scrum, but in reality implement "Scrum but". Unfortunately the "but" tends to be the lack of strong engineering practices and a strong Product Owner. Now there is nothing wrong (in theory) with "Scrum but", as a service company, not all of our customers will accept a Scrum methodology, or, we need to follow their development process, some of which are very heavy-weight. But, you need to strive keep the important pieces of Scrum, and the corresponding good engineering principles. While Scrum is a MANAGEMENT methodology, don't forget the engineering part.

In my opinion, the most important pieces of Scrum include:

• The daily standup
  
• Strong collaboration tools to share knowledge and keep everyone informed.
  
• Constant communication with the customer (product owner) and the team
  
• Short iterations
  
• Engaged and highly motivated teams
  
• Motivated product owner

In addition to these management principles, some of the strong development processes we use at Macadamian include:

• Peer review - all code is peer reviewed by at least one other developer. In addition, the test cases the developer used in his testing are also reviewed by a QA that is on the team.
  
• Daily builds - All builds are run daily, failures are reported to the team immediately. The person who broke the build is severely punished by having to buy donuts. 
  
• Continuous integration - Builds are run whenever a developer checks in source code, this aids greatly in the integration and helps catch build regressions.
  
• Automated tests - These tests are run as part of the continuous integration environment, and prior to any patch submission.
  
• Design review - All design is reviewed by the team prior to being implemented. It helps catch any missed requirements and shortcomings in the design. The design can be as simple as some boxes on a whiteboard, or even some interface declarations. No UML is required.
  
• "Wide and Shallow design" - Helps catch fundamental design issues before any of the actual implementation has been done. This allows a more senior developer to help “bootstrap” a project and leave it with a solid foundation for the more junior developers to fill in. Because the design is only stubbed and not cast in stone, the design can still evolve in an emergent fashion.

What do you think? Anything you would add or remove?