How to choose the right Way of Working in Agile

Being motivated, having a skilled team and lots of technical knowledge isn’t enough to conduct a successful project. Like in any well-organized job, you must have a set of procedures if you want to have control and a basis for continuous improvement.

Agile tells you what to do, not how to do it.  

As already known, Agile framework does not tell you how to do something. It only gives you guidelines on what should be included but leaves freedom of choice to those on the project to organize it as they see fit.  

So, this article aims to offer an overview of the best practices Enlight Engineering has established over the years of working on different projects – as team extension, team as a service or custom solution provider – in robotics, energy, fintech, color, track and trace and many other industries.

About WoW in Agile  

At Enlight Engineering, we have implemented various types of WoW, which depend on the nature of the project.

These are:

• SCRUM
• KANBAN ‍

‍It is important to understand that Scrum and Kanban are just frameworks that should help development teams to evolve their WoW according to the needs of the project and current context. That means the team is free to adapt described roles, artifacts, and ceremonies in a way that is the most convenient for their work, the project and the client. The good and recommended way for the team to evolve WoW is a continuous improvement process conducted through regular Retrospective meetings.

Scrum vs Kanban

Here are some recommendations that should be considered before a Development Team decides which framework their WoW will be based on. Generally, Scrum is the preferred framework on most of the projects, but sometimes it is more convenient to give advantage to Kanban:

• Is it expected that priorities will be changed often? (YES: Kanban, NO: Scrum)
• Is it expected from the team to optimize responsiveness to change requests? (YES: Kanban, NO: Scrum)
• Are frequent change requests expected and it is hard to lock sprint for changes? (YES: Kanban, NO: Scrum)
• Is the team engaged in a small project (short term project)? (YES: Kanban, NO: Scrum)

What do Project Manager, Scrum Master and Agile Coach do?

Project Managers, Scrum Masters, and Agile Coaches each have distinct yet interconnected responsibilities in Agile project environments. The question that often arises is how similar their job is and what’s the difference between them?

Project Managers are responsible for overall project management, including planning, scheduling, and risk management, with a focus on delivering the project within scope, time, and budget constraints. Scrum Masters serve the development team by facilitating interactions, removing obstacles, and coaching on Scrum practices, while also ensuring alignment with Agile principles and values. Agile Coaches have a broader role, supporting not only the development team but also other stakeholders, including management and other departments. They focus on promoting Agile principles and practices throughout the organization, coaching teams and individuals, and guiding the organization towards an Agile mindset and culture.

In essence, while Project Managers focus on project management tasks, Scrum Masters concentrate on facilitating the Scrum process within the development team, and Agile Coaches have a more holistic role, promoting Agile values and practices throughout the organization.

The Characteristics of the Development team

Within adopted WoW all work delivered to the client is done by dedicated Scrum Teams. Scrum Teams consist of PO, SM, Development Team and in ELIGHT case sometimes optionally added PM. At Enlight Engineering, the Development Team always possesses the following characteristics:

• Team members share the same norms and rules
• Responsible to deliver committed work in time and with the defined quality
• The teams are self-organized
• The team is cross-functional  
• Teams are small, typically 5-9 people
• To minimize unnecessary communication overhead, each Scrum Team should be collocated
• The Team and each of the team members have certain responsibilities which must be fulfilled.  

‍

Steps in establishing the right Way of Working

To establish the right Way of Working on a project, the first step is to define stakeholders, roles and responsibilities in the initiation checklist.  

What if the client does not understand software development well enough?

Defining WoW depends on the experience clients have with software development projects. For example, if software development isn’t their primary activity, usually they do not understand well how a WoW is established.  

In this case, we have documented SDLC and PMLC best practices based on our previous experiences (both as a team and individual), which can help us define the WoW in the best way possible. These practices should be complied with, because we are obliged to provide quality services and that is what our primary goal is.

One way of compliance is by focusing on efficiency. This was done by creating the Efficient Team Culture. ETC is a series of processes that we have set up to ensure that every team is efficient, gets to their performing phase fast and creates value for our clients. Team Leaders have the most important role in its practical implementation, with the help of the company’s management. Read more about it here.  

