In my previous article, "Talking About Modern Development Methodologies," I briefly introduced various frameworks. In this article, I will share my personal experience of adopting Agile within my team—a journey that led us to our current Scrum process and our future plans to transition to SAFe.
I am someone who had the opportunity to try and implement Agile in a traditionally Waterfall organization. It has been over 4 years since my first day here, and it took that long for our processes to take shape and evolve into the Scrum we use today.
Personally, I believe that the most critical factor in successfully implementing new processes or improving an organization is the Executive Management, followed by Department Heads and Team Leads.
Why is Executive Support Crucial?
Changing organizational processes requires strong backing from leaders who genuinely understand the value of these changes. If an executive tells you to "use Agile" but still clings to the traditional mindset—demanding upfront requirements, strictly divided phases, rigid scopes, and forced timelines—I can tell you right now: Don't use Agile. You are better off sticking to your traditional methods and simply finding better tools or specific practices to help you out.
To work in an Agile way, everyone must understand that software constantly changes based on new trends and technologies. Furthermore, the software developed must be of high quality. This means that productivity might drop initially, but the overall time spent will decrease. Higher quality means fewer bugs to fix later, and any fixes that do arise will be minimal.
Following the executives, Department Heads and Team Leads must also understand and value Agile. They are the ones who must guide the team, support them, and transfer this knowledge throughout the organization.
Year 1: Project 1 (The Initial Struggle)
In my first year, I introduced Scrum. Why Scrum? Because it has clear processes and step-by-step guidelines on what needs to be done. At the time, I had a decent understanding of it from personal study and various training sessions. When the opportunity arose, I jumped on it.
The first project had a team of 5: 1 Team Lead, 3 Devs, and 1 Tester. I acted as the Lead Dev (not quite the Team Lead, as the actual lead was rarely around due to other commitments).
-
The Setup: No Product Owner, no Scrum Master.
-
The Reality: We tried doing Sprint Planning, Sprint Review, and Sprint Retrospective. It didn't align with true Scrum at all (laughs). I tried following the proper Scrum process, but after a few days or weeks, we had to drop it due to ad-hoc tasks, tight deadlines, and internal team issues.
-
The Tools: We still used a physical Scrum Board + Trello. (Process shown in Image 1)
The project took about 3–4 months and we barely scraped by. The Takeaway: Mixing Waterfall with Scrum rarely survives. We had to rush to meet fixed deadlines, on top of dealing with Regression Tests, Releases, and Deployments. It was incredibly exhausting, to the point where I thought Scrum might not be a good fit.
Year 1: Project 2 (The Agile Mishmash)
Later that same year, I stubbornly tried Scrum again on a second project, but severely cut down the processes. We used a Physical Board + Trello. Overall, it wouldn't be accurate to call it Scrum; it was more like pulling in various Agile practices:
-
User Stories & Gherkin Language
-
Test-Driven Development (TDD) & Automated Testing
-
Pair Programming
-
Iterations
The team consisted of 1 Team Lead, 5 Devs, and 1 Tester. (Once again, I was Lead Dev with similar pseudo-lead duties). This project lasted about 1 year, but things fell apart for several reasons:
-
User Stories & Gherkin: The team was new to this. Without clear Acceptance Criteria, detailed UI mockups, or widespread knowledge of Gherkin (only I knew it, and the tester wasn't proficient), it was too difficult to execute.
-
TDD & Automation: The timeline was heavily squeezed. We constantly had to build Proof of Concepts (PoCs) and lacked the time to develop the actual product properly. With sudden ad-hoc tasks popping up weekly, TDD and Automation were abandoned.
-
Pair Programming: The Team Lead believed "two heads are better than one" for research. However, we paired two Junior developers together, which only made them more stuck.
-
Iterations: We delivered work in cycles, but testing was inconsistent.
The Takeaway: This project was quite a mess. I believe the root cause was that the Team Lead/Department Head didn't truly understand Agile. There was no proper work control, and the focus was too heavy on sales. It was like building a house with a beautiful design but weak pillars and cheap materials. It leaned much more toward Kanban than Scrum. (Process shown in Image 2)
Years 3 & 4: Project 3 (Finding Our Footing)
For the third project (which consisted of 2 systems), the executives explicitly wanted a clear Agile approach. We laid out the processes and chose Scrum again.
The initial team was 9 Devs and 1 Tester. This time, I took on the roles of Scrum Master, Product Owner, and Team Lead. While the beginning was rocky, we successfully maintained the Scrum process:
-
Zero Interruptions: Ad-hoc tasks were minimal, allowing key personnel to stay with the team and follow the process.
-
Estimation Adjustment: We started with Story Points but soon realized it didn't fit the team, so we switched to Functional Points, which vastly improved our estimations.
-
DevOps & CI/CD: We introduced CI/CD, which reduced deployment time and helped us catch errors immediately.
-
TDD & Automated Tests: We began taking TDD seriously. The impact on related features was clear: bugs dropped significantly, and rework was minimized.
-
Acceptance Criteria: We added clear criteria and embedded test cases within them. Developers knew exactly what to test before handing work over, resulting in a noticeable drop in bugs. We are now formatting these into Gherkin.
-
Code Reviews: Introduced to help mentor Junior developers.
-
Daily Meetings: We adapted by integrating Slack, which improved workflow and transparency.
The Takeaway: This project proved that executive support is paramount, and Department Heads must actively back what the team is trying to achieve.
The Present and the Future
Today, we have a team of nearly 30 people. Our workflows are vastly improved, product quality has increased, and we deliver on time (or faster) with much less rework. While we still have some minor issues with documentation and a few other areas, we are in a great place.
Our next major step is to adopt SAFe (Scaled Agile Framework for Enterprise). We are practically ready to adapt this at the Team Level and Program Level since our current planning and workflows already closely align with it.
From over 4 years of trial and error leading to our current Agile success, I strongly believe that Executives and Managers are the most critical factors. Technical skills and other practices will naturally follow.
Finally, to any team currently trying to adopt Agile: Please have a serious conversation with your executives or managers first. Otherwise, you will be exhausting yourself for nothing.
