Optimizing Agile Workflow: Best Practices, Collaboration, and Ethical Standards at Tikweb

In this article, we’ll take you behind the scenes of our Agile and Scrum workflow, showcasing how we harness these methodologies to streamline operations, foster collaboration, and deliver exceptional results.

Agile Foundations:

We’ve embraced Agile principles as the cornerstone of our project management philosophy. Agile empowers us to adapt quickly to changing requirements, prioritize customer satisfaction, and promote continuous improvement. By embracing Agile values such as flexibility, collaboration, and customer-centricity, we lay the groundwork for success in every project we undertake.

Understanding Scrum:

Within our Agile framework, Scrum serves as our preferred methodology for organizing and executing projects. Scrum provides a structured framework for iterative development, enabling cross-functional teams to collaborate effectively and deliver value incrementally.

Scrum Roles

Product Owner:

The Product Owner is responsible for representing the interests of stakeholders and ensuring that the Scrum Team delivers maximum value. They prioritize the backlog, define user stories, and provide guidance on product vision and direction.

Scrum Master:

The Scrum Master serves as a servant-leader for the Scrum Team, facilitating meetings, removing impediments, and fostering a culture of continuous improvement. They ensure adherence to Scrum principles and help the team maximize its productivity and effectiveness.

Software Development Team:

Comprising of cross-functional members, the Software Development Team is responsible for delivering the product increment. They collaborate closely, leveraging their diverse skills and expertise to achieve sprint goals and deliver high-quality solutions.

Components of the Scrum Workflow

Backlog Development:

The Product Owner collaborates with stakeholders to develop and prioritize the product backlog, ensuring that it reflects the evolving needs and priorities of the project.

Backlog Release:

Once the backlog is refined and prioritized, the Product Owner releases it for Sprint Planning, providing the Scrum Team with a clear roadmap of tasks and objectives for the upcoming sprint.

Sprint Work:

We work in sprints. Each sprint typically lasts 1-4 weeks, with the most common length being 2 weeks. Our approach to sprint lengths is adaptive; we often start with shorter sprints for new projects and adjust as our customers onboard.

Scrum or Sprint Meeting:

At the beginning of each sprint, the Scrum Team convenes for Sprint Planning, where they define the sprint goal and select the backlog items to be completed. Additionally, they hold Sprint Review and Sprint Retrospective meetings at the end of each sprint to gather feedback and reflect on their process.

Daily Stand-ups and Team Collaboration

Our daily routine kicks off with morning stand-up meetings where team managers and developers come together to discuss ongoing issues and plan the day ahead. These meetings serve as a crucial touchpoint for aligning team efforts and addressing any obstacles in real-time. Additionally, team managers review progress with stakeholders or the CTO on a weekly basis, ensuring continuous feedback and alignment with project goals.

Issue Lifecycle and Progress Tracking

When a developer begins to work on an issue, they move its status to ‘In Progress’. Upon completion, the issue transitions to ‘Test’, where stakeholders or team managers review it. In our iterative process, feedback loops are frequent; each workday morning after stand-up meetings, stakeholders or team managers assess issues in the ‘Test’ status and either approve them or move them back to ‘In Progress’ if further work is needed.

Issue Status Types and Workflow

We maintain a structured workflow with defined issue status types:

  • Todo: Ready for work; developers tackle issues based on rank.
  • In Progress: Work on the issue has commenced.
  • Test: The developer has completed their work, and the issue is ready for review.
  • QA: The issue has been approved for further testing.
  • Approved: The team leader or project staff has tested and approved the task/change for production.
  • Done: The task has been pushed to production.

Srint Closure and Reporting

At the end of each sprint, the team completes a sprint report and shares it in our company’s Slack #tech-team channel. This report summarizes the work completed during the sprint, highlighting approved changes ready for production. Project staff then leverage this information to inform customers/partners and integrate completed features into marketing and sales materials, such as newsletters and website updates.

Creating and Managing Issues

