agile non-it

5 steps to Agile for non-IT Teams

The majority of coaching, case studies, courses, content, professionals, and tools in the Agile world are focused on IT and especially the software development field. Numerous times we have heard how business people complain about Agile transformation programs, trainings, and coaches trying to adapt the same ideology and practices of Agile for non-IT teams.

And this is the result:

agile non-it

Yep, pushing square peg into round hole. In quite a few cases even IT teams are round holes who will reject the Agile swearword.

What are the Agile values?

According to the Agile manifesto those are as follows:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

If we take 4 Agile values from Agile manifesto, we will see that 3 out of 4 can be applied to any business or functional area. The one outstanding can be easily fixed and adapter to be less opinionated towards software.

Agile values non-IT version

Individuals and interactions over processes and tools
Created value over formalities
Customer collaboration over contract negotiation
Responding to change over following a plan

What we are doing here is making our peg round to fit the round hole. It is still the same peg! First of all, it means that it does not matter if we are introducing Agile to IT or non-IT team. Each team will benefit from collaboration, recurring interactions, recognizing failures early, incrementing fast results and finally, continuous learning.

How to introduce Agile for non-IT teams?

In this article we propose a 5 step methodology which can be applied to any functional area. Here are few examples of functional Agile:

  • – Agile Marketing
  • – Agile Sales
  • – Agile Accounting
  • – Agile Manufacturing
  • – Agile Construction
  • – etc.

To make it work it is of the most importance to understand few things before diving into Agile journey. Mainly you need to have a level 1 Team which is already formed.

agile for non-it

Checklist for level 1 team

  1. 1. Is there a clearly defined team with a leader? If not – go define one and elect a leader.
  2. 2. Does the team know its purpose?
  3. 3. Does the team understand how their work creates business value both/either internal and/or external?
  4. 4. Does the team understand Agile values and why would one try to aim for those values?
  5. 5. Team consists of no more than 8 people (two pizza rule)

Step 1 – educate the team about Agile values and why Agile is beneficial

As we have not yet created a non-IT Agile video introduction, we will need to refer to IT specific one. But it is one of the least biased ones.

Step 2 – Define roles and responsibilities

There are plenty of different Agile methodologies already defined but as we try to stay as far as possible from IT slang, practices and processes, we propose a simplified not specific to any framework solution.

The Roles

  • Agile Leader – the single person responsible for the team’s purpose and deliveries
  • Stakeholders – both internal and external people who influence work requests and priorities
  • The team – everyone in the team, ideally including Agile Leader also as functional specialist

From our experience, while working with various industries it is best to start by defining an Agile leader who will be responsible for Agile journey across the team. There is a great course “Agile leadership” run by Pete Behrens from Scrumalliance.org for those who want to learn more about Agile Leadership. An agile leader can be both formal and informal depending on the company’s organizational structure or culture.

Stakeholders must be recognized to understand with whom the Team and Agile leader should interact to define Team’s purpose and deliveries.

non it agile team

Step 3 – create work backlog

All teams have a work backlog, it just might not be what each team should have. In the majority of cases, it is some Excel spreadsheet or Email folder where tasks are living in a semi-chaotic manner and there are only one or few people who know how to perceive information that is living there.

Proper backlog must have all the tasks/work assignments for the whole team. The backlog can be a physical whiteboard if Team has this rare commodity and they work in the co-located office. The backlog can be an online Kanban Board or an online spreadsheet.

Key properties of a good backlog:

  1. 1. Accessible by everyone from the team at any time
  2. 2. Defines priorities and order of execution
  3. 3. Is ordered and refined so people can understand what needs to be done without talking to someone else
  4. 4. Is constantly maintained by Agile Leader
Team task board

If there are tasks which do not live in the backlog – team should not care about it. Agile Leader is responsible for keeping up the backlog. Each task in backlog should also follow some good practices like S.M.A.R.T. criteria.

smart criteria tasks

Step 4 – Create Agile habits

The official word in some Agile frameworks is ceremonies, but they sound far from sexy so we went with “Habits“. Habits are necessary to ensure Agile is a non-stopping lifecycle for the team which helps to steer and polish towards Agile values. In essence, all those habits will be some form of an event/get together/meeting/gathering either virtual or online.

Order and recurrence of habits is of most importance. Each team can fine tune how often they should exercise Agile habits. Common recurrence patterns: weekly, bi-weekly, monthly.

Agile Habits

  • Collecting Priorities for deliveries – Agile Leader interacts with stakeholders to collect priorities and work demand. The agile leader puts work demand as refined tasks into the backlog
  • – Planning and committing deliveries – The Team reviews prioritized tasks and suggests how much of those can be done in the next cycle. The team commits to complete planned tasks during the cycle
  • Progress review of deliveries – Each day Team spends up to 15 minutes reviewing the progress of tasks and unblocking work from outstanding issues
  • Retrospection – At the end of every cycle team dedicates time 30-60 minutes (depending on team size) to discuss what went well, what could be improved and what actions to take during the next cycle to increase performance

Each team will understand and treat deliveries based on team’s function, but let’s take an example of a marketing team. So marketing team’s goal is to grow awareness of some product brand. Each week they gather priorities from business stakeholders in which industries the brand must be recognized. Each week marketing team’s Agile leader refines tasks that contribute towards product awareness. Each week team spends time planning and committing to specific tasks which will deliver value to brand awareness in prioritized industries. After weeks end team gathers and discusses what went well, what could be improved and what actions to take so next time they perform better. As mentioned before, habits should be performed in certain order and cycle. The above-mentioned marketing team works in weekly cycles because their business area is very competitive and weekly reaction to changes in the market is mission-critical. Let’s visualize it for future reference. Though, each team should either experiment or support cycle length by business requirements.

Policy!

If you want to have working, stress-free Agile cycles, you must ensure that no extra work is added to commitments during cycles. Also, ensure that team sustains focus on those commitments until the end of each cycle. New commitments can be added only during prioritization or planning events.

In some cases, weekly cycle can be quite an overhead because due to slower changing priorities and smoother work demand. In other cases, business might require a fast paced cycle to react and survive.

agile for non-it

Step 5 – make your Agile cycles predictable and sustainable

It means that Agile Leader together with the Team should ensure that during every Agile cycle a similar amount of business value is created. No burnouts, no overtime, no stress. By working in Agile cycles you will:

  • – Manage stakeholder expectations
  • – Introduce a formal prioritization process
  • – Discuss and identify business value
  • – Be able to provide forecasts on delivery dates
  • – Be able to react to changes with a predefined delay equal to cycle length

The epilogue

We tried to simplify here as much as possible. Agile journey itself is an incremental process. If you ever get in doubt – refer to agile values!

giphy

Each step on its own can be a small journey and take time to achieve. Nonetheless, we strongly advise maintaining the order of steps and keep everyone involved. Pushing Agile is not the way, Agile needs to be adopted because of need and understanding. So educate and stay smart.

What is Teamhood and how can it help during the Agile Journey?

Teamhood is a collaboration solution for Agile teams. With Teamhood you will cover backlog step, get help and insights for your Agile journey. To learn more about Teamhood visit our homepage.

project management
Teamhood uses cookies to improve your experience, personalize content and ads, to provide social media features and to analyze our website‘s traffic. By agreeing you accept the use of Cookies in accordance with our Cookie Policy.