A few years ago, I stepped into one of the most challenging and transformative projects of my career as a Cloud Architect. I was responsible for leading a cross‑regional team of more than twenty developers across Hong Kong and China. With Scrum, Atlassian JIRA, and Confluence as our backbone, we rebuilt an AWS‑based JEE Spring microservices platform using Kafka and PostgreSQL and migrated it fully to Azure. The original engineering estimate was six months. We delivered it in ten weeks.

This is the story of how alignment, structure, and communication reshaped the entire organisation.

Background

Situation
The project began with a strong team but a fragmented operating model. Everyone worked hard, but the lack of shared structure created delays and misunderstandings.

Points
• Cross‑regional team of more than twenty developers across Hong Kong and China
• Many engineers were domain experts with strong CI and CD foundations
• Multiple teams involved including product, engineering, sales, and customer success
• Hardworking culture but no unified workflow
• Required to migrate a cloud product to Azure due to client request
• Engineering estimated six months, which the business could not accept

Result
The team had the talent and capability, but without alignment, the project was heading toward an unacceptable timeline.

My Role in the Transformation

As the Cloud Architect leading this initiative, I became the bridge between product, engineering, sales, and customer success. My role was not only technical but also organisational. I facilitated communication, explained Scrum practices in simple and practical ways, and guided the teams to adopt a structured, transparent workflow. By aligning expectations, enforcing clarity, and coaching the teams through Agile execution, I helped transform the project from fragmented chaos into a predictable, collaborative delivery model.

Problems and the Real Original Situation

Situation
The delays were not caused by technical difficulty. They were caused by fragmented communication, inconsistent requirement handling, and a workflow that depended heavily on verbal instructions and individual memory. The actual “before” situation was far more chaotic than a simple misalignment.

Points
• Product team sometimes gave requirements verbally through phone calls, WhatsApp or WeChat
• Product features were told directly to individual engineers or salespeople
• Different parts of the same requirement were distributed through different channels such as email, phone, and chat
• Customer success often contacted individual engineers or product members suddenly
• No one had a complete picture of the requirement
• Engineering teams lacked visibility into each other’s status and technical availability
• Developers were frequently switched between tasks, losing focus
• Management had no visibility into progress or bottlenecks
• CS handled customer issues without knowing what was released
• Feedback rarely reached product or engineering in a structured way

Result
The organisation operated on tribal knowledge. Misunderstandings were common, rework was frequent, and timelines were unpredictable. The six‑month estimate reflected organisational misalignment, not technical complexity.

How I Solved It Using JIRA, Confluence, and Scrum

Inside the Engineering Teams

Situation
The engineering team needed structure, clarity, and a predictable rhythm.

Points
• All development work documented on the tracker
• Engineers only worked on items listed in the tracker
• Requirements treated as negotiable conversations
• PM updated the tracker after every discussion
• Engineers picked the first available item
• Story status updated continuously
• One engineer worked on one item at a time
• Requirements broken into technical tasks
• Development discussions moved into JIRA
• Work delivered into testing story by story
• Tasks created for POC, technical debt, and research
• Tasks broken down with dependencies and blockers
• One task assigned to one engineer

Result
Engineering gained clarity, focus, and a stable delivery rhythm that accelerated progress.

Inside the Product Team

Situation
The product team needed a consistent way to express requirements so engineering could execute without ambiguity.

Points
• Features and bugs written with proper structure
• Requirements documented from the user perspective
• Simple English, point form, short sentences
• Stories tested and verified quickly
• Backlog groomed regularly and prioritized top to bottom

Result
The product team became a source of clarity instead of confusion, reducing rework and saving time.

Knowledge and Task Management

Product, Knowledge, and Requirement Management

Situation
Information lived in too many places. Teams needed a single source of truth.

Points
• Confluence used as a centralized panel
• Structure followed Space to Pages to Contents
• Pages included product requirements, technical documents, and notes
• Product requirement pages included goals, milestones, and voting
• Technical documents included architecture, installation, and account details
• Notes captured meetings, research, and decisions
• Confluence pages linked directly to JIRA issues

Result
Knowledge became shared, searchable, and consistent across all teams.

Issue Types and Their Purpose

Situation
Teams needed a common language to describe work, track progress, and estimate timelines.

