Apart from the fact that most software companies claim to implement agile methodologies, there are still common misconceptions and myths about Agile that are necessary to debunk, now and forever.
This would not only help the ones already implementing agile to avoid common pitfalls, but it will make companies understand agile more, realize its benefits, and embrace the change and ultimately improving prototyping process. You can even plan to take agile training to learn more from various agile certification bodies to follow the principles of Agile manifesto in the best way.
As in traditional development methodologies like Waterfall, when projects are scope boxed, given the list of requirements along with their estimates, the schedule and budgets are derived from these estimates completely.
Since the waterfall model focus end to end development and delivery, estimation is provided without going much into details, those estimates are provided the beginning of each phase. So the risk is, if that estimatoin are wrong, which is normally the case, normally iteration cycle is really long. Since estimations cannot be totally accurate, if end middle of each iteration something needs to be re-do or extend the scope it takes longer to re-focus and re-estimate, which makes the projects delay longer then if Agile methodolgies was used. Its easier to do detail planning for next few weeks then for few years. That’s the main difference between Agile and Waterfall when coming to estimation.
Scrum and Extreme Programming are Agile methodologies that use the time-boxing concept, as by doing this delays can be optimized, planning can be detailed, since focus is very short, we tend to see things more closely and do it better, even if we fail to do it completely, whatever we do is still aligned with the goal.
This leads to the fact that estimates are worthy of not only for the task turn around time but also provide overall completion of goal by looking at a smaller piece of timeboxes.
Other benefits which estimates provide, is that teams work for a predefined fixed period( between one to four weeks), getting maximum done in that period as they can.
The teams can use estimations to calculate how many sprints are needed to develop all the requirements, but each sprint has a fixed cost. This eases the process of budgeting.
Agile team after few sprints can utilize the average team velocity, to have visibility about future regarding the larger releases or deliverables, which gives a powerful tool for product owner to have some estimates about how long it takes to deliver a feature/product, what will be the cost/budget based on the number of sprints needed to complete a feature/product.
Fixed big project is where product/service need to be delivered on agreed cost or budget.
Agile fit well with this kind of projects, because of agile methodologies characteristic of having the short and quick feedback loop with the customer, since cost is fixed, so we need to make sure that what every scrum team is working on is still within the agreed scope. Regular sprint demo, close cooperation of product owner with customer, help to narrow the gap which enables the team to focus completely on product.
In agile project if it is fixed term nature, the responsibility of product owner is even more challenging, because (s)he needs to ensure the requirements are prioritized correctly in order and scope don’t change.
One of the popular myths is agile teams do not commit as there are generally 6 to 8 developers working until someone confirms “he or she is done!” In contrast to it, successful agile teams are transparent and realistic when it comes to their promises.
XP and Scrum have a sprint backlog concept that includes the list of items that will be developed during a sprint. Though the newest version of Scrum backs off on the strength of commitment, usually, for some scrum teams, the sprint backlog items are treated as a contract- the team will deliver all the items that it committed in that sprint only.
However, XP permits the change if the team collectively agrees and the item to be replaced is not being started yet. In scrum and XP, deferment (not completing an item that was promised) is not treated lightly and is taken as an exceptional occurrence. This regular cadence and commitment to delivering software in small increments develop trust among the team members and other involved parties, like users, customers, and stakeholders. Teams that follow the latest teachings on scrum do not promise on the sprint’s scope. This eliminates the idea of scope-boxing as it is a dangerous game to play.
Scrum team should focus on rapid feedback loops, collaboration, and constant communication and transparency to implement agile successfully. Usually, when teams are communicative, the demand for an ironclad commitment becomes less. The resulted trust and collaboration from the teams override the outdated necessity for commitments. As compared to Waterfall projects that are based on estimates and teams did not deliver what they promised.
Scrum does not use business analyst term and instead refers to the product owner. This leads to a single point of contact for the team when they have questions regarding anything. This does not mean Business Analysts are not included in agile projects. In contrast, the domain specific knowledge that business analysts have is an essential asset to the product owner. These experts help compose the backlog items and assist in concluding priority and order.
XP does not enroll a single role like Scrum’s product owner but takes business analysts and customers as a collaborative team that decides the priority and order of the backlog items. Teams can be divided into feature teams when agile projects scale. These teams will still be dependent on the users, business analysts, and customers to craft a backlog for each of these features and the complete backlog of the project.