Common Misconceptions about Agile

Summary: Most software companies claim to have implemented agile methodologies. However, there are some common pitfalls and myths about agile. Many Software development teams think they are agile. They would have been working in small iterations and would have ranked a backlog with product teams to build a workable solution at end of the iteration. Many teams believe implementing Scrum is agile or implementing Scrum Ceremonies/Agile Artifacts is being Agile

Here are some common myths about agile below which I have seen about agile.

People think Scrum is agile

People often think scrum and agile are the same thing as scrum is around continuous development, which is one of the core principle of agile. Scrum is a framework and whereas agile is a mindset. Agile software development refers to group of software development methodologies based on iterative development where requirements and solutions are progressively evolved through collaboration between self-organizing cross-functional teams. Agile development refers to any development process, which is aligned with the concepts of the Agile Manifesto. The Agile manifesto was written in 2001 by seventeen independent-minded software practinoners.

Being Agile Doesn’t Mean there is No Plan

Being agile is a goal toward every day. Too many waterfall projects failed because they did too much planning and likewise agile projects failed because they had less planning.

Yes, Agile Projects fail when they don’t plan. And yes, Agile Projects need a plan.

Now by planning, I do not mean a spreadsheet document with 500 rows with tasks and dependencies, baselines and status of each with start and end dates. Agile projects start with lesser upfront planning and we progressively plan as we uncover more information. However, we would start with ballpark solutions with plan and estimates. However, none of the plan will be a refined plan like what we would have in waterfall project. This means we stay flexible when we are confronted with challenges, and we embrace and adapt to the change and we are open to new ideas and solutions. We are flexible, but this does not mean we do not have a plan. 

Reporting Agile projects through waterfall mechanism

Agile expects senior leaders and sponsors to spend more time on the project than off it. This means to spend time in sprint planning sessions, to ensure the requirements are understood, attending them tells to ensure what is being delivered to meet expectations and regular touch base with the team to provide continuous feedback.

Do not send a Power point presentation and invite people to attend the show and tell. That just a visual way to demonstrate progress. Reporting on Agile is different from waterfall projects. Agile do report progress. Reports are more driven from the agile boards like Sprint burn down, velocity, etc. You do not baseline a project and track the schedule variance in agile. This really hits the heart of difference between agile/scrum and waterfall project management.

Scrum is less about command and control, and more about empowered teams that deliver "complete" features at the end of each and every sprint (a defined period of time). You only really plan (in detail) one sprint at a time, so there is no real need to produce an entire end-to-end project plan that is baselined and then changed (because we cannot accurately plan that far in advance). That does not mean that there is no planning in scrum, only that plans/decisions generally follow the "last responsible moment" principle of decision-making.

Baselining can be done only when all the requirements are known in detail at the beginning of a project. And from the baseline you can calculate variances.

However, in Scrum you do not start with detailed requirements in advance. Here is the relevant quote from the Scrum Guide. "A Product Backlog is never complete. The earliest development of it only lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful."

Sprint Backlog can’t change during Sprint

The common myth among is that Sprint Backlog is fixed during the sprint and changes are not allowed to the Sprint. Therefore, work cannot be added or removed from the Sprint.

So What does the Scrum Guide Say About Changes To Sprint Backlog

The Sprint backlog is a set of Product backlog items, which are pulled in by the development team in delivering a product increment and achieving the sprint goal. The Sprint backlog is a forecast by the development team about what functionality will be next increment and the work needed to deliver that the functionality, which is “Done”

The Sprint backlog makes visible all work that the development team identifies to meet the Sprint Goal. Sprint backlog is a plan with just enough detail that changes can be understood in the Daily Scrum. The Development team modifies the Sprint Backlog throughout the sprint so the sprint backlog is not fixed, so the Sprint backlog is progressively refined throughout the sprint. The emergence occurs as the development team works through the initial plan and learns about new work needed to complete the sprint goal or work.

As new work is identified this is added to the sprint backlog by the development team by working with the product owner. As work is completed, the estimated remaining work is updated. When certain elements are deemed unnecessary, this is dropped from the backlog. Only the development team can change the Sprint backlog during the sprint. The Development team might learn that a technology they may have picked is not working as expected. As issues emerge, changes to the Sprint backlog may be warranted in order to reach the Sprint goal. The Development team will then re-negotiate the Sprint backlog with the Product Owner. In short, a Sprint backlog is flexible as long as the changes do not distract from the focus on the Sprint Goal. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.

The Daily Scrum provides opportunity to the Development teams to inspect and adapt upon the progress to the Sprint Goal and adjust the Sprint Backlog when deemed necessary.

The team and/or the manager are new to Agile – they still see each requirement change as a scope creep to the current course of action.

In the end, accepting a change in the sprint is a negotiation between the Product Owner and the Development Team, with the final authority resting with the latter. Ideally, the team should come up with a consistent policy agreed by all and tacit. Regarding dealing with changes during Sprint, and a sample policy might look like this:

A Change to the story will be accepted within same sprint if

• The Change has been confirmed by the Product owner due to changed business priorities
• The Change is small upto X hrs and can be exchanged with equated portion from the Sprint backlog or low priority item dropped from the backlog

References: Scrum Guide