Introduction

What is Agile? The definition of Agile varies depending on the perspective of a person. For example, some may say Agile is a mindset, a framework that allows rapid change, or that Agile is a methodology that enables incremental changes to a software application. All answers are correct, but the biggest question comes when we implement Agile methodology. This article will discuss some real-time experiences of applying the Agile framework in SDLC. In addition, we will be discussing some specific adaptations we used to find success. Please note that this article is not a Scrum guide. To fully understand how to implement the Scrum framework refer to The Scrum Guide.

History

In 2001, seventeen software developers from around the globe met and spent a few days discussing this new methodology. The outcome of that meeting was the Agile manifesto and 12 Principles. They established the following value points:

1. Individuals and interactions over processes and tools.
2. Working software over comprehensive documentation.
3. Customer collaboration over contract negotiation.
4. Responding to change over following a plan.

From getting the base of Agile development concepts written down, the 17 members (individually) started building different flavors of Agile. This process brought new Agile frameworks into existence. Some famous names of Agile flavors are:

1. Extreme Programming (XP)
2. Feature-driven development (FDD)
3. Lean software development
4. Kanban
5. Scrum
6. Scaled Agile

Out of all, the most popular flavor is Scrum founded by Ken Schwaber and Jeff Sutherland. They have defined the complete Scrum framework in their book, "The Scrum guide". The Agile manifesto, 12 principles, and three pillars of Agile build the foundation for Scrum Framework. The three pillars of Agile are transparency, inspection, and adaptation. The Scrum guide defines everything, including how to run a project using the Scrum methodology. However, it only covers textbook scenarios for implementation. It does not cover strategies for the following challenging questions:

1. When the textbook implementation of Agile methodology fails?
2. When Agile methodology does not fit properly within an organization?
3. What if the stakeholder engagement becomes a concern?
4. How to adapt for growing team size?

Any Agile training sessions or guides do not discuss these difficult questions. Over the last six years, we have gained an in-depth understanding of applying Agile Scrum methodology in different and challenging circumstances.

Agile vs. Waterfall

To better understand the Agile methodology and its concepts, it is crucial to understand the Waterfall methodology. Waterfall is another famous Software Development Life Cycle (SDLC) methodology. This methodology is a strict and linear approach to software development. It aims at a significant project outcome. On the other hand, Agile methodology is an iterative method that delivers results in short intervals. Agile relies on integrating a feedback loop to drive the next iteration of work. The diagram below describes other significant differences between these methodologies. In Waterfall, we define and fix the scope and estimate the resources and time to complete the task. In Agile, the time and resources are fixed (called an "iteration"), and the work is estimated for every iteration. Agile helps estimate and evaluate the work that brings value to the product and the stakeholders.

It is always a topic of debate as to which methodology to use for a project. Some projects are better managed with Waterfall, while others are an excellent fit for Agile. Leaders of the organization or Project managers should understand these methodologies to make the best decision. This understanding at the leadership level will bring out the most remarkable project success.

The Evolution of Our Agile Approach

Here is a bit about our journey.

Getting Started with Agile

After learning about Agile in 2016, I introduced the Agile framework to our team. Since then, we have never looked back. I am a CSM, A-CSPO, SAFe (5.0) Agilist with a DevOps Foundation certification. These certifications are a good starting point for understanding Agile methods. They will set you on a right path to become more versatile with Agile techniques. But only practice can make you better at implementing Agile methodology.

The Organization

The organization we will discuss in this article is a state government agency in the Healthcare domain. Unfortunately, State agencies are still behind on the understanding and application of Agile concepts. Typically, they follow a traditional Waterfall methodology to achieve project success. The leadership relies on old and proven concepts, and making any changes is faced with some resistance. Implementing an IT project in a state agency is no different than in a private organization. For example, business requirements are constantly changing; therefore, working on a project with extended timelines (think 9-15 months) becomes very difficult to manage using the Waterfall methodology. Hence, there is a need for Agile.

About the Team

At this organization, there is a large IT development team made up of about 60-plus individuals. In 2016, the team size was about 18, working with the Waterfall methodology and transitioning to Agile in late 2016. Currently, this is a cohesive cross-functional team. The team includes developers, architects, database administrators, business analysts, Scrum masters, product owners, business intelligence analysts, designers, DevOps engineers, testers, and quality assurance analysts. They work together by applying Agile principles.

Our Agile Journey

