This morning I went to the Agile Summit at the Palo Alto Research Center. It was a five hour seminar with two keynotes and two panels that was all about agile software development. The timing was perfect because a couple days ago I spoke with the President of Rally Dev, a firm that delivers a tool to manage and facilitate agile software development. Prior to speaking with him, I knew nothing about the agile school of thought. I still have a lot to learn about this field, but in a word I would say agile development is all about iterations. The first speaker today was Ken Schwaber, the chairman of the Agile Alliance and author of popular books on this topic. His talk was by far the best. Highlights from his talk:
- The “old” method of development is called waterfall process – where does that come from? This is all about defined dependencies, timelines, works when everything is known. Aka Ford product line when first built.
- Agile development is about an empirical process – can’t depend on start and finish, count on changes, know the vision and work on it piece by piece, adapt after each step.
- There are two disciplines within Agile: SCRUM and XP
- If you develop thinking about what you’re going to develop over the next 2-4 weeks, changes in requirements and plans become much easier.
- Over 60% of what is developed is never used; hence, if you could stop after you have developed that 40%, there’s a savings!
- Offshoring is a cheap way to fail – question: why can’t you both offshore and use agile techniques?
- Agile development is not a prescriptive process, it emphasizes common sense.
- Agile is not a silver bullet; it is very hard work.
- For business managers, deploying agile means less control and hands-on micromanagement of the engineering team. Fixed prices are shunned. The upside to this is that business people can always see iterative results and can stop the project, change directions, etc. at any time.
- Product development is a big big category – of which software development and agile is just a small piece. Things like documentation, marketing requirements docs, etc are all part of product dev.
- Agile tools like Rally are not a silver bullet. People can solve process problems, processes cannot solve people problems. And software development is ultimately about people!
- Agile development involve forecasts whereas the old school of thought involved plans.
I invite thoughts and feedback and best practices; I’m still researching and learning more about this space to see if it is something my company should implement.
The name waterfall development refers to the way the process is usually drawn as a diagram, with each stage cascading downstream to the next and nothing going upstream.
In terms of using agile and offshore together the basic incompatibility stems from the amount of upfront specification and design required by two approaches. To send something offshore you need to specify your complete requirements up front in great detail.
Agile development methods acknowledge that the customer will very likely change their mind about their requirements and so specify only the requirements for the next development iteration which may be as short as two weeks.
It’s not impossible to combine the two but the constant interaction between developer and customer required by Agile methods would make it hard.
Also there are far more agile methodologies out there than just SCRUM and XP. Check the Agile Alliance web page for more information.
I would recommend investigating Feature Driven Development (FDD) to see if is appropriate for your situation. It is classed as an agile method but is regarded as being more scalable than methods such as XP and is certainly not as “extreme” as XP either (no pair programming required). It builds on industry best practices such as code and design inspections.
I personally use an approach modeled on FDD and borrow the parts of XP I like such as Test Driven Development.
http://www.featuredrivendevelopment.com