Wednesday, March 25, 2009

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?

1 comment:

Alex said...

Here are the practices which currently define “being Agile” for our CTO, Damon Poole from AccuRev. These are roughly in order of benefit: short iterations (preferably 1-2 weeks), Kanban (as an alternative to short iterations), backlog, one piece flow, continuous integration, whole teams, collocated whole teams, test first/test early, use of a product owner, incremental design, refactoring, unit tests, multi-stage continuous integration, user stories, sustainable pace, task assignment and estimation by team members, stand-up meetings, burn-down and burn-up charts, iteration review, retrospective, and frequent releases. There are other good practices out there, but these are the ones that Damon believes will become mainstream.

Forrester recently interviewed AccuRev to learn ways in which we and our customers ensure successful Agile adoption and implementation. The report was published today:

March 24, 2009
Ensure Success For Agile Using Four Simple Steps
A Simple Approach To Agile Adoption And Implementation
by Dave West
with Mike Gilpin and David D’Silva

In short, they recommend:

Step One: Pick The Right Projects And Deliver Results Early
Step Two: Keep Momentum Going
Step Three: Make Organizational Change, Not Agile Development, The Main Focus
Step Four: Make The Business Part Of The Solution

You'll need access to the full report for the details.

I see too many companies succeeding on the hard stuff and failing miserably by not focusing on the basics causing too much manual and wasted effort. It's when they get the basic software development functions (version control, change management, build and continuous integration) taken care of that they begin to benefit from the more high level Agile practices.

Great read. Thank you.
Twitter: AccuRevComm