Agile - Mindset
It’s a problem of what we have been taught, what we have learnt and how we think
When my generation went to school we were taught based on a mindset aligned with the industrial revolution.
We were taught based on hierarchies, the teachers and principals were at the top, we were at the bottom, we were subservient. We were taught how to do a task, told what to do and how to act, if we didn't follow the rules we were “punished”. We sat at our little allocated desks, we were not allowed to get up and reform where we sat, what we did, or how we learnt. Our class size was between 20 and 30 people, that was the optimal size for a teacher and a school. We attended prepared lessons that were “given” to us (or often at us), we were not able to explore a subject in the way that suited our learning style best. Our learning was time-boxed, every lesson was 45 minutes or 1 hour and we were not allowed to explore the subject further, even if it was something we were passionate or excited about. We could of course do that in our “own time”.
We were taught based on a factory mindset, we were a cog in a big process wheel. The focus was on moving the learning widget from the left to the right.
Organisations formed before 2001 were formed and managed by people who were taught this way of working. They were taught to think this way and run organisations using this industrial mindset.
These organisations are based on hierarchies, success is when you get “promoted” up the corporate ladder, when you have more people “reporting” to you, when your “team” produces more widgets. Small change is done via projects and programmes, time-boxed windows in which a funding “bucket” is assigned and a “project team” formed to make that change. Once the time window or budget is exhausted the project is deemed a success and the project team disbanded, regardless if the desired outcome was achieved or not. Large change is done via “transformation”, larger time-boxed windows and larger transformation budgets are assigned. Multiple work streams are formed with a larger number of people who are aligned to move the organisation from its current sluggish state to a beautiful nimble butterfly. Often the transformation team are cocooned offsite into a separate building where they have lots of bean bags, movable whiteboards and colourful posters so they can “do agile”.
Unlearning this industrial mindset we have been taught is hard.
In the new generation of education young people are taught with what can be called an agile mindset.
Their teachers are there to help them gain new knowledge and learn new skills, the teachers behave like servant leaders and coaches. Young people form into small groups to learn and work on particular subjects, when the subject changes they will reform into different groups. They are free to roam the room and form spaces that they want to work and learn in, these spaces are like their groups, constantly reforming as required and desired. Groups are less than 9, this is the optimal size for collaboration and interaction. Often there are multiple teachers available to support the larger group, they are available when needed and observe when not. If a subject excites, a person can spend more time learning it to increase their knowledge and skills (within reason, exo skeletons still exist), if it doesn't they can learn the basics and move on. Learning groups comprise people of different ages, the older people learning the skills of mentoring and coaching the younger people.
Organisations formed after 2001 were formed and are led by people who were taught this agile mindset. They constantly explore and experiment with this way of working as part of their culture and Ways of Working.
These organisations are based on flat structures, success is based on delivering outcomes which add value to their customers and therefore to their organisation. Small change is constant, teams are empowered to inspect and adapt their ways of working, They test ideas when they see fit and if the change has value they adapt their Way of Working to include that change. They only keep the changes that have shown value, they are not afraid to dispose of work that failed to make a valuable impact. Teams break the changes down into small iterations or experiments by default, and change is never seen as finished. Large change is done by the same teams but triggered when a macro event happens that requires change to be coordinated across the wider organisation. The coordinated change trigger might be a start-up entering a phase of hyper growth, the organisation entering a new market or product line, the organisation growing in the number of people who work there so that the current team topologies and Ways of Working are no longer effective, or a new threat from a digital native organisation who are looking to take market share. Teams work the way they always have, but an extra level of coordination is introduced to help coordinate this phase. This coordination is managed by defining and communicating shared goals across the organisation, often using the OKRs, and letting the teams decide how they will achieve those goals. The teams work in the same place they have always worked, removing any disruption or waste. Their work is still visible, dependencies are lightly coupled and visibility of a team's work reduces the friction that often occurs when multiple teams need to collaborate to get a job done. They continue to do the work in a way that has been proven to work as they are already “being agile”.
Using and iterating this agile mindset is still hard, but not as hard as unlearning and relearning a new set of behaviours.
When we think of successful companies founded with the agile mindset, we think of Google, Airbnb, Uber, Valve etc. When we look inside those organisations we don’t see the adoption of agile frameworks and methodologies. There is no discussion about the use of Scrum or SaFe, there is just an agile mindset and the process of constant inspection, experimentation and adaptation. When we think of traditional organisations founded with the industrial mindset and who have joined the world of agile theatre, we see the wide scale adoption of agile frameworks and methodologies to “do agile”. We see the implementation of agile rules to be followed, and the retention of a hierarchy of roles and responsibilities. We see little inspection, experimentation and adaptation.
The agile mindset is different to the industrial mindset. Mindsets are hard to describe and even harder to adapt and change.
Agile Mindset
When asking an agile practitioner, expert or coach for a one sentence answer to “what is agile” you will often get the response “agile is a mindset”. When you ask the follow on question of “what is an agile mindset”, more often than not you will get an answer that is along the lines of “it is hard to explain but you will know it when you see it”
If you google search for the definition of an agile mindset you will get a variety of results.
“An agile mindset focuses on “being agile” as a foundation for success in “doing agile.” It is defined by the four values and described by the twelve principles of the Agile Manifesto and then manifested through an unlimited number of practices and different ways of working.” ICAgile
“An agile mindset is the set of attitudes supporting an agile working environment. These include respect, collaboration, improvement and learning cycles, pride in ownership, focus on delivering value, and the ability to adapt to change. This mindset is necessary to cultivate high-performing teams, who in turn deliver amazing value for their customers.” Susan McIntosh - InfoQ
Interestingly we could not find the term “agile mindset” in any of the early published agile content which is widely recognised as founding the agile movement.
You will often see statements similar to:
“A growth mindset is synonymous with an agile mindset” - ICAgile
Where the agile mindset is directly related to the growth mindset.
Growth vs Fixed Mindset
Dr. Carol Dweck published the book Mindset: The New Psychology of Success in 2006 and describes two mindsets, a fixed mindset and a growth mindset.
Fixed mindset
“This could be viewed as a traditional mindset, whereby people stick to what they know best, opting for familiar paths rather than investigating new opportunities. Obstacles or challenges are avoided at all costs. A fixed mindset essentially means people have a predetermined view of the world and are unwilling to change it”
Growth Mindset
“This is the essence of the Agile mindset. People with a growth mindset are open to new ideas and different ways of doing things. They do not run from a challenge — they persevere and think outside the box to develop a solution. Setbacks are not viewed as failures; rather, they are an opportunity to learn something new.”
Graphic is adapted by Nigel Holmes from the book Mindset: The New Psychology of Success by Carol S Dweck PhD.
“In the fixed mindset, everything is about the outcome. If you fail—or if you’re not the best—it’s all been wasted. The growth mindset allows people to value what they’re doing regardless of the outcome . They’re tackling problems, charting new courses, working on important issues.”
“Many growth-minded people didn’t even plan to go to the top. They got there as a result of doing what they love. It’s ironic: The top is where the fixed-mindset people hunger to be, but it’s where many growth-minded people arrive as a by-product of their enthusiasm for what they do.”
It is common to see the description of the agile mindset being connected with the growth mindset described by Dweck. It embodies the belief in the ability to inspect, learn and adapt.
Another common theme is to see the description of the agile mindset being connected with the published Agile Software Development Manifesto Values and Principles.
“Really, agile is a mindset — it’s a way of thinking — that’s defined by four values, described by twelve principles, and then manifested through an unlimited number of practices or different ways of working. It’s simply a deep understanding and culture of learning and experimentation and trying things out. Any creative work will benefit from this notion of an agile way of working.” Ahmed Sidky
Diagram is adapted from the Agile Mindset diagram by Ahmed Sidky and ICAgile
Agile Manifesto
Manifestos
“A manifesto is a published declaration of the intentions, motives, or views of the issuer, be it an individual, group, political party or government. A manifesto usually accepts a previously published opinion or public consensus or promotes a new idea with prescriptive notions for carrying out changes the author believes should be made.” Wikipedia
Manifesto for Agile Software Development
The Manifesto for Agile Software Development is widely accepted as the founding document for modern agile ways of working and is often just referred to as the Agile Manifesto.
“On February 11-13, 2001, at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah, seventeen people met to talk, ski, relax, and try to find common ground—and of course, to eat. What emerged was the Agile ‘Software Development’ Manifesto. Representatives from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others sympathetic to the need for an alternative to documentation driven, heavyweight software development processes convened.
Now, a bigger gathering of organizational anarchists would be hard to find, so what emerged from this meeting was symbolic—a Manifesto for Agile Software Development—signed by all participants. The only concern with the term agile came from Martin Fowler (a Brit for those who don’t know him) who allowed that most Americans didn’t know how to pronounce the word ‘agile’.
Alistair Cockburn’s initial concerns reflected the early thoughts of many participants. "I personally didn't expect that this particular group of agilites to ever agree on anything substantive." But his post-meeting feelings were also shared, "Speaking for myself, I am delighted by the final phrasing [of the Manifesto]. I was surprised that the others appeared equally delighted by the final phrasing. So we did agree on something substantive."
Naming ourselves "The Agile Alliance," this group of independent thinkers about software development, and sometimes competitors to each other, agreed on the Manifesto for Agile Software Development displayed on the title page of this web site.” - Agile Manifesto
You can read the rest of the history of the Agile Manifesto here: https://agilemanifesto.org/history.html
The Agile Manifesto was created by 17 people who came together from a wide range of disciplines that were founded in the Agile Mindset, well before the Agile Manifesto was created. This included:
Extreme Programming (XP)
SCRUM
DSDM
Adaptive Software Development
Crystal
Feature-Driven Development
Pragmatic Programming
Agile Software Development Manifesto Values
The founders of the Agile Manifesto defined four core values:
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.” - Agile Manifesto
AgileData Values
The values above are based on the delivery of software applications, not the delivery of data or information. If we were going to iterate these with the data domain in mind we would end up with:
“We are uncovering better ways of delivering data and information by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Valuable data and information over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.” - AgileData Manifesto
Principles
“a comprehensive and fundamental law, doctrine, or assumption”
“A principle is a proposition or value that is a guide for behaviour or evaluation. In law, it is a rule that has to be or usually is to be followed. It can be desirably followed, or it can be an inevitable consequence of something, such as the laws observed in nature or the way that a system is constructed. The principles of such a system are understood by its users as the essential characteristics of the system, or reflecting system's designed purpose, and the effective operation or use of which would be impossible if any one of the principles was to be ignored.”
https://en.wikipedia.org/wiki/Principle
https://digitalcommons.law.ggu.edu/cgi/viewcontent.cgi?article=1001&context=annlsurvey
Agile Software Development Manifesto Principles
As well describing four core values as part of the Agile Manifesto the founders also describe twelve core principles:
“We follow these principles:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity--the art of maximizing the amount of work not done--is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.” - Agile Manifesto
AgileData Principles
Principles form one element in a structured set of ideas that collectively define
and guide the organisation and the AgileData teams, from values through to actions and results.
We can take the Agile Manifesto Principles and change wherever we see “Software” to “Data and Information” like we did with the Agile Manifesto values. These are a good set of principles to define the agile part of the AgileData Ways of Working. We then need to augment them with a set of relevant principles from the product and data domains.
DataOps Manifesto & Principals
The DataOps movement has also defined a DataOps Manifesto with a set of Values and Principles.
DataOps Manifesto Values
“Whether referred to as data science, data engineering, data management, big data, business intelligence, or the like, through our work we have come to value in analytics:
Individuals and interactions over processes and tools
Working analytics over comprehensive documentation
Customer collaboration over contract negotiation
Experimentation, iteration, and feedback over extensive upfront design
Cross-functional ownership of operations over siloed responsibilities” - DataOps Manifesto
DataOps Manifesto Principles
Continually satisfy your customer: Our highest priority is to satisfy the customer through the early and continuous delivery of valuable analytic insights from a couple of minutes to weeks.
Value working analytics: We believe the primary measure of data analytics performance is the degree to which insightful analytics are delivered, incorporating accurate data, atop robust frameworks and systems.
Embrace change: We welcome evolving customer needs, and in fact, we embrace them to generate competitive advantage. We believe that the most efficient, effective, and agile method of communication with customers is face-to-face conversation.
It’s a team sport: Analytic teams will always have a variety of roles, skills, favorite tools, and titles. A diversity of backgrounds and opinions increases innovation and productivity.
Daily interactions: Customers, analytic teams, and operations must work together daily throughout the project.
Self-organize: We believe that the best analytic insight, algorithms, architectures, requirements, and designs emerge from self-organizing teams.
Reduce heroism: As the pace and breadth of need for analytic insights ever increases, we believe analytic teams should strive to reduce heroism and create sustainable and scalable data analytic teams and processes.
Reflect: Analytic teams should fine-tune their operational performance by self-reflecting, at regular intervals, on feedback provided by their customers, themselves, and operational statistics.
Analytics is code: Analytic teams use a variety of individual tools to access, integrate, model, and visualize data. Fundamentally, each of these tools generates code and configuration which describes the actions taken upon data to deliver insight.
Orchestrate: The beginning-to-end orchestration of data, tools, code, environments, and the analytic teams work is a key driver of analytic success.
Make it reproducible: Reproducible results are required and therefore we version everything: data, low-level hardware and software configurations, and the code and configuration specific to each tool in the toolchain.
Disposable environments: We believe it is important to minimize the cost for analytic team members to experiment by giving them easy to create, isolated, safe, and disposable technical environments that reflect their production environment.
Simplicity: We believe that continuous attention to technical excellence and good design enhances agility; likewise simplicity–the art of maximizing the amount of work not done–is essential.
Analytics is manufacturing: Analytic pipelines are analogous to lean manufacturing lines. We believe a fundamental concept of DataOps is a focus on process-thinking aimed at achieving continuous efficiencies in the manufacture of analytic insight.
Quality is paramount: Analytic pipelines should be built with a foundation capable of automated detection of abnormalities (jidoka) and security issues in code, configuration, and data, and should provide continuous feedback to operators for error avoidance (poka yoke).
Monitor quality and performance: Our goal is to have performance, security and quality measures that are monitored continuously to detect unexpected variation and generate operational statistics.
Reuse: We believe a foundational aspect of analytic insight manufacturing efficiency is to avoid the repetition of previous work by the individual or team.
Improve cycle times: We should strive to minimize the time and effort to turn a customer need into an analytic idea, create it in development, release it as a repeatable production process, and finally refactor and reuse that product.” - DataOps Manifesto
Leadership
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.
What #1
Why
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.
What #2
Why
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.
What #3
Why
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.
What #4
Why
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.
What #5
Why
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.
What #6
Why
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.
What #7
Why
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.
What #8
Why
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.
What #9
Why
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.
What #10
Why
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.
What #11
Why
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.
Project Managers who have done standups
The problem is there is more to Scrum than just standups
We often see a Project Manager joining the AgileData team as a Scrum Coach because they have “done standups” before. Unfortunately, lots of organisations seem to think that running standups is all you need to do to adopt an agile Way of Working.
To be an effective Scrum Coach you have to be a servant leader, supporting the team from behind, but often Project Managers have been taught to manage the work to be done and to lead or stand from the front.
Project Managers != Scrum Coaches
Often you will get somebody join your team as a Scrum Coach who has in a previous life been a Project Manager. It seems to be the natural transition, to move from being a Project Manager to being a Scrum Coach.
In our experience they often make ineffective Scrum Coaches. It is a big change to switch from the Project Manager mindset to the agile mindset.
Anti-patterns we have observed
Lack of Scrum Training
The Project Manager will not attend Scrum Training as they have already “done Scrum” or they have read the Scrum guide.
The Scrum training is all about the introduction of the language and patterns of Scrum. It helps a Scrum Coach start their journey from Novice to Practitioner to Expert to Coach. The training provides a shared understanding and language of the Scrum patterns.
Project Managers have the inevitable task of learning a new language when they move from Project patterns to agile patterns and Ways of Working. Getting a kickstart with a 2 day course that explains the basic language of Scrum can only be a good thing.
Cherry Picking Scrum Ceremonies
If using the Scrum patterns as part of your AgileData Way of Working there are a number of ceremonies that should happen in each iteration:
Daily standups;
Sprint planning;
Prove it session;
Retrospective;
Backlog grooming.
A novice Scrum Coach may miss out some of the ceremonies.
While a team using a daily standup is better than a team who doesn’t collaborate on the work they are doing each day, there is greater value in the team using all the ceremonies together.
Not Storming, Forming and Norming Scrum Ceremonies
Like all supporting roles, to be a good Scrum Coach you actually need experience in running all the Scrum ceremonies. Especially if you have a delivery team that is new to an AgileData Way of Working. Taking the team successfully through these ceremonies for the first few times takes skill and experience.
A novice Scrum Coach’s natural reaction is to either miss out some of the ceremonies or introduce all the complexities of these ceremonies to the team in the first go. This approach tends to overwhelm the team, it is much better to gradually introduce the concepts of each ceremony as the AgileData team participates in them, effectively allowing them to learn by doing.
The 1 hour stand-up
A classic fail “tell” of when a Project Manager’s anti-pattern behaviour is in play is when the standup goes from being less than 15 minutes to becoming a 1 hour talk fest.
Standing at the front, not supporting from the back
A key skill a Scrum Coach needs to have is to be able to facilitate the AgileData team so that they form, storm and become self organising.
A Project Manager acting as a Scrum Coach will either “talk at” the team, running through the list of tasks in play and maybe at the end doing a “round the table” to see if the team needs to add anything. Or they will structure the standup so that the AgileData team are “reporting” to the Scrum Coach rather than talking to each other.
The Project Manager creates the “plan”
A Project Manager is used to creating the plan themselves and assigning tasks to team members, rather than helping a team to become self organising. They are focussed on the success of the outputs not the success of the team or the success of the desired outcomes. Helping an AgileData team to become self organising is the primary goal of the Scrum Coach.
Once the AgileData team is operating successfully, the outcomes pretty much take care of themselves.
The Project Manager converts the visual board to a report
A Project Manager may create and maintain a Project Plan that is separate to the visual board the team uses to manage, track and discuss the work.
This results in duplication of effort as well as the Project Plan being constantly out of sync.
The Project Manager reports to the “steering committee“
The Product Owner or Product Manager is responsible for stakeholder engagement not the Scrum Coach.
While the concept of a steering committee itself is an anti-pattern, of one does exist it is the Product Owner or Product Managers role to liase with the steering committee to keep them informed of the prioritisation and trade-off decisions that have been made.
Agile and/or Scrum is just like mini waterfall projects
A Project Manager will encourage the team to run multiple dependent iterations, creating a “mini waterfall” Way of Working.
While there is often a need to “work forward” to help prioritise and plan future iterations, the idea of a “Requirements” iteration, then a “Build” iteration, then a “Test Iteration” then a “User Acceptance” iteration and finally a “Release” iteration is an anti-pattern.
A pattern for success
If you can’t get an experienced Scrum Coach for a new AgileData team, then identify a capable person who is a permanent member of the organisation, with the right attitude and aptitude, have them attend the initial Scrum training, then find a great Agile Coach or experienced Scrum Coach to help support them to up-skill over time.
In our experience we have found a Business, Data or BI Analyst often makes the best Scrum Coach. They tend to naturally have an agile mindset.
Read more over at
https://wow.agiledata.io/