Many companies today are considering or using iterative methodologies like Agile and Scrum to deliver their software projects. This stemmed from challenges these businesses have faced with a waterfall delivery approach, where code is constantly in a state of flux, and development deadlines were missed routinely despite the best efforts of smart developers. Iterative methods tend to outperform traditional, or ad-hoc, methods, as you can see in the research below. Let’s take a look into why this is the case.

Why are iterative delivery methods better than traditional ones?

Changing requirements: In today’s world, the volume of data generated is constantly rising and the quest to satisfy the consumer is accelerating. Arguably, the biggest challenge a business must contend with is the rapidly changing landscape of user requirements. While traditional methods assume that requirements are mostly static, iterative methods (such as Agile) tend to assume that everything constantly changes and the business needs to build only as much as is known at the time. This approach llows for rapid adjustment to changing user needs, facilitating more customized outcomes. 

The limits of the human mind: Throughout the ages, humans have built systems, tools, and methods that allow them to accelerate their ability to create, innovate, and deliver. However, even with all the tools we create, it seems the larger problems have a higher likelihood for human error, especially when we are short on time. This problem often plays out in traditional methods where a large set of requirements and modules are built in parallel, and are expected to work well together. This challenge typically tends to be too complex to handle for even the most able developer—after all, we as humans can only comprehend so much at any one time.

Enter the iterative approach. Iterative implementation limits the amount of change in a single iteration. This reduces risk and improving outcomes, making them considerably more achievable. This reduced risk gives iterative approaches a huge advantage over ad-hoc methods.

The tendency for the human mind to over-estimate its own capability: No matter how smart we are or how good we are at what we do, we often tend to overestimate our own abilities. This is why as the time horizon draws out, we humans tend to predict faster deliveries than are actually possible. Iterative methods acknowledge this fact and adapt to this challenge by basing predictions on a run rate (known as “velocity” in Agile). This run rate is based on historical data and hence tends to be more realistic.

So now that we know why iterative methods are typically more effective, what is Agile and what is Scrum?

Agile Scrum: What is it, and why should I care?

Agile is a system of methods to deliver iteratively. Agile Scrum adds a few rules to the structure to make processes more collaborative and team driven. Below is a high-level overview of Agile structural elements:

1. A sprint (iteration) that typically runs between one and three weeks, delivering a releasable bit of the product that may consist of bug fixes, new features, UI improvements, or some combination of these and other projects.

• Each sprint has a sprint planning session, where the team commits to the user stories, or subprojects, they can complete during that sprint and break the stories down into tasks.
• Short daily huddles known as the “daily scrum” or “daily standup” where the team provides brief status reports to determine where it is and what can be accomplished that day.
• A retrospective at the end of the sprint that enables the team to determine where they can improve and how they can build more velocity going forward.
• A demo that allows the team to showcase its delivery to stakeholders or users.

2. A release which includes a definitive set of features/stories that will be released over time. A release is usually a predetermined number of sprints. Typically, a team doesn't perform a release planning activity until it has demonstrated a sustained velocity that allows for effective planning.

3. Roles

• A Product Owner who owns the entire list, or backlog, of stories, prioritizes them, and makes sure the customer/stakeholder input is incorporated.
• A Scrum Master (project manager) who facilitates and guides the team towards success on a day-to-day basis.
• The team that is delivering the product. 

While the description above is not comprehensive (you can learn more here), there is also a change in mindset when embarking on the Agile journey. From my own experience, here are some aspects to consider that are usually quite useful in attaining better velocity and predictable delivery from your sprints. I recommend reading the article “A brief introduction to Scrum” linked above if you can; it is the basis for these thoughts.

1. Think continuous integration. Without automated tools to build, test, and release, your velocity will be limited to the speed of humans. Automation can greatly accelerate your delivery; update your tools alongside your features at all times.
2. Think minimal documentation and written content. Yes, documentation is required; however, every bit of documentation should have purpose: improving the team’s capability/velocity.
   • API documents are useful for the team, enabling them to rapidly distribute work without excessive handholding.
   • A 20-page requirements document is not as useful as a product owner sitting with the team and working through the requirements in person. In past implementations, I have asked my team not to bother documenting the issues found within a sprint since they need to be collaboratively fixed immediately.
   • Take shortcuts...that’s what Agile allows you to do. But do not take shortcuts that land you in trouble down the road! Basic discipline is still a pre-requisite to building good products.
