Using Workflows with Agile

Structured, sequential, repeatable, and improvable. Agile workflows are flexible too. But how can Agile Workflows be done in the real world, and can this be done in FinStarty?

The purpose of this post is to help readers better understand workflows and the potential benefits of the agile methodology. In my experience with both large and small projects, I see people focused on getting tasks completed, resulting in the adoption of any workflows becoming a secondary concern, if considered at all. This can lead to confusion and inefficiency.

For a workflow to be adopted, it must align with the team members and be targeted towards achieving specific goals. Demonstrating workflows, giving teams visibility of the current workflow, letting them improve it, and documenting the improvements gives them ownership. Increasing the chances of adoption. Recently, I’ve been using Akeneo, which includes built-in workflows designed to streamline specific product data processes. These workflows will play a crucial role in the larger project and be a valuable tool, enhancing overall effectiveness.

First, Define an End Goal

Workflows should be defined. What do you want to achieve? Onboard a product to a website, onboard all the products onto the website. Make all the product data reach a certain standard. Create a process that facilitates that goal.

Breakdown Big Projects by using Tasks

To establish workflows, we need to save a sequence of projects. FinStarty refers to all jobs, both large and small, as projects. We need to develop our systems to allow the saving of sequences once they're created, but creating them is simple.

We’ll "pretend" to implement a Product Information Management (PIM) system, one large project. On the first project page, we will initially list all major tasks needed for completion. These tasks include collecting data, creating attributes (along with their respective attribute groups), and organising families, among other things.

Create Outline

Once we outline the main project, with tasks. Just a couple of clicks transform the large PIM project into several smaller child projects. We will repeat this process until we have manageable projects that feel less daunting and can be assigned to individuals or teams (scrums).

Consider Dependancies

During this process, there will also be an option to create dependencies, which will be essential for developing accurate Gantt charts. These projects, now joined, can be broken down into sections. This is a workflow that can be implemented and reused. Akeno (and others) have workflow features; some PIM project workflows can be placed here. Specialist applications that allow on-platform workflows allow tasks to be completed with minimal system switching, becoming a seamless part of people's routines. Completing these on-platform workflows contributes back to the parent projects, in this case, consolidating product data into Akeneo and making it available for use across our platforms.

Chunking down a big project into actionable, repeatable steps is the essence of a workflow.

Repeatable Steps

Using blog posts as an example, they have a simple, repeatable process. It starts from the Blogs & Content project, then a repeatable step is populating the "Easy to Rank Blogs" project with tasks that are keywords and phrases identified with "low low" keyword difficulty and relevant. It's a project that will likely never end, at least not soon. We need to continue the idea generation for posts. These are initially created as tasks and made into projects of their own.

When to repeat tasks?

• Perodicaly
  • Add more easy-to-rank blog post ideas once a week.
• Critical Levels
  • Add more easy-to-rank blog post ideas if you have fewer than 10.
• As required
  • Add more easy-to-rank blog posts, as I have no ideas remaining.

Project Types: Should we implement project types that allow us to create rules for prompting actions?

Project Statuses

Some project management platforms permit you to create an unlimited number of statuses, but currently, FinStarty does not. The available project statuses are Incomplete, Paused, In Progress, and Done. The goal is to keep the system simple, which should be sufficient for most projects.

FinStarty Development: Should "Help Required" or "Stuck" be added? What about Scheduled?

What About Waterfall Moments

It’s important to recognise waterfall moments in your workflow; certain later-stage projects cannot proceed until specific preceding steps are completed. Have you identified a dependency that signifies a waterfall moment or a critical path moment? While Agile methodologies are effective, it’s essential to acknowledge any blockers that arise, as ignoring them can negatively impact your projects.

Another reason to identify these moments is to assess whether they are as significant as they seem. Is the blocker as extensive as you think? Breaking down large projects into smaller components is a fundamental part of FinStary's approach. You may discover that only a minor segment of the larger project is being obstructed by this sticking point, and it may not be as critical as initially believed.

Feedback

Work at speed, then get feedback. I recently encouraged someone to complete a structured document quickly and not worry about structure, "put all your knowledge down, we can review it later". Feedback could be a task or project of its own, freeing people from the burden of thinking it has to be "right", we can catch/refine it feedback.

Situation Awareness

Working quickly and receiving feedback later may be poor advice, especially when project goals are not clearly defined. At times, it is necessary to slow down to progress more effectively later.

Hitting Milestones

Management often values milestones, particularly as a percentage of project completion. For me, a key milestone is reaching the Minimum Viable Product (MVP), which signifies a threshold where the project begins delivering value and surpasses previous tools. Milestones should be linked to the problem definition established at the beginning of the project. They should be easily identifiable and can be nested as child projects, potentially within multiple layers.

FinSarty & Agile Workflows

Currently, the inability to save and repeat means our systems are not fully featured enough to be considered agile. However, we can still break down large projects and identify workflows. Additionally, we need to develop visualisation tools. Kanban boards are particularly popular, and we could implement project status indicators or explore options like a Gantt chart style for better project tracking.

You can apply a methodology with any tool, but FinStary needs to make it easier.