The process of creating and managing issues is streamlined to ensure efficiency and clarity:

  • We use Jira for issue tracking and maintain a variety of issue types, including bugs, ideas, stories, tasks, and epics.
  • For bug reports or issues requiring screenshots, we utilize Marker.
  • Our issue templates in Jira guide the creation process, ensuring consistency and completeness in issue descriptions.
  • Urgent issues are managed through a defined procedure involving dialogue among key stakeholders and careful consideration of sprint capacity.

Sprint Retrospective and Follow-up Planning:

At the conclusion of each sprint, the Scrum Team conducts a retrospective to reflect on their process, celebrate successes, and identify areas for improvement. They then use these insights to inform their planning for the next sprint, continuously refining and optimizing their workflow.

Jira Sprint naming

Here are 4 examples of how we name our sprints:

1 week sprint: “KEY23-26 Xxx”
2 week sprint: “KEY23-2627 Xxx”
3 week sprint: “KEY23-2628 Xxx”
4 week sprint: “KEY23-2629 Xxx”
Monthly sprint: “KEY23-jul Xxx”

KEY = Project Code
23 = Year (last 2 digits of the year)
2627 = 2 week numbers
26 = 1 week number jan/feb/mar/apr/may/jun/jul/aug/sep/oct/nov/dec = month
Xxx = Very short description about the major feature/work being done in the sprint
Example: TMPL22-3738 PROD site + login

Testing

Testing plays a pivotal role in our development process at Tikweb, ensuring that our solutions meet the highest standards of quality and reliability. Throughout the sprint, the Software Development Team conducts rigorous testing to ensure the quality and functionality of the product increment, identifying and resolving any defects or issues as they arise. Here’s an overview of our testing practices and workflows:

1. Tech Team Testing:

Developer Testing: Developers perform manual testing on local environments or on our development server (DEV) to validate their work and catch any immediate issues.

Automated Unit Testing: We leverage Laravel Dusk and Percy for automated unit testing on our testing environment (TEST). This allows us to efficiently run regression tests and ensure the stability of our codebase.

2. Stakeholder and Team Leader Review:

Project staff stakeholders are involved in testing issues and providing feedback. Approved issues are then moved forward in the workflow.

Additionally, team leaders conduct manual testing on our quality assurance (QA) environment, ensuring that issues meet the required standards before being approved for production.

3. Handling Major Issues:

In cases where issues are deemed major or have wide-ranging effects, developers or team leaders create test issues with specific instructions for staff testing. These test issues are linked to the original issue, ensuring comprehensive testing coverage.

4. Sprint Closure and Review:

Every second Monday morning, unresolved issues are moved to the next sprint, while approved issues are updated on our production environment (PROD) and marked as ‘Done’.

At the end of each sprint, staff members review completed issues on PROD to ensure that they meet expectations. This review typically occurs between Wednesday and Sunday, providing ample time for thorough evaluation.

5. Partner Testing and Evaluation:

Some issues may require testing from external partners, especially for new features or integrations. Partners who have requested the feature are invited to test and evaluate the functionality, either during the sprint on our testing environment or after sprint completion on PROD. This flexibility allows for collaborative feedback and iterative improvements.

6. Final QA and Deployment:

Upon completion of a Jira version, changes are pushed to our quality assurance (QA) environment (qa.xxx.xx) for final testing. This environment runs on a copy of our PROD site’s real data, providing a realistic testing environment.

Once the changes pass final QA, they are deployed to our production environment (PROD), ensuring that our customers receive stable and reliable updates.

In summary, our rigorous testing practices and collaborative approach to quality assurance ensure that we deliver solutions that meet the needs and expectations of our clients and stakeholders. By prioritizing thorough testing at every stage of the development lifecycle, we uphold our commitment to excellence and customer satisfaction.

Environments

We use up to 5 different environments. How many we use, generally depends on where in the project roadmap we are. From the beginning, there might be only local. Later into the project, all 5 environments should be running and be used.

Direct server logins on PROD sites use yellow prompts and markings.

The 5 environments (Local, DEV, TEST, QA, PROD)

PROD = Production = App

Direct server logins on PROD sites use yellow prompts and markings.

QA = Quality assurance

Direct server logins on QA sites, uses purple prompts and markings.

QA is our staging environment, named QA for easier understanding for the clients, as QA is short for Quality Assurance.

TEST = Testing

