Assessing your way of working
Learn about IGOR, a simple tool to help any team assess and improve its processes and rituals
IGOR stands for inputs, generate, outputs and review. Behind the acronym, there is a simple tool I have used to assess all sorts of teams’ ways of working and support them in their continuous improvement. That includes development squads, build engineers, events team, user-research teams, people operations, quick regression testing department and tech guilds.
This article is divided into two blocks: the first one is a short story of how I came about the tool, while the second is an explanation of how to put it into practice. I hope that sharing my experience with you will help me explain why the IGOR exercise is a precious addition to your facilitator toolbox.
Why was IGOR born?
Harnessing the power of DIY
There is something seductive about Kanban, the least prescriptive of the popular Agile practices and methodologies out there (with a notable and humorous exception). When I first learned about it I immediately felt its allure. The principles, the practices. So simple, so achievable. It looked to me like the do-it-yourself of methodologies and, as a software tinkerer, I immediately started fantasizing about how would my team use and adapt Kanban to their own ends.
But when I finally got the opportunity to teach Kanban and test it with my team I found that the freedom it offers comes at a price. Following, you will read about how my frustration transformed into creativity and finally into IGOR, a tool for assessing any team’s ways of working and the main subject of this article.
Principles, practices and a paradox
The Kanban guide suggests that some change management principles are common to all Kanban implementations. Specifically, the very first prescription Kanban gives you is: Start with what you do now.
That’s a nice way to start! Probably what you’re doing now makes a lot of sense. I have yet to find a team the way of working of which makes no sense whatsoever. Maybe I’ve been lucky or maybe I’ve been curious enough to scratch the surface when I thought something was funny at first glance. The case is, teams often have good reasons to work the way they do.
But then, any Kanban guide will instruct you to follow the other five principles and six practices and in an intentionally vague manner. The people behind Kanban University or Scrum.org do not want to commit to any specific industry or craft in order to broaden their audience (and to milk their cash cows, but that’s a totally different subject) but this generalization brings also ambiguity.
So, we’re discussing a generic method to apply to your current way of working which suggests starting by changing nothing but also by visualizing, limiting your work in progress, managing your flow, making your policies explicit, implementing feedback loops and improve collaboratively while evolving experimentally.
After my first Kanban workshop with a team, a lot of questions were asked: what should we visualize? Where should we implement the feedback loops? What about starting with what you do now? What should we keep and what should we change from the start? Needless to say, I was not prepared to answer most of those questions.
Back to basics
This setback got me thinking about the first Kanban principle. What is it we do now? What are the pieces of a working methodology? What should we analyze and manage? What are the quintessential components of any and all ways of working? Every team is unique in its own way!
In order to answer these questions, even for the most generic method like Kanban or even do-whatever, I had to go to the most foundational elements. I started by comparing a team to a black box: get inputs, generate outputs. That was the simplest we could get.
The black box idea caused a tsunami of frownings. Nobody was comfortable with the teams simply “generating outputs”, neither was I to be fair. We always say that efficient teams look to achieve an impactful outcome instead of simply outputting work. There was a missing piece in our black box metaphor and that was revision.
IGOR is born
So, inputs, generate outputs and review it was. I felt I was onto something and not only because of the catchy name. Ever since IGOR saw the light of day, I have used to support every Kanban workshop I have done to figure out “what we do now”. Once that was settled, it was easy for the people in the room to understand what they wanted to keep for now and what needed experimentation and changing.
The tests were a success but the scope of the tool was circumstantial, I needed to experiment further. I have tested that IGOR can be part of a retrospective or other kind of workshops, even if you are not looking for a radical change. You can put the focus on the team’s methodology as a broader topic or analyze how did the iteration fit in your current team agreements.
It is not only useful to assess an existing team ritual, but it can also be used for bootstrapping a new team. I have found that running the IGOR exercise gave a deeper agreement and a better start than just simply stating “we will use Scrum”. It helped teams define their first team agreements considering all steps; for instance, the definition of done, the definition of ready and key engineering and product metrics.
Practical IGOR
So, how do you take this tool to your team? As I mentioned above, IGOR is really simple at it takes only around 30 minutes.
Preparations
You will need a board, physical or virtual. There are multiple options for the latter, miro.com and metroretro.io are free and very popular.
On the board, draw the schema as you see above.
- I (input) at the left side
- G (generate) at the top
- O (output) at the right side
- R (review) at the bottom
- Big arrows point from the I to the G and from the G to the O
- Smaller arrows point from the R to the other letters
Finally, you should prepare some questions for your team to answer. You will find examples in the section below, just make sure to ask your own relevant questions.
Facilitating
Start explaining the purpose of the exercise and how will it help the objective of the meeting. Ask the team to first focus on the Inputs and Outputs only. Put forward your questions about these. Examples:
- What types of work items do we have?
- How do we know what should we start doing?
- How do we prioritize work items?
- Who can request/create a work item?
- How do we reject work items?
Or:
- What types of deliverables do we generate as a team?
- Who are our users and stakeholders?
- How do we deliver our work to our users?
- How do we communicate with the relevant people when our job is done?
Form groups of 2–4 people and give them some time to answer these in sticky notes in the corresponding area. After the time is up, instruct them to share with the whole team. Ask if there are any surprises or if there is anything missing. Discuss and refine, adding or editing your stickies until everyone is happy with the nature of inputs and outputs.
Ask the team to split into groups again and create a story. They should explain to you, an ignorant bypasser, how they turn work inputs into valuable outputs step-by-step. Again, use sticky notes in the Generate area to connect the inputs with the outputs and share them with the whole team after some minutes. Are the stories consistent? Is there something missing?
Finally, ask them about their review process: how do they evaluate the efficiency of every step? How does the team measure the quality of their inputs, the efficiency of their routines and the impact of their deliverables? This step can be done individually or again in groups, also depending on the energy of the room. Ask everyone to create sticky notes on each one of the arrows and share them with the group after a while.
And that’s it! Whatever comes next depends on the nature of the meeting as a whole but the team will have created very valuable insights about your ways of working. In a normal retrospective, this could help identify work items that got derailed and understand the reasons behind that. In a team bootstrapping, these should become the very first team agreements and can be documented. As stated above, this simple yet powerful tool can be used in many scenarios and you should adapt it to your ends.
Acknowledgements and a final request
I wanted to thank the ManoMano Agilist Community of Practices for their scepticism about the new and improved Kanban Official Guide and for their enthusiasm and support when I told them about IGOR. I am really happy to count you amongst my mates!
Finally, if you use IGOR with your own teams or are simply curious to learn more, I’d love to hear from you! Feel free to contact me in any way the Internet offers.
Never stop playing!
