Success Factors for Iterative Development
June 9, 2006 4:57 AM Subscribe
What are the success factors in implementing an iterative software development process?
What are some of the key ingredients that make an iterative development process successful? What are the corporate culture factors that enable/restrain iterative development? Are there certain team dynamics required for success? Are there signs during the process that predict success or failure? What are the distinguishing characteristics of iterative and agile development? Or are they synonymous?
What are some of the key ingredients that make an iterative development process successful? What are the corporate culture factors that enable/restrain iterative development? Are there certain team dynamics required for success? Are there signs during the process that predict success or failure? What are the distinguishing characteristics of iterative and agile development? Or are they synonymous?
A good project manager is, IMO, the single biggest factor in whether a project will succeed or fail.
If he's good, it doesn't matter which process he uses. But without him, no process in the world can save you.
This answer is probably antithetical to your question, which is about agile and iterative, which de-emphasize management and process, but that's my experience.
I suppose an experienced, committed team could PM itself in theory, but I've never worked in one that could.
posted by Leon at 5:44 AM on June 9, 2006
If he's good, it doesn't matter which process he uses. But without him, no process in the world can save you.
This answer is probably antithetical to your question, which is about agile and iterative, which de-emphasize management and process, but that's my experience.
I suppose an experienced, committed team could PM itself in theory, but I've never worked in one that could.
posted by Leon at 5:44 AM on June 9, 2006
I've been in several software projects in relation to my study. So I'm speaking from a 'team of students with lots of conflicting schedules and courses' point-of-view.
Iterative development probably means short periods and fast deadlines. A PM (and a team) that keeps a very close eye on these deadlines is a must. In order to do this, the team must be 'close', and communicate often. This was one of the most difficult thing to do in student teams, where everyone has his own courses to follow besides the project.
posted by Harry at 6:17 AM on June 9, 2006
Iterative development probably means short periods and fast deadlines. A PM (and a team) that keeps a very close eye on these deadlines is a must. In order to do this, the team must be 'close', and communicate often. This was one of the most difficult thing to do in student teams, where everyone has his own courses to follow besides the project.
posted by Harry at 6:17 AM on June 9, 2006
Best answer: Ah, agile development. There's lots of talk, websites (more), interviews and books (more). Key ingredients would seem to be:
posted by xpermanentx at 6:57 AM on June 9, 2006 [4 favorites]
- short feedback loops with customers
- constant communication between team members
- small teams
- well-rounded developers over narrow-sighted specialists
- source-code control that is not dependent upon location
- developers squirrelling away on code and not talking to other team members
- iteration cycles that are too long and miss what the customer wants
- coporate structure that praises documentation, ass-covering and ticking boxes rather than working software
- risk aversion, avoidance of new and unfamiliar technologies and methodologies
- break down in communication between team members
- lack of testing, developers not interested in or committed to testing
- lack of communication/input from client
- failure to deliver working iterations/prototypes
- difficulty adapting process or prototypes to changing circumstances/requirements
posted by xpermanentx at 6:57 AM on June 9, 2006 [4 favorites]
A couple of comments from the PM side:
Agile is a development methodology, not a requirements methodology. Clear requirements are still a must and if your shop is still using, for example, use cases and wishes to move to stories as a development tool (a COTS shop will need use cases or whatever for internal groups), I would advocate building the stories from the UCs. (Likewise, stories are not requirements.)
Siloed departments/fiefdoms make this extraordinarily difficult to implement and, frankly, some teams are more suited for working agile than others.
Finally, all iterative development is not agile development and I've seen some very successful iterative-but-not-agile projects.
posted by wildeepdotorg at 7:52 AM on June 9, 2006
Agile is a development methodology, not a requirements methodology. Clear requirements are still a must and if your shop is still using, for example, use cases and wishes to move to stories as a development tool (a COTS shop will need use cases or whatever for internal groups), I would advocate building the stories from the UCs. (Likewise, stories are not requirements.)
Siloed departments/fiefdoms make this extraordinarily difficult to implement and, frankly, some teams are more suited for working agile than others.
Finally, all iterative development is not agile development and I've seen some very successful iterative-but-not-agile projects.
posted by wildeepdotorg at 7:52 AM on June 9, 2006
Agile development is iterative development taken to a micro-management level. The iterations are deliberately tiny, so that planning, creating, and knowledge of success or failure, is known at a very early stage of each iteration. This allows early replanning or abandonment without significant loss of resources.
For both, you're going to need an environment of 'Continuous Integration'. This means that all developers are checking in early and often. Each checkin is included in a build, if not immediately, then at most within an hour. A build is not considered complete until it has been fully unit tested. The implication of Continuous Integration is that the iterative development steps are so small that, even though frequent check ins are the norm, they should not break the build. There is often a token penalty for any 'build breakers'.
Also note that unit tests aren't considered a 'nice to have', they are a fundamental part of this approach to development. In true agile development, a full unit test suite is always created for a component before work starts on the component itself. The unit test is, effectively, the contract that the component's interface must adhere to. For each build, all unit tests are run against all of the system's components. A report is usually generated giving details of the test failures and successes. All members of the team will have access to the reports.
It's important to distinguish between a broken build and a failed unit test. Broken builds are bad, failed unit tests not so bad. The first build after initial check in of a new component of a system, all unit tests should fail. Basically, the initial checkin, will be a skeleton unit test suite, and a skeleton component. No functional code will exist at this point. Subsequent check ins will be made as the each individual test in the suite is fleshed out. When all tests are complete, all of the tests will fail. Subsequent check ins, where the component's functionality is fleshed out, will result in fewer and fewer failed unit tests. Eventually all tests succeed. At this point, the component is considered to functionally complete. That is, it strictly adheres to the unit test contract.
posted by veedubya at 8:53 AM on June 9, 2006
For both, you're going to need an environment of 'Continuous Integration'. This means that all developers are checking in early and often. Each checkin is included in a build, if not immediately, then at most within an hour. A build is not considered complete until it has been fully unit tested. The implication of Continuous Integration is that the iterative development steps are so small that, even though frequent check ins are the norm, they should not break the build. There is often a token penalty for any 'build breakers'.
Also note that unit tests aren't considered a 'nice to have', they are a fundamental part of this approach to development. In true agile development, a full unit test suite is always created for a component before work starts on the component itself. The unit test is, effectively, the contract that the component's interface must adhere to. For each build, all unit tests are run against all of the system's components. A report is usually generated giving details of the test failures and successes. All members of the team will have access to the reports.
It's important to distinguish between a broken build and a failed unit test. Broken builds are bad, failed unit tests not so bad. The first build after initial check in of a new component of a system, all unit tests should fail. Basically, the initial checkin, will be a skeleton unit test suite, and a skeleton component. No functional code will exist at this point. Subsequent check ins will be made as the each individual test in the suite is fleshed out. When all tests are complete, all of the tests will fail. Subsequent check ins, where the component's functionality is fleshed out, will result in fewer and fewer failed unit tests. Eventually all tests succeed. At this point, the component is considered to functionally complete. That is, it strictly adheres to the unit test contract.
posted by veedubya at 8:53 AM on June 9, 2006
Response by poster: Although I marked xpermanentx as best, I appreciate each and every answer. Good stuff guys! Thanks!
posted by sexymofo at 12:46 PM on June 9, 2006
posted by sexymofo at 12:46 PM on June 9, 2006
This thread is closed to new comments.
You need a mature professional team. The simple nature of iterative development means that you will potentially toss out work because it's not actually appropriate once you've finished it. Some people find that extremely difficult to do even though it's the appropriate decision.
Other elements to focus on are people's ability to develop without a grandiose plan. You have your end goal and framework, but it's a looser development process, which once again makes technologists uncomfortable in some cases.
I'll think about this some more and see if I can elucidate more eloquently as I still haven't had my coffee..
posted by Lord_Pall at 5:21 AM on June 9, 2006