The problem is how we have been trained to behave
The problem is we have been trained to manage the work to be done, not lead the team doing the work.
The adoption of an AgileData Way of Working results in a change in the way people work and behave. It changes the tasks they do, the way and order they do the tasks, their roles and responsibilities and the way they engage and collaborate with other people.
Within the delivery pods/squads/teams there are a number of well described patterns and practices they can adopt. However for the supporting roles, their path is not so well described and in our experience they face a larger change than the delivery team members. The people providing the supporting roles often have to move from managing to leading, and depending on the individual and the organisation this can be a small or a massive change.
Leading vs Managing
Whether an individual adopts a management stance or a leadership stance is dependent on a lot of factors. What is the organisational structure they work in, is it a flat structure or a hierarchical structure. What is the organisational culture for decision making, are people expected to defer decisions to people with the best skills to make the decision, the most senior or experienced person who could make the decision or the person who is the highest in the hierarchical organisation chart. What is their background, did they grow up in a culture of community or extended family based effort and decision making, or did they grow up in a silo’d or structured family environment. What was their educational background, did they learn in schools based on the Industrial mindset and patterns or schools based on newer collaborative learning mindset and patterns. Has the majority of their working lives been in the start-up style of organisations formed after 2001 or large command and control style organisations that have been around for generations.
The AgileData lens we use to differentiate between a person who displays leadership behaviours over management behaviours is:
Leaders focus on setting the goals for the team, lets the team get on and achieve those goals and supports them when needed. The team is responsible for the work to be done, how it is done and when it is done.
Managers focus on the work to be done, and directs the team on what work needs to be done, how it is done and when it should be done.
With an AgileData mindset we value leadership behaviour over management behaviour.
This AgileData Leader vs that Project Manager
There is a recurring anti-pattern we observe when people who have operated in project and programme management roles start to work as part of an AgileData Way of Working in a supporting role. We believe the anti-pattern is rooted in what they do, not who they are. It is about their behaviour, not their personalities and beliefs.
As managers they have been trained to behave in a certain way, their role models have reinforced this behaviour. They then practise and refine those patterns and behaviours for their entire careers.
These behaviours are an anti-pattern to the way a person behaves when they come from an agile background and with an agile mindset. We believe it is useful to articulate examples of agile behaviours we have observed in Leaders and compare them to the anti-pattern behaviours we have observed in Managers.
Just like the agile manifesto we prefer the behaviours on the left over the behaviours on the right.
This is the anti-pattern of micro-management.
A well formed and experienced AgileData team is composed of people who have the skills and experience to do the end-to-end data work. Just like you would not tell a mechanic how to fix your car, or a chef how to cook your meal, a cross-functional and self-organising team are the best people to plan and deliver the work that needs to be done to achieve a well articulated goal.
Managers are often not at an expert or coaching skill level for every data task to be done. Even if they are at a coaching level for that particular skill, their role is a supporting role, not a doing role. They should take a coaching stance and behave with a servant leaders mindset and support the team when the team needs their help, not tell the team what to do and when to do it.
This is the anti-pattern of micro-management.
A self-organising team are the best people to optimise who does the work and when, to deliver the goal in the least amount of time and with the least amount of effort. A Manager creating and assigning the work tasks disempowers the team, it removes the conversations between team members on the best way to get the work done and it removes the ability for the team to have visibility across all the work to be done.
Once a task is assigned to a team member by the Manager, and that tream member is suddenly deemed to own that task, it will result in less ownership by the team. The team member will become isolated with that task and the team are less likely to assist when they need help.
The Manager will assign the task to the a team member who they believe are at an expert level in the skills required to achieve that task. This will cause bottlenecks in the flow of the work. Self-organising teams will agree on the best person who can do the task to keep the flow of work moving, and often that will be a person who is a novice or a practitioner as the expert is already working on a higher priority task.
The behaviour of setting goals and letting the team get on with the work needing to be done to achieve the goals are prevalent in both #1 and #2. The difference is in #1 we focus on the pattern of who decides the work to be done, and in #2 we focus on the pattern of who assigns the work to be done to a team member. In both cases the answer is the team not the Manager.
This is the anti-pattern of micro-management.
There is something empowering when the team creates the cards. The key to the pattern of creating user stories, features or task cards is the conversations the team has to question and clarify the work to be done.
When the team creates the cards, they use their own words to describe the work to be done in a language they understand. The Leader can ask questions and get clarification from the team if they don’t understand what the card means. If a Manager writes the card the team will typically stay quiet if they don’t understand what is actually meant or if they disagree with the work described.
There is a challenging balance between this micro-management anti-pattern behaviour and the pattern of the Product Owner / Product Managers bringing a set of well thought out user stories to explain the goal of the iteration and provide details of the acceptance criteria they will use to test if the work is Done.
This is the anti-patterns of no team planning and of setting unrealistic expectations.
The conversation the team has on what is needed to deliver the work, is as valuable as the guestimate of effort to do the work. The conversation is what the team uses to identify the work that is involved and guess the size of the effort to deliver that work. The conversation and guestimate is based on a set of assumptions, it is likely that as the work starts being delivered, the assumptions will prove to be flawed, resulting in the guestimate of effort also being flawed. The team will understand the invalid assumptions and work with the Leader to manage the implication of the change in required effort which results.
When the Manager picks the date for the work to be done, that conversation doesn’t happen. The team has no way of guessing if the effort between starting the work and the date the Manager picked to complete the work is achievable or not. The Manager has defined the assumptions, not the team. When the team starts delivering the work and it is determined that the original delivery date will not be met, neither the Manager or the team will take ownership of the problem.
Humans are bad at estimating, hence the use of the term guestimate, we are after all just guessing as we have never done that actual piece of work before.
This is the anti-pattern of waste.
The Manager will have a project plan that is separate to the visual collaboration tools the team are using. The Manager may have created this plan in complete isolation or they may have created it based on the initial backlog grooming and iteration planning that the team did to kick off the iteration.
The Manager will be constantly trying to map and update the project plan based on the constant movement of the team visual collaboration tools, attending team ceremonies or conversations with the individual team members. This project plan is not a digital twin, it is an offline and out of date view of the work being done.
The team has to try and map the cards on their visual board to the task on the project plan. The Manager has to try and map the tasks on the project plan to the cards on the team’s visual board. A lot of the conversation will be wasted due to the miscommunication on what is being worked on and when.
Nobody will be clear on which is the source of the truth, when more than one visualisation of the work being done is in play.
This is the anti-patterns of micro-management and micro-interruptions.
The team ceremonies are designed as a forcing function, to provide regular events which force the teams to communicate and collaborate to each other in a semi structured way and create a shared understanding of where they are currently at and where they plan to go next to achieve the stated goal.
The visual collaboration tools are a way of recording the results of these conversations, in a short form. They are used to document what the team agreed and allows them to revisit it next time they have the ceremony. It also allows the team to view the current and planned states of work at any time, and ideally from anywhere.
Given these are the ceremonies and tools the team uses to communicate and collaborate amongst themselves, they are the best way for somebody outside the team to understand the status of where the team is at in delivering the desired goal, from an entire team perspective.
Teams will often break up a larger piece of work to be done, into smaller tasks and spread these tasks across multiple team members. If a Manager asks an individual team member for a “status update” then they are only getting a view of the status for part of the work being done, or based on the opinion of that particular team member.
The “pop by” behaviour (either in person or virtually) also has the negative impact of interrupting the team member from the task they were working on. We know that these interruptions force team members to switch focus and that the cost in terms of lost productivity of this focus switching is much higher than the “5 minute chat” itself.
The team ceremonies are designed to interrupt the entire team, so they are the most effective place for a Leader to listen for the answers they need, or to ask the questions they need answered.
This is the anti-pattern of waste.
This is a similar anti-pattern to #6, where the Manager is communicating to individual team members about the work being done, but rather than random “5 minute chats” with individual team members this is a scheduled weekly meeting for the entire team. The team meeting is outside the ceremonies the team are using to make themselves more effective.
The Managers meeting is run by the Manager, with the Manager doing the majority of the talking from a position of power. The team engagement is based on a Question and Answer pattern, with the Manager asking the questions and the team trying to answer them. There might be an additional meeting anti-pattern, where the Manager goes around the table and each team member talks for a few minutes about what they have worked on or plan to work on, but it is done in isolation of the visual board. When a team member mentions a blocker or a problem, there is a tendency for the Manager to deep dive and try to provide a solution in the meeting.
The goal of the meeting is for the Manager to be able to update the out of date project plan.
This is not a team endorsed ceremony and the team are not empowered to cancel the meeting if they think it has no value, unlike the other ceremonies they use to make themselves more effective.
There are a number of patterns that look similar to the Managers weekly team meetings that have value. Pastoral care meetings are one example, pastoral care is one of the things that often gets lost in a new Way of Working. Pastoral care meetings are where a Leader meets with individual team members on a regular basis to discuss the personal goals of the team member and any personal issues the team member may be experiencing. Another example is an all hands meeting, where the Leader updates the entire team on what is happening across the wider organsation.
One difference is the useful pattern ceremonies are there for the Leader to provide information to the team, the anti-pattern ceremony is for the Manager to extract information from the team.
This is the anti-pattern of micro-interruptions and waste.
The cost of time slicing between work is massive. The team will typically lose an hour before that half hour meeting as they don’t want to be in the middle of something when the meeting starts. They will then typically take an hour after the meeting to get their headspace back into what they were working on. That “little” half hour meeting just cost two and half hours of work not done time.
The team will walk into the half hour meeting with little or no understanding of what is going to be discussed. This means they are unable to plan before the meeting to ensure they bring the relevant information required to achieve the meeting’s desired outcome. Often the half hour meeting ends up with the Manager providing some background information and another meeting being booked to discuss it when the team has done the planning or research work required. This information could have been provided in another form, rather than the form of a meeting.
The outcome of the meeting could have been covered in one of the standard ceremonies, such as backlog grooming, planning, daily check in, prove it or retrospective.
This is the anti-pattern of unplanned work and waste.
One of the benefits of the AgileData Way of Working is the ability to absorb constant change, but this change always has a cost and a consequence.
The team will plan the work that needs to be done, at a time that provides the most value and results in the least amount of potentially wasted effort. The team will backlog groom work that is in the future, to help break it down into smaller manageable chunks. As the work gets closer to being prioritised for delivery the team will go into greater detail to understand the work and plan how they will deliver it. At each stage the amount of planning effort expended is higher and therefore so is the amount of wasted effort incurred when a change of prioritisation or goal happens.
During these planning ceremonies the team will be guesstimating when they think they will have the work completed. When unplanned work arises the team needs to be given the opportunity to replan and re-guestimate the effort required to achieve the goal, based on the additional late arriving work. If the unplanned work is just plonked on top of the planned work, the date the work is likely to be delivered will naturally move out, but the impact of this change will be invisible.
Once it becomes visible the unplanned work has impacted the guesstimated delivery date, there are two choices, move the delivery data out, or remove some of the planned work. These are the same choices the team will discuss when planning the impact of the unplanned work when it arrives (if they are allowed to), but those choices are discussed at the time the change of work happens allowing the Leader to make trade off decisions and communicate the impact of these decisions with the relevant stakeholders.
This is the anti-pattern of lack of collaboration.
To enable effective collaboration, communication needs to be a two way street, where the lines of communication flow both into the team and out from the team.
By keeping the team in the loop of the wider conversations they are having across the organisation the Leader is enabling the team to factor these conversations into their planning ceremonies.
The sharing of this information also helps to enable a sense of one team between the Leader and the AgileData team members.
This is the anti-pattern of lack of ownership.
This anti-pattern is often seen in organisations founded with an industrial mindset. The mindset of the organisation is based on management hierarchies, not losing face and promotion at all cost. Where nobody wants to take the blame when things do not go to plan.
The organisation has a fixed mindset and a culture of blame when something goes wrong, vs a growth mindset and a culture of learning from failures. Decisions are documented not so they can be used as hypotheses to be tested and proven or disproven, but as contractual documents that can be used to identify who was at fault. This behaviour results in teams being cagey when asked to estimate how long work will take to be delivered, or asked to deliver high risk work.