3. Accept and celebrate change. Agile mastery requires complete acceptance to change and an ability to adapt quickly. Guess what? If your requirements and business expect your code to change all the time, you are in a state of flux with lots of unknowns. But this is good news, since the unknown can drive the greatest growth machines.
4. Commitment. No Agile team ever delivered well without committing to the outcome of the sprint and going after it. Over time, long hours will subside and predictability will increase as you begin settling into a good, repeatable velocity and are also able to size your stories consistently.
5. Generalized capability within Scrum teams: Teams with a generalized capability tend to accept more stories and deliver more velocity over time since their backlog will almost never be low. While it is acceptable for an individual developer to have a specialization, it is recommended to build teams where any member could take on all stories in the backlog. This will require cross-training and learning and a focus on enabling and empowering each individual on the team to take on any task.

All this sounds great, right? But now you’re probably wondering…

How do I get started with Agile Scrum? How do I get good at it?

If I’ve convinced you so far that Agile can help you and your organization, then the next question becomes where do I get started, and how long does it take to get good at this?

Based on my experience, the steps to full adoption of an Agile structure across the organization are described below. There are other models (Dr. Dobbs’ model, for example) that discuss these stages, but their essence is the same. Bear in mind that much like the iterative approach to Agile, these phases tend to overlap and are not quite as separate as listed below.

1. Stage 1 – Informing: I would strongly advise you to take a formal course or a certification (CSM, for example) that thoroughly covers the basics. This phase typically lasts anywhere from a day to a week.
2. Stage 2 – Adopting: Apply Agile Scrum to at least one project at work. Early on, there will be a number of challenges. Some of them are documented here. Keep the process moving and be brutal and realistic during your retrospectives about what should change. Being results oriented and honest with yourself in these discussions is the only way to improve. Trust me, it’s worth it when you are done with the early phase—even though in the short term you might see productivity plummet within your project. I would also invest in a tool that makes coordinating the backlog and the sprints easy. This phase typically takes a month or two, assuming you are doing two-week sprints.
3. Stage 3 – Scaling: Expand what you’ve learned to multiple projects: Once you’ve delivered a few sprints with predictable velocity, then you are ready to take your experience and apply it across more projects. Do so cautiously, though, since stretching too far could dilute your ability to improve. That said, having multiple projects running in parallel allows you to learn the most in the shortest time. This is why I recommend scaling quickly. This phase tends to be a two- to four-month investment.
4. Stage 4 – Optimizing: Improve the efficiency and ability of the teams through automation, tooling, organizational changes, and any other means necessary. These should flow naturally from the retrospectives and is the most important step towards gaining velocity. Invest in CI/CD tools and automation—and make sure the key metrics you care about are automated. If you pepper this work into the previous stages, you won’t have a lot to do here. However, if you want to take it slowly, this step can take anywhere from a few weeks to a couple of months, depending on the maturity of the code environment.

At this point, you should have achieved a delivery methodology that allows daily delivery of useful features (if necessary), automated key metrics, and a team that gets the daily dynamics well. Congratulations! You have come farther than most teams ever will. 

You can accelerate the above phases by taking Simplilearn’s Agile and Scrum courses. The course work has live projects that help you assimilate and execute these concepts much faster and may enable you to compress the above steps.

Ok...That’s great, too...but…

What outcomes should you expect?

Having been an Agile practitioner for more than 10 years now, and having implemented this methodology across more than 20 teams in development, content, marketing, and many other diverse delivery teams, my learnings have been distilled down to these takeaways:

• Infinitely higher morale in the team. I mean seriously! The teams will really enjoy the collaboration and the sense of ownership once you go down this path. Yes, there will be naysayers, but this is natural with any change.
• I have found that post-release issues dropped close to 30% for us. With a more mature team, you could expect 50% reduction or more in post-production issues. Most issues are found in a sprint and fixed before release. Couple this with the fact that you are only releasing incremental capability (lowering risk) and you get a much better quality delivery.
• The velocity of the team tends to increase 30 – 60% once you get to scaling and automating your Agile delivery. This is mainly due to the ruthless focus on improvement every sprint and the added automation that you will attune to naturally as a result of the daily cadence.
• The ability to predict outcomes based on release planning is much better compared to the traditional project plan. I have seen that accuracy is about 30 – 50% higher in my past projects. This is a large delta in bigger projects. 

The most important part of this journey is that you are now building an adaptable organization and a team that can swivel quickly. This is a competitive advantage in an increasingly tough marketplace.

Further reading:

Essential Scrum: A Practical Guide to the Most Popular Agile Process, Kenneth S. Rubin                                                       Learning Agile: Understanding Scrum, XP, Lean, and Kanban, Andrew Stellman & Jennifer Greene