A Path to Transformation Beyond Technology
In recent years, I have had the opportunity to help several non-tech teams adapt to Agile ways of working. This journey often begins with a shift in the mindset rather than the adoption of a specific framework like Scrum, Kanban, or any other framework to name it. My focus has always been on understanding the underlying principles of Agile, rather than simply following a prescribed methodology. This approach is important because it highlights the difference between “being Agile” and “doing Agile.”
“Doing Agile” refers to the act of following Agile practices and using Agile tools without a deep understanding of the underlying principles. It’s about checking the boxes — holding daily, using JIRA, breaking work into sprints — without fully grasping why these practices exist or how they contribute to a team’s success. This surface-level approach can lead to frustration, as teams find themselves weighed down by what feels like additional administrative overhead. Without understanding the “why” behind Agile practices, these teams might struggle to see the real value, leading to scepticism and resistance to change.
In contrast, “being Agile” is about Agile mindset and adapting practices to fit the unique needs of the team. It’s about embracing the principles that drive Agile — such as collaboration, flexibility, and continuous improvement — and applying them in a way that genuinely benefits the team and the organisation. It means that the team is empowered to tailor Agile practices to their specific context rather than just following the process.
For instance, in my experience working with a non-tech team, the shift from “doing” to “being” Agile happened when they started to see Agile as more than just a set of tasks and deadlines. They began to understand that Agile was about creating a workflow that allowed them to meet their mandates efficiently, while also giving them the flexibility to adapt to changes in their work environment.
By introducing tools in a way that highlighted their benefits — like using JIRA’s due date feature to manage time-sensitive tasks — they started to see these tools as enablers rather than burdens. This shift in perspective allowed them to embrace Agile as a mindset, leading to more effective collaboration and better outcomes. Setting up automated email reminders made it more efficient.
Why Agile? Understanding the Need for Change
Before diving into the mechanics of Agile, it’s important to address why a team should consider adopting Agile ways of working in the first place. Agile is not just a set of tools or a new process; it’s a philosophy that emphasises flexibility, collaboration, and continuous improvement. For non-tech teams, especially those used to more traditional methods, this can be a significant cultural shift.
Agile helps teams by providing a framework to manage their work more effectively, fostering a culture of transparency, and encouraging continuous feedback. It’s about being responsive to change, focusing on delivering value, and empowering teams to take ownership of their work. For teams dealing with complex, dynamic environments — whether in finance, marketing, or HR — Agile can offer the adaptability needed to stay ahead.
When helping teams make the transition to Agile, I emphasise the importance of understanding the core principles before worrying about specific practices or tools. This is important because the tools and processes are only effective if they are supported by the right mindset.
From Theory to Practice: The Importance of Hands-On Learning
One of the most effective ways to solidify Agile concepts is through hands-on experience topped up with small exercises to evaluate the understanding. In a recent workshop I facilitated for a non-tech team, I began by assessing their current knowledge of Agile concepts and tools. This step is crucial because it allows me to tailor the session to meet the team’s specific needs.
The workshop was divided into two sessions: one focused on theory, and the other on practical application. In the theoretical session, we discussed how adopting Agile ways of working could benefit the team. We explored concepts like breaking down work into manageable chunks like Initiatives, Epics, Stories, Task or Sub-Task, prioritising tasks, and ensuring continuous feedback loops.
To clarify, the focus should not be on the structure/hierarchy, the focus should be on breaking down work in smaller doable chunks. The reason why I directly introduced the structure is to align with the Product Owner’s who operate at the Initiatives layer in this hierarchy. It also helps with inter-team communication, as other teams follow a similar structure.
In the practical session, we moved from theory to action. I asked participants to create examples of actual initiatives, breaking them down into initiatives, epics, stories, tasks, and subtasks. This exercise is more than just a drill; it’s a way for the team to internalise Agile concepts and apply them to their daily work.
During these activities, I encourage open discussion within the group. The team members debate whether a particular piece of work should be categorised as an epic, story, or task. I share my insights based on my experience as a Scrum Master, but ultimately, the team decides what works best for them. This autonomy is key to “being Agile” — it’s about finding what fits the team’s unique context rather than rigidly adhering to external standards.
Addressing Unique Challenges with Agile Solutions
One of the most rewarding aspects of these sessions is helping teams find solutions to their specific challenges. For instance, the finance team I worked with had mandates that needed to be executed on specific days of the month. They were creating these tasks well in advance but struggled with remembering and picking them up at the right time.
In this case, we leveraged JIRA’s due date feature and set up automated email notifications to remind the team when these tasks were due. This simple adjustment made a significant difference in their workflow, ensuring they met their deadlines without the stress of constantly monitoring their task list.
The beginning of Being Agile
The transition to Agile is not just about implementing a new process — it’s about adopting a new way of thinking. By focusing on the underlying principles and making teams comfortable with the tools, we can help them move from merely “doing Agile” to truly “being Agile.” This journey involves continuous learning, adaptation, and a commitment to fostering a culture where teams feel empowered to take ownership of their work.
In my experience, the most successful Agile transformations are not the ones that are pushed down by the leadership team, but ones where teams understand why they are making the change, how it will benefit them, and how they can tailor Agile practices to fit their specific needs. By guiding teams through this process, we can help them unlock the full potential of Agile, driving both individual and collective success.
Comments