The team should be aware of what is to be created, where it will be used, or we are risking high dissatisfaction. The team should have a clear picture of what their work will achieve. This is defined at kick-off meetings.

Implementation of the chosen WoW

The next step of WoW establishment is the implementation of the chosen WoW.  

Scrum framework is distinguished from other agile frameworks by specific concepts and practices, divided into three categories: Roles, Artifacts, and Ceremonies.

Here’s a brief overview of Enlight Engineering best practices to implement WoW through these categories.  

Best practices in WoW implementation

Artifacts  

The integral parts of the “artifacts” category:

• Product backlog
• Sprint Backlog and Task/Kanban Board  
• Burn Down Chart
• Impediment Backlog (Retrospective Backlog)
• Potentially Shippable Product Increment
• Short Term Goal

Product Backlog

The artifacts revolve around product backlog which is a “living” system – items are added, changed, and/or removed from the backlog throughout the entire duration of the project.

Enlight Engineering uses Product Backlog from some system agreed with the client, e.g. JIRA, TFS, [PBL], etc. This PBL system is then customized based on the client requirements or platform which is used.

All backlog items are prioritized based on their value to the project. Prioritization may consider factors such as risks, benefits, costs, and estimates.

To consider with product backlog:

• The Definition of Ready establishes criteria that Product Backlog Items must satisfy before they are considered ready for implementation.
• The Definition of Done defines the criteria that must be met for a PBI to be considered complete. This includes criteria related to implementation, testing, documentation, and acceptance.

Sprint Backlog and Task/Kanban Board

Enlight Engineering combines the Sprint backlog list of user stories and related tasks with modified Kanban board, i.e. scrum wall board, which is instantiated in the system which is used in project, e.g. JIRA or TFS, etc. The board is called a Task Board.

Modified Kanban board (scrum wall board)  

The board provides transparency and allows the team to track the status of work items from backlog refinement to completion.

Rarely, there is even a physical board, while most often the board exists only in PBL platform, e.g JIRA, TFS, or some other system used in the project. However, we have often seen benefits of using a physical board – the process is more dynamic, clear and inclusive. Sprint backlog list is an input for the Sprint Review meeting.

Burn Down Chart

The Burn Down Chart visually tracks the progress of work items against the projected rate of completion for the sprint. It helps the team monitor progress and identify any deviations from the planned trajectory, enabling timely adjustments as needed.

Impediment Backlog (Retrospective Backlog)

The Impediment Backlog captures impediments encountered during the sprint and serves as input for the sprint retrospective. By addressing impediments and proposing improvements, the team continuously enhances its efficiency and effectiveness.

Potentially Shippable Product Increment

This increment represents tangible progress towards project goals and can be potentially released to the client.

Short Term Goal

Establishing a Short Term Goal provides the team with a clear focus for each sprint, aligning efforts towards delivering valuable outcomes. The goal is determined collaboratively by the Product Owner and the Development Team during sprint planning.  

Ceremonies

During our software development process, we have several types of meetings based on the frequency and topic of discussion. These are:  

• Sprint Planning and Refinement Meetings
• Daily (sometimes weekly, or twice a week) Scrum Meeting
• Sprint Review Meeting
• Sprint Retrospective

Now, let’s look at the basic activities of each of them.  

The work to be performed in the Sprint is planned in the Sprint Planning Meeting. Sprint Planning focuses on the following two questions:

• What needs to be and can be delivered in the Sprint Increment?
• How will the work needed for the execution of Sprint be achieved?

In spring planning, a list of open issues/bugs/defects should be considered, and only relevant ones should be included into sprint as tasks. The team is free to raise any question about any item in the sprint backlog candidate and to return the item to the product backlog if the team finds that the item is not well defined. The team is responsible for committing to a realistic target (the team selects items per priority level). Each item that is accepted by the team must be split down into concrete tasks.

In product backlog refinement, the purpose of the meeting is following:  

• Removing non-relevant backlog items.  
• Creating new backlog items as response to the new requirements.  
• Reprioritizing backlog items.  
• Defining estimates for the new backlog items.  

