Agile

Agile is not as much a methodology as it is a set of values, ideals and goals. Scrum and kanban are implementations of agile. Both practices are implemented differently while having the same foundation, the Agile Manifesto. They have specific, measurable and quantifiable procedures and processes. Both share the goal of breaking down projects into smaller chunks and focusing on continuous testing. The number one performance gain of agile is preventing rework. Applying either process in your company will help you spot deficiencies sooner and allow you the clarity to fix any problems that arise during the process, rather than at the end of the project. Being most effective, while adding business value, should be the end goal.

The Agile methodology is a project management approach that involves breaking the project into phases and emphasizes continuous collaboration and improvement. Teams follow a cycle of planning, executing, and evaluating.

The Agile framework is an iterative methodology. After every sprint, teams reflect and look back to see if there was anything that could be improved so they can adjust their strategy for the next sprint.

Manifesto clearly specifies the fundamental principles of the agile approach:

“Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation, Customer collaboration over contract negotiation, Responding to change over following a plan.”

As you think about your own agile software development practices, consider the following best practices, 

Use iterative development

This is a hallmark of the agile software development practice. Bigger projects are broken down into smaller chunks and continuous testing is done. In Scrum, tasks will be prioritized into sprints. Each member of the sprint will be responsible for specific tasks to complete during the sprint. In Kanban, iteration is not time-bound but implemented per task.

Don’t lose track of your daily standups

The more consistent you are with your daily standups the less backtracking and rework you will have to do. Development Team members should be prepared to discuss what has gone well or been completed, along with any concerns or roadblocks they may have incurred. Team members need to come prepared with answers to:

What did I get done in the last 24 hours? What am I going to do in the next 24 hours? And what help do I need in order to get my work done? 

There should be transparency of work so that each member is responsible for a portion of the work and know the responsibilities of their team members. Other recommendations include adhering to the “time box”: standups should not exceed 15 minutes and reserving long discussions for your weekly huddle or set up a meeting to follow.

“If longer discussions are needed, a promise between affected team members to follow-up after the stand-up works wonders to keep the session moving and also ensure follow through to resolution.” Jim Ash, Product Management Principal, CSM, nvisia

Set clean communications guidelines for your teams

This is where transparency comes into play. Each sprint should have clear and prioritized tasks and each member should know what part of the sprint/task they are responsible for. During daily standups, progress and any concerns (at a high level) should be discussed to prevent rework. Members should arrange to follow-up after for more in depth discussion and resolution.

Ensure feedback (from end user) is continuous and transparent

Feedback from the end user throughout is imperative. The agile process, in nature, is a collaborative process. At the beginning, expectations and goals should be discussed and used for road mapping. During the process, continuous feedback is necessary in navigating any issues or adjustments to deliver a satisfactory end product.

“In Scrum and Kanban, the end user requirements should anchor everything you do.”

Focus on flow. Try to reduce starts and stops.

Every time you stop a process, your team is going to lose momentum and cohesion. They are going to lose valuable brain “state” and productivity. By minimizing starts and stops, you minimize context switching that must be done by the technical team.Keep in mind, the main idea of agile implementation is to point out deficiencies in your current process. It is not intended to be a quick, easy or a painless adoption. These frameworks are in place to help you identify what needs to change or be adapted in order to get the benefits you are looking for. If you have never done agile before, we suggest starting with Scrum because it is easier to implement – and to implement in small groups rather than across your enterprise.

Kanban is a project management framework that relies on visual tasks to manage workflows, while scrum is a project management framework that helps teams structure and manage their work through a set of values, principles, and practices.

The key difference is that Agile methodology is a high-level project management approach that emphasizes iterative development, while Kanban boards are visual tools that help teams optimize their workflows.

Kanban and Scrum are two different approaches to managing and organizing work. Both are commonly used in software development but can be applied to any type of work that involves completing tasks or projects and both can be implemented within Jira using boards.

Put differently, teams should use Kanban. When Kanban practices are applied with Scrum, they provide a focus on improving the flow through the feedback loop; optimizing transparency and the frequency of inspection and adaptation for both the product and the process (from the Kanban Guide for Scrum Teams).

A kanban board often has three elements: boards, lists, and cards. Kanban boards are the biggest picture of a process that organizes broad aspects of a workflow. For example, a company may choose to have a different kanban board for different departments within its organization (i.e. finance, marketing, etc.).

Kanban is better for continuous flow work like support and services. WIP limits are set by the scrum team for every sprint, and new work is picked up only after all the work is completed. If teams need a sense of accomplishment/completion/closure, use scrum.