Points
• Bug for previously working functions that broke
• Note for behaviours that became new requirements
• Story for the smallest unit of user value
• Task for feasibility studies, POC, and technical debt
• Epic for large initiatives
• Subtask for breaking down work
• Enabled velocity tracking and release estimation
• Tracked internal and external dependencies
• Smart Commits connected code changes to tasks
• JIRA release notes notified sales and CS automatically

Result
The organisation gained predictable delivery, accurate planning, and better cross‑team alignment.

Team Meetings to Improve Communication

Situation
Tools alone were not enough. Teams needed real‑time alignment and shared understanding.

Points
• Daily morning standups with engineering
• Weekly Monday meeting with all team heads
• Customer success joined standups when client feedback needed clarification

Result
Communication became continuous, reducing misunderstandings and last‑minute surprises.

Example: From Product Design through Engineering to CS and Back

Situation
To show the impact of the transformation, here is a real example of how a feature moved through the organisation before and after the new workflow.

Before

Situation
The original workflow was chaotic, fragmented, and heavily dependent on verbal communication.

Points
• Product team sometimes gave requirements verbally through phone calls or WhatsApp
• Product features were told directly to individual engineers or salespeople
• Different parts of the same requirement were distributed through different channels
• Customer success often contacted individual engineers suddenly
• No one had a complete picture of the requirement
• Engineering built based on partial or outdated information
• Sales promised features based on verbal conversations
• CS handled customer issues without knowing what was released
• Feedback rarely reached product or engineering

Result
The organisation operated on tribal knowledge. Misunderstandings were common, rework was frequent, and timelines were unpredictable.

After

Product Design

• Product team created a clear Confluence page with goal, user story, acceptance criteria, and diagrams
• Page linked directly to a JIRA story and tasks
• All teams saw the same requirement at the same time

Engineering Development

• Engineers broke the story into tasks and subtasks
• Dependencies and blockers were defined
• Work delivered story by story into testing
• PM verified each story immediately

Release to CS

• JIRA release function automatically pushed release notes to Microsoft Teams
• CS team received a clear list of new features, fixes, and version numbers
• Sales also received the same release notes

CS Feedback Loop

• CS tested the new feature with real customers
• Feedback added as comments on the Confluence page
• Product team reviewed and updated requirements
• Engineering received new tasks or improvements linked to the original story

Result
The entire lifecycle became a closed loop. Every team saw the same truth, reacted quickly, and aligned their actions.

Before and After Comparison

Situation
The transformation changed the culture, speed, and clarity of the entire organisation. Presenting the contrast as a table makes the improvement immediately clear.

Result
The organisation shifted from reactive chaos to proactive alignment, with every team operating from the same truth.

What This Solved and the Result

Situation
Once structure, communication, and knowledge alignment were in place, the entire organisation began to move faster.

Points
• Centralized visibility improved planning and saved time
• Clear product goals reduced misunderstanding
• Early validation reduced downstream rework
• Engineering timelines became predictable
• Product page and task linkage aligned business and engineering
• JIRA auto‑release notes empowered sales and CS
• Engineering teams understood each other’s status and availability
• Defined blockers prevented last‑minute surprises
• Centralized documentation reduced search time and improved support

Result
The six‑month estimate collapsed into ten weeks because every team finally moved in the same direction.

Conclusion

Product success is built on teamwork across all functions. Improving the product development timeline required alignment from product design to feature validation, business requirement transformation, testing, release, customer success, post delivery support, and customer feedback. When every team shares the same truth, the entire organisation accelerates.

This experience, even though it happened a few years ago, remains fully relevant in today’s AI driven business era. It is a clear example of how Scrum and Agile principles solve real operational problems. The story shows that delays rarely come from tools or technical expertise. They come from the absence of a disciplined operational methodology. When teams follow a repeatable Agile process supported by a single source of truth, technology becomes an accelerator rather than a bottleneck.

What’s Next

This article presents the high level view of how Scrum and operational alignment improved a cross regional cloud migration timeline. In the next article, I will walk through the detailed implementation across each phase, and explain the specific problems the team encountered, how those challenges were solved, and how the Scrum workflow kept the project moving with clarity from design to delivery.

About the Author
Jonathan Wong is an IT and AI consultant with 20+ years of experience leading engineering teams across Vancouver and Hong Kong. He specializes in modernizing legacy platforms, cloud security, and building AI-ready systems for startups and large enterprises while advising leadership on using strategic technology to drive business growth. 
Connect with me on LinkedIn