• Redefining estimates of the existing items.  
• Splitting backlog items which are broad in scope (epic) and getting them ready for the upcoming sprint.  
• Verifying if all backlog items are covered by acceptance criteria.  
• The team asks the Product Owner about anything that should be clarified about any of the relevant backlog items.

In Daily (sometimes weekly, or twice a week) Scrum meetings each team member should give answers to the following 3 questions:  

1. What has he/she accomplished since the last daily Scrum meeting?  
2. What is he/she going to accomplish till the next Scrum meeting?  
3. What are the impediments that prevent him/her from accomplishing the tasks? Ask for support from other team members and offer support to others.

Daily Scrum is mistaken to be a status tracking event, though, in fact, it is a planning event.

The Sprint Review takes place at the end of the Sprint and is designed to gather actionable feedback on what the team has completed during the Sprint. This is a very informal meeting and should not last longer than 2 hours (no power point or similar presentation, only demo in SW of developed features, so the client can provide feedback).

The Sprint Retrospective is an integral part of the “inspect and adapt” process (also known as continuous improvement). Without this meeting the team will never be able to improve their overall output and cannot focus on overall team performance.

Through retrospective, efficiency and effectiveness are increased.

Although there are many ways to conduct an agile sprint retrospective, our recommendation is to conduct it as a start-stop-continue meeting. Using this approach (practically going through proposal items) each team member is asked to identify specific things that the team should:  

1. Start doing
2. Stop doing
3. Continue doing

Another important event in Enlight Engineering typical WoW is the SEMAT workshops.  

These workshops are usually held every quarter and should be attended by the client (project manager and project owner) and the development team. This is where the entire project is scanned – from the Way of Working, to the client, to the team.  

When you work on something for a long time, it's difficult to notice where changes are needed. Through regular SEMAT workshops, the team easily identifies and becomes aware of areas that require improvement, pinpointing problems, defining action items. Following that, in the next quarter, another SEMAT workshop is conducted to assess what has been improved and what still needs to be addressed. This is our stance on continuous improvement, enhancing the team's effectiveness.

Signs that WoW should be changed or modified

Lack of clarity within the team regarding when the "definition of ready" is met. For example, for a given user story, team members may feel uncertain about what constitutes readiness. The "definition of ready" should outline what needs to be satisfied for the client.

Often, our teams claim that the "definition of ready" is not well-defined. Key elements for a well-defined user story ready for work include clear acceptance criteria and technical considerations, which the client might overlook.

Similarly, the "definition of done" is crucial. Every piece of code written must undergo a review process, and every user story must pass through Quality Assurance (QA) testing.

Misalignment between testing and development schedules leads to frustrations and dissatisfaction within the team. When testing and development are not synchronized, it becomes challenging to revisit work done months ago, leading to confusion and delays.

What is the most challenging aspect to implement?

When it comes to implementation, we often circle back to the client's level of awareness and engagement.

While nothing is inherently difficult to implement, what we frequently hear from teams is the importance of regular retrospectives. The most common complaint is that people in retrospectives (which are typically held with the client) aren't open, and nobody addresses team issues, resulting in stagnation.  

Retrospectives must be conducted openly, with everyone candidly expressing what needs to change or what bothers them because otherwise, nothing will change.

Our goal is to eliminate any "us vs. them" mentality and ensure that all our people assimilate into their teams seamlessly.

Overview of WoW improvement channels

‍

Performance Improvement Plan  

This document allows us to track identified issues and assign responsibility for monitoring progress. It serves as a structured approach to addressing and resolving challenges.

Regular Meetings with Key Account Managers (KAM)

Consistent communication and collaboration with KAMs ensure alignment with client expectations and address any emerging issues promptly.

Daily Team Communication

This includes regular ceremonies and retrospectives, fostering open dialogue within the team to identify areas for improvement and celebrate successes.

SEMAT Workshops

These workshops provide a structured forum for the team to identify, analyze, and address process inefficiencies or bottlenecks, promoting continuous improvement.

Biweekly Problem Definition Meetings

Facilitated sessions between Team Leaders (TL), KAMs, and Chief Engineers to define and prioritize challenges. These meetings establish ownership and accountability for driving solutions forward.

‍