In the beginning, we started doing everything by the book, following the Scrum precisely as described in the Scrum guide and training webinars. It was exciting for everyone, and the team was on board with the new working method. However, challenges started appearing as we went through a few sprints. We began to see disinterest and resistance from the team. Long scrum ceremonies would include discussing the work in full detail, documenting the requirements, identifying effort points, and earning everyone's consensus took anywhere from 3-5 hours. These Scrum ceremonies were overwhelming. These meetings were eventually getting tiresome, and attendance was reducing. Due to several reasons, our approach has evolved over the years. We have adjusted the Scrum practice as per our team's needs. Our leading precedent value became - “Working software over comprehensive documentation.”

Adjustments to the Scrum Process

As our team grew, we also had to scale the practice and found success with these new methods:

1. Divided the groups per the dedicated assigned projects.
2. Each team has dedicated leadership resources: product owner, Scrum master, technical lead, and development team.
3. Each team works on its own and holds its scrum ceremonies.
4. The team size is limited to 7-9 individuals.
5. Limited meeting times so that no Scrum ceremony is more than 2 hours in length.
6. All requirements are detailed before the Scrum planning meetings.
7. Discontinuing the backlog refinement sessions.
8. The technical leads were made mandatory in all sessions with stakeholders.
9. Decentralizing the decision making power.
10. The Scrum team understands the vision and mission of the organization.

With these practical adjustments, our team was cruising through the process of Agile, following the 12 principles and enjoying the benefits. However, the project management office (PMO) wanted more accountability and documentation. To counter this situation, we spent more time coaching the PMO team. We are creating awareness about Agile concepts within the organization and how to proceed forward. The process everyone agreed upon is depicted in the diagram below:

Application of Agile Principles and Values

The founders of Agile gave us 12 principles and four values in the manifesto, some of which have been more important to our team than others. However, as we applied Agile, our results showed which principles and values benefited us to drive success. Our team has used the four values and effectively utilized the principles. The following section explains it in more detail.

1. Individuals and interactions over processes and tools – Our team is not reliant on any tools for interacting within the team. All team members are readily available to other team members. Decentralized decision making helps the free flow of the development work. Instead, the information travels directly from the decision-maker to the team member working on an idea.
2. Working software over comprehensive documentation – We require minimal documentation so that it does not delay the development process. Although we do not neglect documentation, the focus is always on working software as the deliverable. So having working software instead of wasting time on comprehensive documentation is one of the essential values we have implemented.
3. Customer collaboration over contract negotiation – All Scrum teams are highly involved and collaborate effectively with the stakeholders. All work performed by the scrum team has high visibility, and the team is open to any ideas brought up by the stakeholders.
4. Responding to change over following a plan – Our team embraces change and takes a collaborative approach with stakeholders. We look for every opportunity for feedback, and development work is changed accordingly. If you properly implement the first three values, this value will automatically fall into place.

Below are the seven principles which the team has mastered:

1. Focus on customer satisfaction
2. Embrace changes
3. Deliver work frequently
4. Work as a team
5. Practice simplicity
6. Maintain self-organization
7. Focus on working product

 Measuring Success

The ability to measure success is a significant factor in the organization. Being successful helps motivate the team for future projects. There are several industry standard ways to measure success. Measuring success depends on the type of industry and the leadership needs. It is essential to understand that neither methodology (Waterfall or Agile) guarantees a successful project. A project's success always depends on the working team and the leadership. Below are some standard ways to measure success:

1. Scope completion within the time
2. Customer satisfaction
3. Project completed within the allotted budget
4. Desired project quality achieved

Within our organization, we measure success using customer satisfaction. Measuring success in a non-profit government organization while following Agile methodology can be challenging. For our team, we measure success by following parameters:

1. Customer/Stakeholder satisfaction
2. Scrum team experience/satisfaction
3. Continuous open communication within the team and with stakeholders
4. Achieving committed milestones with a margin of 8-10 %

Conclusion

Today, our team comprises over 60 individuals, including 6 Scrum teams. We still encounter daily challenges in practicing Agile methodology. We are still evolving and adjusting the process to bring the highest level of success for all. What always remains consistent is the fundamentals (Agile values and principles). Different teams may adapt the Scrum process differently as per their individual needs, requirements, organizational structure, policies, and culture. But the bottom line is that having the Agile manifesto embedded within your working culture can drive success and bring value to your project.

Statistically, Agile projects have shown higher success rates by delivering business value early in the process, making it easier to lower risks associated with development. Some of the benefits of Agile projects are:

1. Higher quality products
2. Raised customer satisfaction
3. Increased project control 
4. Reduced risks due to changing external dependencies, and
5. Faster ROI.

However, agile methodology is not always the best fit for every organization or project. Therefore, organizations should consider the pros and cons and identify the best approach for their project.

"Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning." – Albert Einstein.