Transactional work is the activities that didn’t address value creation like programs or projects nor supporting the nature of that value. Transactions are described as:
- Administrative work
At the team level, “Transactions” represent impediments. These impediments are hinting the progress of that team towards the expected goal.
On the other hand, some teams are deep in transactions such as:
- Shared services
I have to agree to that sounds a bit like a stereotype. When you look at what people are working in an organization, most of their activities are transactions: reading emails, answering emails and attending meetings. When I worked for the first time with HR departments and Accounting, I was shocked about the random routine of the activities. Most of the work is repeating in the same manner weeks after weeks.
When I asked them if they saw some creativity, innovation or passion in that kind of work, I often get the deep sensation in my heart to be an alien. A very few gave positive feedback; these are “the experts”. The experts love to scrutinise in deep some activities that most of us would describe as dull. A good friend of mine is such an expert. He is a Finance Controler and Auditor. Once he told me a story when he was Controlling an audit in Italy for a subsidiary. That company just had been audited by a wagon of auditors from one of the big fours during weeks. He reviewed the whole collection of audit papers and accounts during the weekend; he found a lot of mistakes and rewrite the entire report on how it should be. He is outstanding in its job, but he is a nerd, an expert.
So, transactions are some work that’s mostly not distilling creativity and exception is made for experts.
How can I identify transactional work?
Usually, transactional work is identified with tasks — not the jobs you created but the responsibility that someone assigned to you.
When assigning a task, the manager believes that only rudimentary skills are needed for execution. That model of thoughts comes from manufacturing, from the early ages of scientific management when subordinates are handling the work delegated by their bosses. In some business areas, this system might work, but most of the time, those tasks are complex.
The traditional organizational model based on a matrix organization, the management has to assign tasks to individuals. Those tasks are operated individually in a “box”. Every day the employee has to complete the tasks, and every morning new duties are assigned.
Agile is different. Agile is considering system dynamics or in other words, the dynamics of a team. Here the work isn’t assigned to an individual, but high-level goals are given to a group. The team is planning its journey, and we say that work is pulled to individuals through self-commitment. And, when a team member is selecting the job, she or he is decomposing that work in small pieces like tasks. Here, tasks are the result of self-commitment and the negative impact of the transaction is reduced.
Example of an Agile set up in a Finance Team
My customer asked me to help him in the transformation of its Finance Entity into an Agile Organisation. During our conversations, it sounds obvious that we can use Agile techniques in Projects or Programs. Still, the vast majority of people working in that Department have their work allocated by their line managers. The nature of that work was mostly transactions and expertise.
Even if some high-level concepts are well documented on the web, in that context, the approach was to consider it with an unbiased mind and to design from scratch how an agile Finance organization might look alike.
Working at management and leadership model, we had to consider that:
- We don’t have teams
- People have to understand first why we believe in agile and what problems we want to address.
- How does such an organization look alike as our vision for next year?
From the first quote of the Agile Manifesto “we uncovering better ways of doing…”, and with the values of Kanban, we were able to start a coherent, non-invasive and not dogmatic approach.
Step one: make work visible
Making work visible sounds an easy step when you are small, but how to handle it when you are very large, global and work from everywhere?
Transparency is the idea behind that, and it is only having the full picture with all the facts and figures that you can make consistent decisions. All doesn’t make all the legacy and all the history of the enterprise. But it means everything you are having “on your plate” today.
That part sounds simple, but in reality, it is one of the toughest one. You have to feel comfortable to show up to the team how good or bad you are doing, where you are wasting time or that you are super fast. As a coach, the level of transparency is a measuring of Organizational Experience. If your colleagues in the team are comfortable with sharing, it means that they are working in a safe-container or a psychological safety nudge.
The team is also sometimes more a concept than a reality. In “structure”, the matrix created a virtual top-down team composition. Here, the team designs the people working for the same line manager as an example, in the same cluster, a community of practise (chapter). The team in AO is a group of individuals from 5 to 7 people having something in common. If the team works in a swarm on projects or programs, the solution or the purpose is the common denominator.
When the team works in a platform, it is often the line of business or the department what creates the link.
In the Digital Finance example that you can find later in this book, Finance people are all working as experts on particular tasks. The challenge isn’t to increase the Customer Experience as usual, and it is about to reduce risk and share data and reports for decision making. Each expert is in its silo. Bringing those experts together as a formal team is using a different strategy than deliver faster. The plan is in PX or People Experience and OX organizational experience. It means that the agile way of working or “mindset” is distilled through increasing interaction and collective behaviour.
Lean Kanban or proto-Kanban is a “non-violent” starting point. The team is creating a Kanban board to visualize work. Every day starts with a daily meeting to plan all together the day. And to review the previous day and what’s is coming up as urgent tasks.
Step two: improve and prioritise work
While using this Kanban Board, the whole workflow is made visible, and duplicates are discovered.
In the set up the board, you design swim lines. Those swim lines are at the beginning helping to prioritize the work.
The picture above, the MOSCOW prioritization has been used:
- On the top, you have the genuine Expedite from Kanban for all the urgent tasks to be fixed in the day (quick fixes)
- Must-Have is the highest priority
- The Should and Could have lowest priorities
- And Wish to have as nice-to-have or “super bonus.”
Every day, the team is standing in front of a physical board if you are all on-site or in front their computer with any software that you are using to share progress (Jira, MS Projects, Excel, Trello…).
At the team level, everyone agrees on the workflow (top row and column headers) which can evolve based on the nature of work you have to deliver.
Five tickets in process for five team members are also called WIP Limit or Work-in-progress limit. The idea is to avoid multi-tasking and start thinking to complete work before starting a new one. In the beginning, you will have the feeling of slowing down, but rapidly you will improve your capacity.
Every Friday Morning, the team takes one hour to ninety minutes to reflect on the work that has been delivered during the week and what to improve. That event is part review and part retrospective. The team check what work is completed and strengthen its working model.
Look for effectiveness. The aim of that approach is not to produce more, it to deliver more value that matters, and that creates impact. Creating a result is the first step to move out from a genuine transactional work while getting conscious about what you are doing as an employee and for whom. You as part of a system called enterprise are making an impact of enterprise’s future. Once you are having such a feeling, then you are engaging yourself. Engagement is a bottom-up process, and it works only if the context and the organization are designed for it.
In transaction works, people are usually over-crowded with tasks. They are reluctant to stop and to challenge their way of work. Continuous improvement isn’t genuine or even asked in a matrix organization. But it is the key for self-commitment, having a voice and empowerment.
Step three: let services emerge
After a while, the prioritisation swim lines are replaced to highlight the recurrent services. In Lean Kanban terms, it is called Classes of Service.
Making work explicit on the board enables an effective visualisation on what services are the most covered. In the example above, the team discovers that “Order-to-cash” is the leading service covered by the team’s activities “Demand-to-fulfil” comes second, and so on.
Once services highlighted on the board, the coach or any team member can ask to dive more rooted in the activities in each service. You will discover that some actions are random and others from low value. At this moment in time, automation comes into account for all recurring work in the service, and the primary service process has been improved.
From that data, the Product Owner or even the dedicated Service Process Manager can update the process also decommission it (SX strategy).
That visualisation of services will help to generate a portfolio with some measurements like lead time, defect rate, cost of delay, dependencies, etc. While working on these items, some improvements will emerge or even deep processes reengineering. These changes will be handled as swarms or small projects spikes (simulation, innovation).
All line of businesses are using Lean Kanban:
- to visualise their work
- to improve their working mode
- to discover services to automatise
- to collaborate
The activity board of each team (backlog) is a measurable portfolio of activities.
The outcome of such reorganisation of work are:
- Removing duplicates
- Work becomes explicit
- Communication between team members increases
- Teams control value creation and optimise costs
- Moving out from low engaging transactional work to safety teamwork