Definition of AGILE
1. marked by ready ability to move with quick easy grace
2. having a quick resourceful and adaptable character
The Importance of Planning
It’s amazing how long the term “Garbage in, Garbage out” has been around, yet with the advent of the term agile teams (and typically developers) tend to embrace agile as a means of avoiding planning and detailed design. Equally harmful can be the outright of rejection of implementing “agile” methods on the basis of believing that “agile” means “unending, undefinable costs.” When done with best practices in mind, neither of these extremes should hold true.
The quality of one’s estimation will naturally correlate with ...view middle of the document...
“Agile” at its simplest facet merely allows for the inevitable changes that will come once more is learned by developers and customers through the building of the project. “Agile” deals with the shortcomings of old waterfall methodologies, but it does not eliminate any of the required steps to do a project well.
Iteration – Not Elimination of Steps
“Agile” merely shifts the planning, designing, developing, testing, and refactoring steps into a process more tolerant of change and ambiguity than that of more rigid methodologies. So how then should teams approach these steps? Can an “agile” project be estimated for time and cost, when the complexity of the project isn’t known? The answer to this latter question is a qualified yes. The qualification comes as a result of needing to understand how to track the ambiguities and unpredictability of planning, with the metrics and analytics of reality, and measuring the degree of uncertainty.
Lessons Learned/Tips for Planning
• A major tenant of “agile” is getting something in front of the end-user as soon as possible. That something should have some valuable features but it does not have to have all the features at that time.
• The “agile” process works best and development is more successful if team members are collocated with the customer.
• Timeframe questions are difficult to answer in the “agile” process. An example is as follows: “When will feature X be implemented?” A possible response maybe “I don't know it's not on the current or next sprint plan, if you want feature X before feature Y we will replace feature Y with feature X in the next sprint.”
• As requirements change the “agile” process is easy to adjust.
• Story points often confuse some performers. They say it makes all of their future estimates meaningless. For example, they used to be able to say, “I think that feature X will take 3 days to code, 1 day to test, 1 day to deploy and integrate, and 1 day to fix integration issues.” Now their estimates are relative to a story point scale that is challenging to maintain.
• “Sprint” and Scrum do not scale to large teams, instead limit team sizes to around 10 and have more teams running. If you have larger teams with 50 people, your Scrum goes from 30 minutes to 1:30 minutes, your sprint review takes a day, your sprint planning takes a day, and half of the people could be under tasked.
• For “agile” projects, returns on investment of time spent with up-front planning and design diminish in proportion with the amount of risk of change. That is, the more likely a given feature or requirement is to change, the less time one should spend on detailed design.
• The nature of the SSC PAC C2PRC project, with a live prototype out at several Fleet sites, dictates that we have the ability to reprioritize...