Direct server logins on TEST sites, uses green prompts and markings.

DEV = Developer

Local = The local environment on developer”s own local machine

WWW = Marketing site

DEMO = Demonstration

External environments for PROD and TEST

Handling Urgent Production Issues

When encountering error 500s or other critical issues, swift action is essential to maintain system stability and customer satisfaction. Any error 500’s in the Slack prod-error channel, should be fixed and pushed to PROD as soon as possible.

Immediate Response Protocol:

Upon detecting an error 500 or other critical issue, developers promptly address the issue and push the necessary fixes to our production environment (PROD) without delay.

To expedite the resolution process, developers add the Chief Technical Officer (CTO), Team Manager, and Product Owner as watchers on the corresponding Jira issue. This ensures that key stakeholders are notified of the issue and its resolution progress.

The developer then proceeds to push the fix to both the testing (TEST) and production (PROD) environments, marking the issue as ‘Done’ in Jira. This triggers automated notifications to the watchers, keeping everyone informed of the issue’s resolution status.

Communication and Transparency:

In cases where an immediate push to PROD is necessary but hasn’t been discussed with the team, developers provide a brief explanation within the Jira issue. This ensures transparency and clarity regarding the urgency of the fix.

Additionally, developers communicate the resolution of the issue in the Slack channels #prod-error and #tikweb-prod-error. They provide confirmation that the error has been fixed on both TEST and PROD environments, accompanied by a link to the corresponding Jira issue for reference.

Enhancing Collaboration with Integrations

One such integration is Slack, which serves as our central hub for company-wide communication and coordination.

The #tech-team Channel:

The #tech-team channel within our Slack workspace facilitates direct communication between the CEO, CTO, and the Tech Team Manager. While day-to-day operations typically involve communication cascading from the CEO to the CTO and then to the Tech Team Manager, this channel provides a direct line of communication for strategic discussions and decision-making.

During the initial phases of app development, particularly until version 1.0 is achieved, the #tech-team channel may be utilized for discussing complex issues requiring input from both technical and business perspectives. However, once the app is launched, its usage is reserved for urgent matters, such as critical production errors that require immediate attention in the absence of the CTO.

It’s important to exercise caution when utilizing the #tech-team channel, as it can disrupt the daily workflow of the Tech Team Manager and developers involved in ongoing sprints and issue resolution.

The #support Channel:

Our integration between Jira and Slack ensures seamless communication between our development and support/sales teams. When an issue in Jira is labeled and marked as done, a notification is automatically sent to the #support channel in Slack.

This notification mechanism enables our support and sales teams to promptly update customers when their requested issues are resolved. Relevant information from the Jira issue description can be easily copied and shared with customers to provide clarity and transparency regarding the resolution.

Promoting Effective Work Ethics

We adhere to a set of guiding principles that outline how our business and tech departments collaborate to ensure efficient development and adherence to deadlines. These ethics are essential for maintaining productivity, fostering a positive work environment, and delivering high-quality solutions to our clients.

Respecting Developer Focus:

We understand the importance of allowing developers uninterrupted focus when tackling complex coding tasks. Interruptions can disrupt their flow and mental clarity, potentially setting them back by up to 30 minutes as they recalibrate and refocus.

To mitigate this risk, we prioritize minimizing unnecessary interruptions and providing developers with the space and time they need to delve deep into their work. This not only enhances productivity but also safeguards against jeopardizing sprint timelines.

Forward-Thinking Planning:

At the onset of each sprint, we emphasize meticulous planning and alignment among developers, team managers, and the CTO. Together, we meticulously assess and prioritize the issues slated for the sprint, ensuring they constitute a manageable workload within the designated timeframe.

Once a sprint is initiated, we maintain a closed-lid approach, meaning that no new issues are added mid-sprint. This commitment to upfront planning and agreed-upon tasks minimizes the risk of derailing the sprint timeline and helps prevent the emergence of unforeseen bugs or complications.

By upholding these work ethics, we cultivate a culture of respect, collaboration, and accountability within our teams. This enables us to consistently deliver on our commitments, meet project deadlines, and exceed client expectations.

Download this article - Workflows

Download to read more

Send download link to: