Version 1.1
“See it, say it, fix it”
Let’s be frank, we today have highly skilled tech competencies in the world that says no to companies that say they don’t want to work agile. Agile methods are here to stay because it enables more and higher value to customers and empowering employees.
This is an article describing a model in a series of articles I will explore further in the future. This series will be called an ikigai grounded organizational framework - IGOF.
Ikigai is nothing new, it has been part of the japanese culture or concept referring to something that gives a person a sense of purpose, a reason for living. In this series of articles I will do the same but for an organization.
I will start with transparency.
In any organization, to be able to see what you fail at, what you are good at and what you will accomplish, you need transparency during delivery to customers. This is an article on how you can build transparency and see what you are good at during your delivery to customers. This article focuses on how you build transparency based on data and not just green/yellow/red subjective “stoplights” of the products and services you deliver to production. Later on I will write about transparency after production and values in that.
This article is a model of how an organization could become transparent and stay agile in the path to their goals, possibly finding exactly what you are good at as an organization, what brings value to customers - finding and defining your organization ikigai.
Transparency enables continuous learning. When an organization can se how its doing, it can learn what to improve.
ATOM is not a framework, this is a transparency model to visualize work.
ATOM is not a leadership model, this is a part of understanding if we will meet our targets, how stressed we might be, if we will get there in time and creating a window for all employees to the organizational progress - to be transparent.
Why use ATOM?:
What problem does it address?
The purpose of this article:
Expect inspiration and ideas on how to fix the “single source of truth” in your planning and transparency.
To be able to get value from this article, some prerequisites and foundations in the organization need to be established, if not, there’s a lot to do before this article could come in handy and less to gain from this article if you are not working agile.
Agile Ways of Working in teams need to be enabled and committed by leadership, that's meaning all in leadership and not just “OKed” by CTO.
If you do not have a real agile organization, this article might still help you but it will probably be less reliable because the team Epics or team members entity/ticket might not be owned and worked on according to real agile values. For example this will not work if you have “waterfall backlogs” with Product Owners creating the backlogs for the teams, because then the ownership, psychological safety and ability in the autonomy in the Epic status is not reliable.
Any kind of largest entity for the team-level work needs to be defined. A common item name for this is Epic.
The market standard is to use Jira as an agile process tracker-tool. This article excludes analysis and how to draw value of this article if you use Azure dev-ops or other tools. Since Jira is more or less a tech-standard, then the information of statuses and progress in Jira is crucial to adapt to from a leadership perspective if an organization wants to be data driven in their information overview, and use that data that already exists in Jira.
If the source of truth (transparency progress) is not in Jira, then it's a bigger challenge before it's possible to enable this article's benefits.
Entities is a generic name in ATOM of anything that is being delivered to customers, regardless of its size or name. In practice in Jira this is a ticket regardless of its size or type.
For the simplicity of this article we will use this form:
Largest entity should be in the ballpark of 6-12 months work.
Second largest entity should be in the ballpark of 3-6 months work.
Epics should be in the ballpark of 1-3 months.
Tasks and Story level work should be written so they can be completed within a single sprint (2w) by a single team member.
You choose whatever naming you feel is applicable best for the current language culture in your organization - that is the preferred way of scaling your entity sizes in ATOM.
A suggestion of ATOM is to use these namings of each size level
Initiative (6-12m)
Deliverable (3-6m)
Epic (usually already set) (1-3m)
Story/Task/Bug/Support/Incident "Story level" etc (usually already set and very adapted to each team processes) (maximum 2w)
ATOM places the sizes of entities in categories of worktype;
Initiative belongs to the strategic type of work an organization does.
Deliverables belong to a tactical type of work.
Epics and its children belong to teams - the operational type of work.
If you work in Jira, then it’s easy to start Jira project for each representation of work (think of each circle as a jira project)
In this example the yellow project would hold the Strategic Initiatives.
The purple would hold the Tactical department work Deliverables.
The green would be the team's operational Epics and Story-level type of work.
In this architecture you can simplify technical ownership of who and how each Initiative and Deliverable is created
and developed to production, also it enables WIP-limit and ownerships on each ”level”.
A common ownership model would be to focus on each level-type of work and create its traditions to talk about
transparency and its plans.
The yellow strategic Initiative level would be owned by tech and company leadership.
PMs on the purple Department Tactical Deliverables and team traditions on the green.
Each Jira project would have its own board(s) and backlog(s) and ART or similar Scrum of Scrums would be held at the purple tactical level.
More on meeting traditions later.
Together with each size of each entity comes meta-data that employees might need to understand and read, to know what needs to be done.
For example, the largest entity (Initiative) “Open American market” might need a definition of done, which could be “Done when we have 5% of our total revenue from the American market”, an possibly more important information so employees know what the work constitutes of - exactly like a well written Story/Userstory.
These largest entities of work might also need more metadata, like; sponsors, problem statement, product owners/managers, budget, cost-center, owner department, exclusions, dependencies, etc.
Common required metadata fields could be; Target date, description, definition of done, acceptance criteria, assignee, area owner (if not applied in the jira-project ticket key)
Some of these metadata could even be required before employees can create these entities.
There needs to be a documented and transparent definition of entities and their-metadata requirements that all employees can read, understand, and update.
Each entity size needs to have an owner and also that owner needs to own the process (statuses) each entity lives within (unstarted, investigation, planned, in progress, done or other).
Example: Let’s take the parent of an Epic; Deliverable.
Deliverable required fields and who can move it to a decided production (often referred to “in progress”) status, could be owned by a Product Manager.
The reason for that is to enable consistency and quality in the transparent organization of what you deliver and work on.
At the same time, each employee can technically move it to “in progress” but exactly which requirements to verify and should be filled in and enable it to move in to in progress is owned by a Product Manager. This is to hinder the subjective changes of required fields by many employees or stakeholders on the Deliverable level meta-data so “i can just get my work started” and skip some "unnecessary requirements”.
The loudest voice should not be the one that delivers the most and have the most in progress to ”draw resources”.
Due dates is not a terminology selected in ATOM, the reason is that Due dates signals a time set in stone which reminds of waterfall. Target date is a looser but still selected date that allows for adjustment if the world around you changes so we allow the culture and plans to be agile.
The meeting traditions can be called whatever you like, and preferably you name them after something already existing in your org. ART, Scrum of Scrum, Pulse Meeting, etc. Let's be agnostic.
The core purpose is to have a meeting where you sync with relative personas on the different levels of work. The more things that become transparent, the more conversation it sparks.
In teams you have the stand-ups daily, in areas/department/alliances you might have the meetings weekly or biweekly. In larger departments you might have them monthly or quarterly - it all depends on the sizes of the areas/department/alliances and the need to be agile if the organization is going through complicated or complex changes or even reorganizations.
There need to be alignment and conversation that will be sparked when departments or leadership sync on the status of work.
Since a meeting tradition of this sort, not should be just repeating what’s in the plan, common meeting traditions topic when looking at an aggregated data driven transparent ”ATOM plan” could be;
Does anybody need help with their current work, and from whom?
Is there any upcoming work (not in the plan) that needs to be sorted out or investigated?
If so, is there any dependencies or information needed to that discovery?
Is all work in the plan that is ongoing? Are we working on too many things at the same time?
ATOM does not imply all teams work in the same cadences or even all in scrum. Kanban is a well working agile process for teams to enable ATOM.
In an agile environment, there needs to be information flow that helps you make decisions of when and how to change.
Let's go through on a conceptual basis of how to aggregate the data you need to make decisions.
Each entity you work will, needs to have a status.
The name of the status can be of ANY, as long as it has a category. There needs to be a status owner in each organization, preferably an Agile Coach for each department and also for leadership workflow strategic work.
Every team needs to report (if you want to have this centrally) or be able to answer to what category the statuses adheres to.
The categories need to be “Unstarted”, “In progress”, “Done”.
The data driven statuses
To calculate the math of what status of completion each parent has, this is the ATOM model where you take each child and aggregate the status category into the parent.
Let's take an example:
In this case the Parent will be 50% “In progress” (yellow) 25% “Done” (green) and 25% in “Unstarted” (blue).
The parent in this case, will give you an idea if the whole entity by its statuses aggregated to it, the data, can possibly match the target dates set on it - it could answer “will we or won't we complete what we committed to?”
In this case, if we have a target date on the parent that is two weeks forward of the current date you are in, and each child takes at least one or two sprints (lets say its Epics) is that realistically going to be complete by then?
The answer is no, because there is 25% work not even started and totally 50% of the parent is not done.
The scalability in the children/parent structure is applicable in several “hierarchical” levels. It’s easy to add another parent and calculate the children's statuses to aggregate.
The above picture operational level epics has children with tasks/storys etc, those also aggregate statuses to the Epics, but its simplified in this example to give each Epic just one status color.
In this example it's easy to assess the strategy level entity (head parent entity) as probably being done within 1,5 weeks, but a conversation needed to be had here is; “do we have any blockers in the yellow in progress Epic children and its parent on the tactical level? Why is it not done after it's planned to be done in the timeline? Will it hinder our target date on the strategy level entity? Who needs help and with what? Can we use help from other teams and form a virtual team to complete the work?
Lots of conversations get started when things get connected and transparent.
Eventually you can see each head parent entity as a living organism completing and adapting to reality in full transparency and agility when you add/remove/complete its children.
What can an organization accomplish by adjusting or drawing inspiration from this article?
The possible answer is that each organization will know if they will achieve and complete what we have set out for in an agile environment by matching it to the entity status categories of target dates.
The value that is possible to gain is now that a top parent can have a data-driven status on how the progress actually is on all the work connected in the children. Managers, leads and others roles no longer need to look at different systems, presentations, miros, charts, subjective valued ”stoplights” or spreadsheets to get an overview of how it is actually going with what the organization has planned to ship to customers. The single source of truth with Objectives or entities that is being delivered is possible.
Finishing thoughts
There are so many ways of building transparent models or WoW in any organization.
What I've learned and am trying to share is that the same organizational debt and technical debt problems exist in modern techy/hip organizations as in old waterfall organizations - but the ambition to work harder to fix those problems are vastly better in modern techy/hip organizations.
One of the reasons among many to write this down is to share simple learnings that all types of organizations can learn from, because in the end we all want better apps, services, and functions - and we don’t want institutional organizations to throw away tax money on waste.
Teal organizations strive for autonomy and peer relationships or self-management, wholeness and evolutionary purpose.
Ikigai organizations strive for a sense of purpose, a reason for existing.
Finding an organizational ikigai is a path, but if you need to choose any path and not click-install any type of model or framework - choose to become transparent - this should be considered as a suggestion on how to become transparent. As the author im happy if you can see 10% of this article as a value you can use.
