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, training, and coaches trying to adapt the same ideology and practices of Agile for non-IT teams.
And this is the result:
Yep, pushing a square peg into a round hole. In quite a few cases even IT teams are round holes who will reject the Agile swearword.
Looking for an Agile tool that fits developer and non-developer teams? See Teamhood for Agile.
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 the 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 that can be applied to any functional area. Here are few examples of functional Agile:
To make it work it is of the most importance to understand a few things before diving into the Agile journey. Mainly you need to have a level 1 Team which is already formed.
- – Agile Marketing
- – Agile Sales
- – Agile Accounting
- – Agile Manufacturing
- – Agile Construction
- – etc.
Checklist for level 1 team
- 1. Is there a clearly defined team with a leader? If not – go define one and elect a leader.
- 2. Does the team know its purpose?
- 3. Does the team understand how their work creates business value both/either internal and/or external?
- 4. Does the team understand Agile values and why would one try to aim for those values?
- 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.
Step 3 – Create a 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. Learn more about Scrum artifacts.
Key properties of a good backlog:
- Accessible by everyone from the team at any time
- Defines priorities and order of execution
- Is ordered and refined so people can understand what needs to be done without talking to someone else
- Is constantly maintained by Agile Leader
If there are tasks that do not live in the backlog – the team should not care about it. Agile Leader is responsible for keeping up the backlog. Each task in the backlog should also follow some good practices like S.M.A.R.T. criteria.
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. More on story point estimation.
- Progress review of deliveries – Each day Team spends up to 15 minutes reviewing the progress of tasks and unblocking work from outstanding issues. Monitor Agile burndown charts for more insight.
- 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. Learn more about Scrum ceremonies.
Each team will understand and treat deliveries based on the 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.
Learn how to set the Definition of Done and the Kanban cadences.
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.
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!
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.
2019 - Present Co-founder and CEO @ Teamhood.
2015-2019 Head of software engineering department at Danske Bank.
2017-2018 Partner Associate Professor at Vilnius University. Lecturer of Software Architecture course
2011 - 2015 Managed numerous smaller IT teams at Prewise.
Co-founder of RaveIT, Eylean, No Brakes Games
Certified Agile product owner and practitioner. Managed large scale enterprise projects as well as launch of small startup products.
MSc of Software Engineering at Vilnius University.
Hobbies: Racing, MTB cycling, Windsurfing
