My Articles (187) Community Articles (6) Guest Writing

My Articles

These are articles written by me, Jimi Wikman. These articles are written on a wide range of topics. The main focus is of course on Atlassian, but as I am also very much interested in other areas that I have worked, or are just interested in you will also find other categories here. Under Ways of Working you will find articles relates to the build process management, design, requirements, development, test, operations and support. Under Interesting I write about security, e-commerce and Invision Community. Under professional, I write about work as a consultant, work related health issues, business related news and other topics related to professional work.

This morning, I commented on a post by Matthias Orgler where he brought up a decision made by Sy Liebergot during the Apollo 13 mission. Matthias sees this as an example of how true Agile works if we trust the people closest to the problem instead of having management decisions. While I don't think this example is a strong advocate for team autonomy or distributed leadership per se, it does bring up a good case for why true Agility demands structure and clarity.

What happened on Apollo 13?
Let's quickly summarize the article and what happened on Apollo 13 that sparked this article by Matthias (who you should follow btw, because he writes a ton of awesome articles and posts!).
On April 13, 1970, during the Apollo 13 mission, oxygen tank pressures started to drop, and fuel cells began to fail. An EECOM controller by the name Seymour Liebergot made a decision to shut down the fuel cells to save the crew. Liebergot was an EECOM controller and was responsible for the electrical and environmental systems on board the Command Module.
During Apollo 13, flight controller Seymour Liebergot ordered a routine stirring of the oxygen tanks to address a faulty sensor reading. When astronaut Jack Swigert activated the fans, a wiring fault caused Oxygen Tank 2 to explode, damaging Tank 1 and knocking out two of the three fuel cells that powered the spacecraft. Liebergot initially suspected an instrumentation error, but working closely with his backroom support team, the collective picture of abnormal readings across multiple systems led them to confirm a catastrophic failure. With oxygen leaking and power critically reduced, the mission shifted from lunar landing to crew survival.
As a result, the crew survived, and Apollo 13 became known as NASA’s “successful failure.”

A great example of how teams should work
Matthias sees this as a great example of distributed leadership, which I disagree with, as this, in my opinion, was not leadership but authority and ownership. This might seem like nitpicking, but as you know, words matter. He also identifies that this situation required several things that are often missing in many organizations.
Clear Goals
Clear Ownership
Trust
Preparation
From this, Matthias sees that "Ordinary people, trusted with leadership, rose to extraordinary heights". The thing is, though, that Seymour Liebergot was not ordinary in any way. He was an expert in charge of one of the most critical systems onboard the Apollo 13. He was not a generalist or T-shaped worker; he was a specialised electric engineer with 8 years of hard-earned experience on multiple Apollo missions and a distinguished military background.
Where Matthias sees this as an example of Agile working because leadership was distributed, I see it as a great example of how Agility is working because of experience and expertise. This was also a team effort, as Seymour Liebergot got help from his team to identify the best solution for the situation. The decision was made not from chance, not from opinion, but from experience and expertise, and it was based on evidence as the crew of Apollo 13 confirmed the situation.
This situation did not work because the team was Agile; it worked because the team had clarity and because they knew exactly how to act through clear processes and training. It did not work because authority was distributed; it worked because the team was experienced and had earned the trust required for decisions to be the appropriate way to act.
It worked because the team was prepared and had procedures and workbooks for almost any scenario that could happen. It worked because the team knew every wire, every bolt, and every valve in the spacecraft. It worked because the team had trained and planned every aspect of the mission in detail months before launch. It worked because there was a team that trusted each other and worked together with clear ownership and authority.

Most organizations don't have teams
We tend to use the term Team for any collection of people, but a team requires more than just putting people together in a room with a common goal. People who just work together towards something are just a group, not a team. All teams are groups, but not all groups are teams. The distinction hinges on interdependence: when members genuinely need each other to accomplish something, a group becomes a team.
In group psychology, groups and teams are distinct in several important ways:

Group
A group is a collection of individuals who share a common identity, characteristic, or purpose, but whose members work largely independently. Key features:
Members may have loosely related or even unrelated goals
Coordination is minimal — members don't need to rely on each other to succeed
Success is measured individually (e.g., a class of students, a department at work)
Social influence operates through norms, conformity, and social identity (Tajfel & Turner's Social Identity Theory)
Membership can be passive — you can belong to a group without actively participating

Team
A team is a specific, more structured type of group where members are interdependent and work toward a shared goal. Key features:
Members have complementary roles and must coordinate to succeed
Collective outcomes matter more than individual ones
Accountability is mutual — members depend on each other
High levels of communication and collaboration are required
Teams develop stronger cohesion and role clarity over time
Psychologists like Richard Hackman (Hackman, J.R. (2002). Leading Teams. Harvard Business School Press) argued that true teams require a real task, clear boundaries, and a stable membership — without those, you just have a group calling itself a team (what was referred to as a "pseudo-team" by researcher Michaela West, 2000-2012 - team effectiveness in healthcare), which can actually perform worse than a well-functioning group because it creates coordination overhead without the benefits of genuine teamwork.
Research by Ruth Wageman ("Interdependence and Group Effectiveness" in Administrative Science Quarterly in 1995) specifically found that teams perform best when the task itself requires collaboration, not just when collaboration is encouraged culturally. If I can complete my work without needing you, we're functionally a group regardless of what we call ourselves.
This is why many Scrum teams struggle. If developers just pull tickets independently from a backlog and work in parallel without needing each other, they are psychologically a co-acting group — individuals doing parallel work under a shared label — not a true team.
The key is that Scrum distinguishes between role and skill. Everyone shares the accountability for delivering the increment, but in practice, people still bring different skills — frontend, backend, testing, UX, etc. The interdependence comes from needing all those skills to deliver a working product, even if no one "owns" a specialism exclusively.
This distinction is often missed in dysfunctional Scrum groups, where the impression is that Scrum teams should be T-shaped or consist of generalists. Groups that do not have specializations are, by definition, groups and not teams.

Teams develop stronger cohesion and role clarity over time
While it is broadly true that teams develop stronger cohesion and role clarity over time, the process is neither linear nor automatic. Schutz's FIRO model suggests that role clarity and cohesion are sequential rather than parallel — groups first negotiate belonging, then authority and roles, and only then develop genuine closeness. Unresolved tensions at any stage can stall or reverse the process entirely.
Sports psychology adds further nuance: Albert Carron's research (Carron, A.V., Widmeyer, W.N., & Brawley, L.R. (1985), Carron, A.V., Colman, M.M., Wheeler, J., & Stevens, D. (2002)) distinguishes between task cohesion (shared commitment to the goal) and social cohesion (interpersonal liking), and finds that task cohesion is the stronger predictor of performance — meaning a team does not need to be close to be effective. Sports research also shows that role acceptance matters as much as role clarity; a player who understands their role but resents it contributes less than one who has genuinely bought in.
Finally, cohesion is not simply a function of time together — membership changes, conflict, or weak leadership can reset a team's development, while shared pressure and challenge can accelerate it. A more precise claim is that teams have the potential to develop cohesion and role clarity over time, provided interpersonal needs are worked through, roles are accepted rather than merely assigned, and membership remains reasonably stable.

FIRO (Schutz, 1958)
FIRO (Fundamental Interpersonal Relations Orientation) describes three interpersonal needs — Inclusion, Control, and Affection — and Schutz proposed that groups move through these phases sequentially as they develop.
The fit with the claim is reasonable: FIRO implies that cohesion and role clarity do emerge over time, but through a specific interpersonal process:
Inclusion phase — members test whether they belong (identity and membership are uncertain)
Control phase — members negotiate influence and hierarchy (role clarity is being worked out here)
Affection phase — genuine closeness and trust develop (cohesion emerges here)
So FIRO actually adds important texture — cohesion and role clarity don't develop simultaneously or smoothly. Role clarity comes before cohesion in Schutz's model, and the process can stall or regress at any phase. This complicates the simple claim that teams "develop stronger cohesion and role clarity over time" as if they move together in parallel.
FIRO also implies that unresolved inclusion or control issues actively block cohesion — meaning time alone doesn't produce development. The interpersonal work has to happen.

Sports Team Research
Sports psychology offers some of the richest empirical data on team development, and it adds further nuance:
Cohesion is multidimensional — Albert Carron's work (the Group Environment Questionnaire) distinguishes between task cohesion (commitment to the group's goal) and social cohesion (liking each other). These don't always develop together, and crucially, task cohesion predicts performance better than social cohesion. A team can be high performing without members being close friends.
Role clarity and role acceptance are different things — In sports teams, players may understand their role clearly but resent it (a talented player stuck on the bench, for example). Research suggests that role acceptance matters as much as role clarity for both cohesion and performance, and this is harder to develop than mere clarity.
Cohesion can develop quickly or not at all — Elite sports teams, particularly those assembled for short tournaments, show that cohesion can form rapidly under pressure and shared challenge, rather than gradually over time. This challenges any simple linear model.
Tuckman's model Bruce Tuckmans model (Forming, Storming, Norming, Performing), is often cited alongside sports contexts and aligns with FIRO reasonably well — but sports research has shown teams can skip or revisit stages, especially when membership changes (a new signing, an injury), which resets some of the development.

Summary
The original claim — that teams develop cohesion and role clarity over time — is a reasonable default but oversimplified in three ways:
FIRO suggests that role clarity and cohesion are sequential, not parallel, and the process can stall
Sports research shows that task cohesion and social cohesion are separable, and time doesn't guarantee either
Development isn't linear — membership changes, conflict, or poor leadership can regress a team to earlier stages
A more defensible claim would be: teams have the potential to develop cohesion and role clarity over time, provided interpersonal needs are addressed, roles are not just clarified but accepted, and membership remains reasonably stable.

Authority and Leadership in Group Psychology
Group psychology has a lot to say about authority, and it's one of the more complex and contested areas.

Formal vs Emergent Leadership
Groups consistently produce leadership even when none is formally assigned. Research on leaderless groups shows that within a short time, informal hierarchies emerge based on perceived competence, assertiveness, or social dominance. This suggests leadership is a group-level phenomenon, not just an individual trait — the group partly constructs its leader by granting them influence.
Hollander's idiosyncrasy credit model is useful here — leaders earn influence by first conforming to group norms, building trust and credibility, and only then can they deviate from norms or push the group in new directions. Authority is therefore socially negotiated, not just assigned.

FIRO and Authority
As discussed earlier, Schutz placed the Control phase at the heart of group development — the negotiation of influence, hierarchy, and decision-making. Until this is resolved, the group cannot move to genuine cohesion. This means unresolved authority is one of the primary blockers of team effectiveness in FIRO's model.

Bion's Basic Assumptions
Wilfred Bion's psychodynamic work on groups is particularly rich here. He observed that groups under stress abandon rational task focus and regress into one of three basic assumption states:
Dependency — the group looks to a leader to solve everything, becoming passive
Fight-Flight — the group unites around an enemy or threat, real or imagined
Pairing — the group invests hope in two members producing a solution that saves them
These are unconscious defenses against the anxiety of collective work. The implication is that authority figures attract powerful unconscious projections — groups will idealise, rebel against, or become dependent on leaders in ways that have little to do with the leader's actual behavior. This makes authority in groups inherently emotionally loaded.

Social Identity and Leadership
Tajfel and Turner's Social Identity Theory suggests that the most effective leaders are those who are seen as prototypical of the group — embodying what the group stands for. This is why outsiders imposed as leaders often struggle even when competent, and why leadership transitions are psychologically disruptive — they threaten the group's sense of identity.

How This Fits With Scrum
Scrum's approach to authority is one of its most psychologically interesting and ambitious features — and also one of its most frequently misunderstood.
Scrum Distributes Authority Deliberately
Scrum splits authority three ways:
The Product Owner has authority over what is built
The Scrum Master has authority over how the process runs
The Developers have authority over how the work is done
This is a conscious attempt to avoid concentrating authority in a single leader, which group psychology would predict leads to either dependency (Bion) or resentment and power struggles (FIRO Control phase).

The Scrum Master Is Not a Manager
The Scrum Master role is psychologically unusual. It holds process authority without task authority — the Scrum Master can't tell developers what to build or how to build it, but facilitates the conditions for the team to self-organise. This maps loosely onto what group psychologists call a boundary manager — someone who manages the interface between the team and its environment rather than directing the work itself.
The risk, through Bion's lens, is that teams in the dependency basic assumption will project leadership onto the Scrum Master anyway — looking to them for answers, direction, and rescue — even when the role explicitly resists that. Many Scrum Masters inadvertently collude with this by stepping in too readily, which reinforces dependency rather than building team autonomy.

The Authority Vacuum Problem
Because Scrum deliberately avoids a traditional team leader, it can create an authority vacuum — particularly during the FIRO Control phase when the group is actively trying to negotiate hierarchy. Without a clear authority figure to either accept or push against, this negotiation can become covert and dysfunctional — playing out through passive resistance, cliques, or conflict over technical decisions rather than being worked through openly.
This is a known failure mode in Scrum adoption. Teams that haven't resolved the Control phase disguise authority struggles as technical disagreements.

Hollander in Scrum
Hollander's idiosyncrasy credit model also has interesting implications. In a self-managing team, influence needs to be earned through demonstrated competence and contribution rather than granted by hierarchy. This is psychologically healthy but takes time — and during that period, the team may feel uncomfortably rudderless, especially for members coming from traditionally managed environments.

Summary
Scrum's authority model is psychologically sophisticated — it tries to create the conditions for earned, distributed authority rather than imposed hierarchy. But it underestimates how much anxiety authority vacuums create, and how powerfully groups will fill that vacuum through unconscious means if it isn't addressed explicitly. The Scrum Master role carries enormous psychological weight that the framework doesn't fully acknowledge.
This is also why we see huge issues with Scrum, as the role of Scrum Master has been watered down, and we have seen way too many inexperienced and incompetent people try to fill that role. This inevitably creates dysfunction and an authority vacuum that dysfunctional teams try to fill with group authority, which only elevates the problem and creates a breeding ground for abuse of authority.

How does this fit with the Apollo 13 situation?
Based on the events described, the Apollo 13 mission control team acted as a true team in the psychological sense, and it's a compelling example of why the distinction matters.

The Evidence
Task interdependence was real and immediate — No single controller could diagnose or solve the problem alone. Liebergot needed his backroom support to make sense of the data; other flight controllers were simultaneously reporting abnormalities across different systems, and the crew depended entirely on the ground team's collective judgment. The task required collaboration — it wasn't just encouraged culturally.
Shared goal under pressure — The moment the failure was confirmed, the entire organisation reoriented around a single collective objective: bring the crew home. Individual roles and specialisms remained, but they were subordinated to one outcome that everyone owned jointly.
Mutual accountability was real — The decisions made by any one controller had immediate consequences for the crew and for every other controller. There was no clean separation of individual contributions — if the diagnosis had been wrong, it would have been a collective failure.
Role differentiation with interdependence — Each controller owned a distinct system (power, life support, propulsion, etc.), but those systems were physically and operationally connected. This is close to the psychological ideal — clear roles that genuinely need each other, rather than parallel independent work.

The Interesting Detail
Liebergot's initial instinct was to treat it as an instrumentation problem — essentially an individual diagnosis. It was only through working with his backroom team that the true picture emerged. This is a concrete illustration of what group psychology predicts: collective sense-making produces better decisions than individual judgment, particularly under uncertainty and time pressure. The team didn't just execute a known solution — they constructed understanding together.

Through Bion's Lens
What is also striking is that the team appears to have avoided Bion's dependency trap despite the enormous pressure. Rather than collapsing into passive reliance on a single authority figure, the team distributed the problem-solving across roles while remaining coordinated. This is psychologically difficult to achieve under stress — most groups regress toward dependency or fight-flight when anxiety is high. That they didn't speaks to strong prior development, clear role boundaries, and a culture that had already resolved the FIRO Control phase through training and simulation.

Summary
The Apollo 13 mission control team exhibited every psychological marker of a true team — real interdependence, shared accountability, complementary roles, and collective sense-making under pressure. It is arguably a near-perfect real-world example of what group psychology describes as effective team performance.

Where It Matches Scrum and Distributed Authority
Authority was distributed by domain — Just like Scrum splits authority between Product Owner, Scrum Master, and Developers, Mission Control splits authority by system. Each flight controller had sovereign authority over their domain — Liebergot owned power and fuel cells, others owned propulsion, life support, and so on. Nobody told Liebergot how to interpret his data. This maps closely onto Scrum's principle that developers have authority over how the work is done within their area.
No single heroic leader solved it — The diagnosis emerged collectively. Flight Director Gene Kranz coordinated, but he didn't have the technical answer — the answer came from the distributed expertise of the team working together. This mirrors the Scrum ideal where the Scrum Master facilitates without directing the technical work.
Collective ownership of the outcome — Once the crisis was confirmed, nobody was protecting their individual domain. The shared goal overrode specialisation, which is exactly what Scrum's mutual accountability model tries to produce.

Where It Diverges From Scrum
There was a clear authority figure in Kranz — Unlike Scrum, which deliberately avoids a team leader, mission control had a Flight Director with real authority. Kranz could and did make final calls. This is significant through Bion's lens — having a legitimate, trusted authority figure likely prevented the dependency or fight-flight regression that leaderless groups under stress typically fall into. Scrum's authority vacuum might have been catastrophic in this situation.
The backroom structure was explicitly hierarchical — There were front room controllers and backroom support teams in a clear hierarchy. Liebergot worked with his backroom, but he was the decision-maker for his domain. This is closer to a federated authority model than Scrum's flat self-managing team.
Decisions had to be made fast under life-or-death pressure — Scrum's ceremonies and collaborative decision-making work well when there is time to reflect, inspect, and adapt. Apollo 13 required rapid authoritative calls with incomplete information. The structure supported this by being clear about who had authority in each moment. A pure Scrum model without that clarity might have produced paralysis.

The Most Interesting Insight
Apollo 13 actually resolves one of the tensions we identified in Scrum earlier — the authority vacuum problem. Mission control had distributed authority by domain (like Scrum) but retained coordinating authority in the Flight Director role (unlike Scrum). This meant the Control phase in FIRO terms was already resolved — everyone knew their role, their boundaries, and who had final say when consensus wasn't possible.
Scrum tries to achieve the benefits of distributed authority without the coordinating authority layer, which is psychologically ambitious. Apollo 13 suggests that under high pressure and complexity, some form of coordinating authority — not micromanagement, but a trusted final decision-maker — may be what allows distributed expertise to function without collapsing into confusion.

Summary
Apollo 13 mission control was closer to a federated leadership model than pure Scrum — distributed authority within domains, but with a clear coordinating authority above them. It matched Scrum's spirit of respecting domain expertise and collective ownership, but retained enough formal authority structure to prevent the psychological risks that Scrum's flat model can create under pressure. It could be argued that this hybrid model is actually more psychologically robust than either pure hierarchy or pure self-management.

The conclusion
While I do not see the same evidence for distributed leadership or authority as Matthias, he has picked a very good example where we can see how certain aspects of Scrum and Agile mindsets are applied, but also where it is lacking. Perhaps more importantly, it shows that with some adjustments to address gaps in authority, for example, without descending to bureaucracy, we can get really good collaboration if we have the experience, expertise, and the ingredients required to form teams.
Agile can not be just a mindset. It must have a strong structure and clearly defined authority and processes that allow for decisions that are not bureaucratic and not ad-hoc, even under stress. We must build teams, not groups, and above all, we must have strong expertise combined with high competence where collaboration is required, and trust is earned, not demanded.
Agile can only exist in clarity where the unknown is the exception, not the norm.
Then we can have true Agility.

By 💫 Jimi Wikman in Collaboration & Communication · April 12Apr 12

0 comments

By 💫 Jimi Wikman · March 21Mar 21

On February 11-13, 2001, at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah, seventeen people formulated a few simple statements. Statements that would be called the Agile Manifesto and it would shape the way we work with development, for better or worse. In the 25 years that have passed since those simple statements were written down, the world has changed...

The Agile Manifesto and why it mattered
25 years ago, back in 2001, the world was a much different one. Work was, in many cases, done on massive scales with long cycles and clear separation of work as inspired by the industries where the work was carried out. Today, we refer to these long forms of projects that turned dysfunctional as processes turned into red-tape bureaucracy as waterfall. This was never a common name, however, but it was later added as a way to recognise dysfunctional process-based work in long cycles.
The fact that these seventeen people sat down and summarised what most of us today would simply call common sense is not surprising. Change had been on the way for a while, as more and more people were looking at the way, especially large organisations, worked as wasteful and dysfunctional, long before that meeting took place. This meeting just happened to become the catalyst that ignited a movement towards a more balanced and human way of working.
It became the match that ignited a desire to change. As the world of the Internet and the digital era formed at an unprecedented pace, the term Agile became synonymous with the way of working for the modern workplace.

4 simple values and 12 principles.
The Agile Manifesto is simple, with just 4 rules and 12 principles. It is expressed as a vision with no practical ways to apply, and as such, it was vague, but it provided the direction that so many wanted. The fact that it can be interpreted pretty much any way a person wants made it the perfect starting point for the inevitable pivot in ways of working.
The 4 rules of the Agile manifesto make perfect sense even today, and they reflect a frustration when stuck in a bureaucracy that focused on strict processes and absurd documentation. Today, I don't think anyone would consider the opposite of these rules to make any sense, which is why I would argue that these 4 rules would be considered common sense today.
These principles are more specific than the 4 rules, and as such, they also display that the Agile manifesto was born out of frustration. These are opinions from people who have a biased focus and a strong need to be seen and given control in a world where they had very little. There is no point of view that represents the business in these principles, and there is more focus on giving the people who came up with the principles control than on what science tells us about group psychology.
It is a document born from frustration and a desire for control more than anything else.
A document created with the best of intentions, but not with the best holistic point of view.

An Agile world turned into greed
Riding on the popularity of Extreme Programming and Scrum, the Agile manifesto ignited the desire for a more human and fast-flowing way of working. Scrum, in particular, became popular as its lightweight process appealed to the many people who wanted something new. It was vague, open for interpretation, and openly stated that it was not a methodology, but a framework. A framework that people could shape anyway they wanted, as long as the process of Scrum was followed. In fact, Scrum demanded that it be followed exactly as specified, or it was no longer Scrum!
As Scrum became more and more popular, it was inevitable that it would become commercialised, and it did not take long before paid certifications started to appear. As a scrummaster, you had to be certified, and with 20 or so pages of information with no defined way on how to actually do Scrum, it was very easy to become certified. Soon the market was flooded with scrummasters with no experience and no clue how to implement Scrum, except to quote the scripture...

Agile becomes a religion
As the digital world and the corporate world evolved, Scrum remained basically the same. As more and more people started to question the value of Scrum, it upset the community of Scrum evangelists. Words like Agile quickly were hollowed out with buzzwords, and evangelists started to use phrases like "Agile is a mindset", but with no explanation of what that meant.
Anyone questioning "Agile", which quickly started to become something mythical no one could actually quantify, would be ridiculed and gaslighted. Just suggesting that there are practical reasons why Agile, as defined in Scrum, does not work in investment projects triggered accusations of being an advocate of Taylorism and red-tape bureaucracy.
Agile was no longer about common sense or about providing a more human and realistic approach to how we work. It became an institution to be followed without question, or you would be branded as evil for even suggesting improvements or changes. Teams began to self-isolate, and mistrust towards any form of management started to create a rift in organisations, causing financial harm as well as damaging collaboration.

The Agile awakening
Then came the pandemic. People no longer interacted the same way, and as isolation had people starting to question how we work as the workforce dramatically shifted. More and more people started to look at Scrum and Agile in general, and soon they started to question things. Just like the little boy in the emperor's clothes, they called out that the emperor was indeed naked. Scrum was not a methodology, and following it to the letter (literally) did not add the value it had been sold to us for decades.
Companies started to abandon Agile, and the roles of Agile coaches and Scrum masters faded quickly. It was clear that Agile was not the magical bullet that would kill all of our problems. In fact, no one could actually define what Agile actually is. There is no definition that is useful in practice, only buzzwords like "Agile is a mindset", which is pointless and does not define anything unless you define the mindset...
Agile was no longer what people were looking for, but without alternatives, strange new alternatives sprouted. Things like SAFe, which is a waterfall with Agile terminology that tries to take the best of Agile and Waterfall, but fails at both. Lean and Flow, Kanban, and many other flavours call themselves Agile, yet no one still knows what Agile is or what problems these frameworks actually solve.
At the core, today we have a problem with Agile, and that is that it is not defined and has never been defined. You can ask anyone around the globe today, and they will have stories of how Agile, in whatever form, has worked for them. You will find the same number of stories of how Agile has turned into chaos and destroyed teams and companies.
This is not because Agile is bad or good, but because it does not exist...
..Or rather, it exists in as many variants as there are people...

The Agile manifesto explored
To understand the Agile manifesto, we must first understand where it came from. At the beginning of this article, I wrote about the meeting that the 17 authors of the Agile Manifesto held and the outcome. To understand why the outcome became what it became, we would have to talk to the authors themselves, but we can make some presumptions based on the outcome itself.
First, we need to consider the world that these people worked in at the time.

The birth of Agile
In the late 90's and early 2000's, many who worked in IT worked in large companies with heavy processes. These were processes that worked well for big engineering projects like building infrastructure. For the growing digital world, however, it was a poor fit. Not only was this a field where every day was a learning experience as we figured out how people interacted with new interfaces, but it was also a time when social advances happened at an unprecedented pace.
Massive 2-3 year plans set in stone with little to no communication or collaboration led to massive failures and a massive loss of money. Developers that was on the cutting edge of the new digital frontier were treated as workers and had little influence over the decisions that were made by managers who had no competence or understanding of the new technologies.
This was an extremely frustrating time for those who worked every day in the new technologies that saw the potential, but were never invited to voice their competence or experience. A sense of working in a dystopian world of incompetence was amplified by silo structures and a lack of access to those who made decisions.
This is where Agile came from.

Communication and involvement with clarity
From this frustration came the desire for rebellion and to take control from those who did not understand.
A desire to be heard and to be involved is a strong theme in the Agile manifesto. They want access and direct communication, and you can see that this is a group of extroverts because the second principle is not true. The most efficient way to convey information is not verbal because it depends on what format the receiver needs. Verbal is the fastest, as you have direct communication, so questions can be asked and answered at the same time.
Information is also a vague term. Instructions are never mentioned, and that is a form of information, but it is handled vastly differently from documentation, which is mentioned. To me, this shows that the group is more frustrated than trying to make a permanent solution to their problems. You can also see this in Scrum and other Agile frameworks, where everything related to communication focuses only on verbal communication.
It is also interesting that the wording is "working together" and not collaborating. If you consider the other principles where the Agile manifesto wants to take control from management and establish control in the teams, this indicates that the wording is not accidental, but deliberate. The teams should lead, and the business should provide what the teams need. In essence, a switch of the control pyramid that was in effect at that time.
I still see these requirements from teams, Agile or not, and what I find is that what they need is not communication or collaboration, but clarity. More often than not, this comes from unclear expectations, and paradoxically, that is often because there are no processes defined. This is a serious side effect of reducing the written and visual instructions as part of these principles, and to some degree, the misinterpretation of the four values.

Control and the freedom to change
The most prominent theme in the Agile Manifesto and its principles is control and the ability to make changes at any time. This is very typical for groups of people who feel that they do not have control, but also for extroverts who don't want to commit and instead have the possibility to rapidly change directions.
This is by far the most damaging aspect of the Agile manifesto, as it has led to self-isolating teams and a culture of chaos and ad-hoc behaviour when used in a dysfunctional way. We have to understand that the intention of these principles was probably not to cause this, but more of a desire to direct power to the people in this meeting who felt powerless at that time.
I believe that the intention was to move away from the dysfunctional way of working that was common in those days. A way of working where changing anything in the development aspect of a project was like pulling teeth and almost never worth the effort. They wanted more influence as they were the people on the cutting edge of technology. They probably wanted fewer stupid decisions by incompetent managers who were acting on yesterday's technology. They also wanted the ability, or the right, to change things often. This is both a sign of the times, as many things during this time were fluctuating heavily, but also a typical need from an extrovert mind.
We know for a fact that development teams do not have the competence or experience to make design decisions. They absolutely should not make any business decisions, and sadly, the outcome from these simple principles is that requirement management more or less has vanished in Agile contexts. While the world of technology still moves fast, it is nowhere as fast as it was when the Agile manifesto was drafted. Managers are far more competent and in some cases even more competent than the people in the teams.
What is even more telling here is that this was written in a time when projects ruled supreme. Not the misnamed assignments most of you work with today, but actual investment projects. As you know, there is a world of difference in how an investment project is managed and run compared to how an assignment or initiative inside an annual operational budget is managed and run. This was never a part of the Agile manifesto, which is also a cause for friction and frustration today.

Rapid change and experimentation befitting the times
This is also very typical for the times. The Internet was changing the way the world worked rapidly, and technology turned everything on its head, often on a daily basis. Code languages evolved seemingly overnight, and hardware doubled in capacity every iteration. Titles and how work was done changed often as technology and science converged, and new discoveries were made in how we interacted with our new technology.
The fact that the people in this meeting felt this way is not surprising. The will to change is their common goal for even having this meeting, and that suggests that they belong to the early adopters category, which is more open to change than most people. While I do not think anyone feels that shorter iterations of deliveries or reflecting on how we work is negative, the principle that focuses on the customer shows a lack of understanding of the business.

The code above business needs
These principles clearly show that there was no consideration for business values. The full focus of the Agile manifesto was clearly focused on technology and the development of code. While this makes sense since the people in the meeting were from the areas of technology and code, it has hurt the way we work, as a big part of how we work was never addressed.
To me, this is the biggest flaw of the Agile manifesto, as it naturally creates a rift between the business side and the technology side. This is by far the biggest problem we have today when it comes to ways of working, as Agile has never included the business side. It is, in fact, considered the anathema of Agile if you even bring that up. Nothing gets you branded as a proponent for Taylorism, or even office slavery, when you go deeper into that rabbit hole.

The Gap and the Ageing of the Agile Manifesto
Over the 25 years since the Agile manifesto was written, the world has changed. The world is no longer the same crazy world of rapid change as it was when it was written. Many will claim that it is and that we have to be fast in how we work, but this is not true. This is just stress talking through the mouths of early adopters who feel the need to jump on everything that changes. What we need today is not to be first, but to be right on time.
The way we work is slowing down. Science has taught us a lot in 25 years, especially in psychology through the fields of UX and CRO. Human-computer interaction is no longer a frontier field, but a field of continuous exploration as design shifts and changes. We know so much more today than we did 25 years ago, but we still try to execute on principles we know are wrong today.
Everything we know about group psychology and everything we know about the different fields related to developing technology says that self-organising teams are a bad idea. Believing that you can have all competence in a single team for organisations at scale is impossible. We invent new words like T-shaped profiles and full-stack developers to gaslight people into believing that a backend developer can also master UX design or that a front-end developer can optimise a database...
I see the gap between developers and management increasing rapidly. I think this is partially the reason why we are seeing mass layoffs of developers and technical people at the moment, and as managers can seize back control that they have been struggling with for decades, they will. Just like developers did when Agile started to take shape. The pendulum always swings back eventually...
The greatest failure is perhaps that the Agile manifesto never aligned with business needs, and as such, always stands as a flawed or limited expression of frustration from a small subset rather than as a whole. While the Agile manifesto does not advocate for the removal of processes or the need for documentation, the end result is that Agile is often experienced as a fragmented and confusing way of working. This fits well with people who want to control things and have a mind that can handle that type of setting, which is surprisingly few. Today we have an epidemic of stress-related illnesses with high cortisol, especially in managers, that is a direct result of a work environment lacking clarity...
Agile and the Agile manifesto were a cry for help and a call for rebellion 25 years ago. It added a lot of good things to the way we work, but it also created a massive gap between developers and the rest of the organisation. It shattered the dysfunction of the massive projects where the most competent people had no voice or influence. As time passed, what was a good thing was turned into a dysfunctional religion, effectively strangling the very solution it was designed to be. Criticism was not just expressed by former practitioners, but even the authors of the Agile manifesto expressed their critique of the state of Agile.
Agile became weaponised as a chaotic and ad-hoc way to avoid accountability and to turn away from the organisation in self-isolation...
Agile is no longer agile.

The future of Agile
I find this quote to fit the current situation very well. While Agile in the form of Scrum and SAFe that we have today is not generally working, there are plenty of examples when they do work. Not because of Scrum of SAFe, but because the people make it work. Through discipline and grit. This is a testament to the people more than to Agile itself. You also have the opposite, where individuals or groups completely destroy things by abusing the term Agile.
They also have several positive aspects that I think we should preserve. Not because of nostalgia or to keep the name Agile, because I think we need to bury the term Agile for good. We should keep them because they make sense and because they add value. In addition to the parts that we should preserve, we should also bridge the gaps and extend these things to reduce the lack of clarity.

Processes are not evil; inventing the wheel over and over is
During the last 25 years, processes and documentation, especially in the form of requirements, have been pushed out and even become vilified. We need to get past such nonsense, as we need to ensure that we have clarity in our ways of working. That does not mean that we should let the pendulum swing all the way back to the old, dysfunctional ways of massive documentations and processes that constrict and strangle work. Having dozens or even hundreds of teams create their own way of working causes fragmentation and dilution of data. It also confuses and hinders collaboration. We need to teach people what processes are and what level of processes are theirs, and how they can adjust them to improve instead of destroying.
We need a balanced approach, and it has to be defined in practice.

We need to break out of self-isolation
Groups of people should not self-isolate in an organisation, so we need to break the mindset that groups should rule supreme. Organisations are made of many people, and collaboration is always the correct way forward. Self-organisation is a myth in any organisation, and in psychology, there are plenty of warnings about what happens when groups self-organise. Groups work to create value for the organisation, not themselves, and not customers. Collaboration must happen so the most qualified voices can provide the best guidance on how to create that value.
What we need is influence and clear structures of communication that are organisation-wide.

We need accountability and clarity
As groups have become less and less competent in how to value their own work, they have also shifted away from accountability by inventing arbitrary values such as story points. We also see group accountability over individual accountability, again avoiding taking responsibility and accountability for their work. This has to stop, and we need to make sure we teach people to make estimations again and why they are important. We need individual accountability, but also to remove cultures of accusations and micromanagement.
We need clarity of who is responsible for what, so we can rebuild a culture of trust.

Agile is not the enemy; abuse of Agile is
I could continue this list with more ways that we need to adjust Agile for a modern workplace, but this article is already long enough as it is. I will end this article by pointing out that Agile is not the enemy, because Agile does not exist. The enemy is when people abuse the term to create ways of working that are harming both people and organisations. This is not done on purpose, but even more dangerously, it is done with the best of intentions by people who do not have the competence or the insight to realise they are very much affected by the Dunning-Kruger syndrome.
The road to hell is paved with good intentions, and without clarity on what Agile is and how it works, it should stay as a vision, not as a way of working.

The Agile manifesto has aged well, and it still has value. You just need to look below the surface and read it as the world was back then. Use what you see provides value to your organisation, not just your group and fill in the gaps where time has made the original intent less valuable today. Find new ways that work better today and share them with the world.
Agile is not a mindset; it is a set of ideals presented for a world we no longer live in.
It is up to us to refine and iterate on those ideals to a reality that we live in today and then to continue to iterate as the world around us changes.
--
Agile is deeply flawed because we are flawed.
That is both its beauty and its curse.

By 💫 Jimi Wikman · February 10Feb 10

The concept of groups as a way to bundle people together has been around in the Atlassian platform forever. Teams is a newer concept, and it is not designed for the same purpose as groups. As the group functionality regressed into a black hole of no visibility and poorly defined offboarding processes, which has led to security issues I think it is time to review the situation.

Groups and the black holes in the Atlassian platform
I have talked about this many times. Groups that are managed only in the Atlassian platform are a nightmare. Every Data Center installation knows the agony of cleaning groups and the dysfunction of having a platform that is detached from the global user management. It does not matter how much time you spend micromanaging your groups if you have not connected the offboarding process to include the Atlassian platform. Which, no one does for some reason...
If you have a dedicated Atlassian team managing access through groups, and even if you have the best offboarding process where the team is actually getting tasks when someone offboards, you will still have problems. No matter how well you organise things as an Atlassian admin, you can never know where or how your well-pruned groups will be used. Any space admin can add any group at any time to do anything they see fit. But they have no idea who they are providing access to...
That is the curse of the group function:
Only Atlassian Admins can see who is in a group (no visibility)
Users can add groups anywhere (no visibility)
In the most common scenario, the Atlassian platform team does not get informed when a user is offboarded, and no one documents groups, so they know why they exist or where they are being used. As a result, almost all Atlassian platforms will have people who are no longer working in an organization that have an account that they can log in with that gives them access to areas no one really knows they have access to.
More than one Atlassian platform has had security incidents because of this...

What about Teams?
Teams started as a local group inside of what is now Plans, which you still can do for some reason. It has since evolved a bit, and after a few years of Atlassian playing around with the concept, it is now in this weird state where it is conceptually broken. In theory, teams are a better implementation than groups, simply because they have visibility and team members can manage who is on the team themselves. This would hand the responsibility to the people who actually own people management and not to administrators.
We now have a Teams system field, and recently we got some automations based on Teams. Of course, Atlassian also focused on changing the color of the Teams icon in a very limited way, which no one asked for, as we want to set Team icons ourselves, but that is where Atlassian is right now. They seem ignorant of the bigger issue, or they just have not figured out how to solve it yet. To be fair, Atlassian has made some changes, but they are slow and seem to lack an overall plan.
One major issue was that Teams where organization wide objects. This was a big issue for organisations that had multiple sites, and Atlassian got a lot of backlash for it. In July 2025, a change started to roll out that changed this, so Teams were localised on the organisation level. This was a big improvement, and with the addition of Managed teams announced in March 202,5 teams seemed to be on the right track. Managed teams are basically synced groups from another system, such as an Active Directory, making the teams sync members automatically.
The reason Atlassian added the Managed Teams made many of us older Atlassian administrators chuckle a bit:
For the past 20 years, Atlassian has not changed groups, even though they suffer from the same problems as listed here. And then some...
With managed teams, regular teams, and local teams in certain products, Teams is a bit all over the place still. To make things worse, there are certain aspects of Teams that you would think would have been considered on day one when conceptualising the feature. Things like that, Team Names have to be unique (?!), or that they can be used across the platform, the way groups can. Today, Teams is pretty useless in terms of access management or as a filtering option, which is why most organisations just don't see any value in it.
There is also the fact that Atlassian keeps changing Teams, and Managed teams are sometimes referred to as Official Teams now. Atlassian is also very bad at describing Teamsand you can see this text, for example, on their official Teams App page:
This does not align with the Managed groups, or Official groups, as they sometimes call them. This kind of inconsistency causes confusion, and it happens all the time these days as Atlassian is rapidly prototyping its way to the new vision they have for the Atlassian platform. I also noticed that there is something called Team Types now, which I have never even heard about...

How can we take Teams to the next level, and what about groups?
In my opionion Atlassian should make a decision on what Teams and Groups are. Today, groups are not a good solution for any form of security because of the way groups are managed, or rather, not being managed. I suppose the idea was to follow how other platforms use groups, like for example SAP, but that is not how groups are set up or used in the Atlassian platform. In the Atlassian platform, groups are used as categories for teams that are too lazy to manage the people they work with, or that have set up monolithic spaces where way too many people work.
Teams lack a commonality across all products, which is a problem in general for the Atlassian products, as there seems to be no perceivable holistic plan. Simple concepts like naming conflicts and that Teams can be used across the Atlassian platform should be a high priority, but it seems that they are less focused on the architecture and more on the presentation. I do not know if someone is trying to push the Atlassian platform towards a social network or what the reason is for having elaborate Team presentations, but I would put more effort into the way we can use Teams instead.

Step 1 - New Architecture change for Teams
The first thing to do, in my opinion, is to remove all local Team references and only use the Team app in all products. Only use user-defined groups and Managed groups (just remove the Official designation, it just sounds weird). Restrict user-defined teams to spaces so they can not extend outside of the space scope. Only allow Managed Teams to be used across all spaces. This way, space admins can group their user base if needed, and it can be used to assign Team leaders who manage users in their team. Add a new permission for this so Team managers can add and remove users to the space and assign roles to them (possibly add an approval step from the Admin for better security). This will also prevent duplicate names, as any conflict of names would only occur inside a single space, as it only exists there.
Managed Teams are the default object. Skipp Official Teams nomenclature.
User Managed Teams are local objects in Spaces only. Rename to Local Teams
Add Permission to manage Local teams to assign Space Roles.
Add an approval function for approving additions to the Space roles.
When creating Local Teams in Plans, for example, treat the Plan as a Space or fetch from the Spaces included in the Plan.

Step 2 - Make Teams usable everywhere
The second thing to do is to make sure Teams can be used everywhere. Dashboards, Filters, JQL, approvals... everywhere where you have Groups today. This so you can remove Groups from those areas completely. Add a multiselect Teams field so more than one Team can be connected to a work item (for larger objects like projects and initiatives). Add a functionality under access in each space to restrict the assignment field to the Managed Teams that have been assigned to the space. For JSM, you might also want to add a set of restrictions based on Managed Teams for things like who you can add to a ticket or who can submit tickets. This would act as an organisation, but for internal users.
Add Teams to replace all features that today use groups (workflows, dashboards, JQL...)
Add a Multiselect Team System field for scenarios where multiple teams need to be assigned
Add Space configuration to restrict assignment to Managed Fields assigned to the Project
Add Spave configuration for JSM, restricting ticket creation or Ticket assignment for participants

Step 3 - Change Groups to become Security Groups
The third step is to remove functionality for groups to be used in filters, approvals or assignments. This should all be handled by Managed Teams now, making groups obsolete for this purpose. Instead, groups are re-defined as security groups that are used ONLY for security configuration in the Atlassian Admin section. This includes application access, global permissions and so on. These security groups are either synced or manually handled as part of the onboarding/offboarding process.
This will make a full separation between the platform security and the user management layer, ensuring that no one adds a security group to a space by accident. It also transitions user management to the Spaces and provides better and easier space management for user access. This should clarify responsibilities, which, at the moment, are very unclear regarding who is responsible for managing groups. Separating in this way will mean that Atlassian administrators are responsible for security groups and the creation of the managed Teams. Everything else is on the teams themselves and the Space owners, as it should be. In the best scenario, an Atlassian admin would have no responsibility beyond the configuration, as the users and Teams would be synced from other systems.
If done correctly, the workflow restrictions could allow Local Teams, which would then allow each space to manage that permission by creating Local Teams matching the name in the restriction. This would allow for easy management, and with proper governance, it can reduce the need for customisation without compromising access control.

Just my initial thoughts
These are just my initial thoughts, and obviously, a proper strategy for the Teams and Groups architecture should be formulated in far greater detail than this. I am sure there are many more ways to improve the Teams functionality and how to rework the black holes that are groups today. These are my suggestions on the subject, but I would love to hear what your thoughts are.
What are your thoughts on how we can better use Teams, and how do you see Groups in the future?

By 💫 Jimi Wikman · December 31, 2025Dec 31

The Atlassian platform has never had any real support for capacity planning, project management, or any form of CapEx activities. This is because the Atlassian platform has always been closely connected to Agile, and as such, they have always focused bottom up with the teams in focus. At one point, they had a very, very basic function for individual time allocation in what we now call Plans, but that was removed several years ago. Now that Atlassian is once again looking into individual capacity, it seems that they are doing it the wrong way again...

The current approach from Atlassian
It is a little difficult to understand how Atlassian is approaching these things since they do not have a unified approach, as I see it. There is no real portfolio app in the Atlassian platform, even if both Plans and Align are trying to fill some gaps (but once again from the wrong perspective, in my opinion). People are split into multiple products (users, groups, teams...), and you have time in the form of time reporting and estimations, but as these are available in any form of values and not just time...
It is a mess.
It seems that the Jira team has its own ideas on capacity planning, and as often happens when you start bottom up, it is designed not from a budget perspective, but from a work assignment perspective. As you can see from the post in the Atlassian Community, this is a Jira space-focused approach, which makes no sense as Atlassian is focusing heavily on the Strategy collection, where this has no connection, as I understand it.

From my perspective, this has nothing to do with capacity, as this view, to me, is nothing more than a fancy way to show ASSIGNMENT. Not only are the values connected to an execution task, but they are also only showing assignment in this Jira space. This has nothing to do with capacity, and I can not for the life of me see how this will translate into anything useful across the organisation?
I have no idea what this has to do with capacity planning, but anytime I see words like "empowers teams", I know this comes from the wrong perspective.
Capacity planning is not a team-based activity only; it is mostly used in higher levels of the organisation to ensure investment projects can be properly funded and to report costs on those projects. I have led several projects, and I have never had any issues planning work based on the actual availability of my team or teams. This is a non-issue if you know what you are doing as a team lead or project manager.
What you need, which is severely missing in the Atlassian platform, and what we should have in the Strategy Collection, is global capacity planning and capacity reporting so we can manage project costs and do vendor management.
This solution is, in my opinion, not capacity planning, and to be honest, this feels more like a control tool than a capacity planning tool. You already have estimations, and Plans can assign work based on those values. The problem is that most teams can't estimate these days, so any form of planning based on bad data is just a waste of time... but that is a topic for another time.

What are my suggestions to get Capacity Planning in the Atlassian Platform?
The first thing I would do if I were working for Atlassian and was in charge of the Strategy Collection was to break down a few architectural core functions.
User - We have the User object defined fine, I think.
Team - One Team object in all apps. We are getting there, I think.
Budget - Does not exist today, and it needs to be defined as a new object type.
Capacity - Does not exist today, and it needs to be defined as a new object type.
If we start with this very simple structure, then we can start to define capacity and what we need to use it for.

What is capacity?
Capacity is not a very complicated concept. In relation to time, it is simply the available time. Nothing more, nothing less. In work related context, we assign capacity to individuals to represent the available time that the individual can work. For example, I would have a capacity of 8 hours daily as part of my full-time employment. This can then be used to plan work where the estimated time to produce something is matched against my time capacity.
Capacity has absolutely nothing to do with tasks or what work is actually being done; it is just the capacity an individual has available for work.
It is very simple.

What do we use Capacity for?
How we use capacity depends on what format the work is being done in, but in general, we need capacity for the following reasons:
Delivery Planning - we need to be able to anticipate and plan when work will be available to the end users.
Capacity Planning - we need to be able to foresee if key individuals are available and have capacity for future endeavors.
Prioritization - we need to know if the work we are considering has the ROI we desire, so we can prioritize work based on capacity and estimation against the generated value (often in multiple time spans)
Reporting Cost - we need to be able to report cost in projects and initiatives, which is based on the actual individual cost for everyone working in the project or initiative.
Vendor Management - we need to be able to foresee when we might need to contract vendors if our own workforce does not have the required capacity.
As you can probably tell, capacity is used for all forms of planning. In fact, you can't plan anything without knowing the capacity of individuals. This is why the Atlassian platform has always struggled to be a project management tool, as it lacks two of the three corners of the project triangle: Cost and Time. Yes, I know we have estimations, which is time, but without capacity, that value is actually useless. The only value we have in the Atlassian platform is the task execution times, which are NOT the same as the project times, unless you have tasks for everything in Jira (I know some teams that actually do this!), or you add time for things like meetings that eat up a lot of invisible time.

How would I set this up in the Atlassian Platform?
To use Capacity properly, I would set this up in two ways. The first would be on the user profile, which I think should be in Talent. There, a user's base capacity is defined based on their employment and their local calendar to fix their days off. In Talent, you should also have vacations and other absences, so the global capacity is owned by Talent. This is also where the users' salaries, or contractual costs, are set, connected to contracts that are in turn connected to a budget or investment.
Then I would create a new app for Budget and Portfolio management.
In this app, which should replace the current Projects feature that used to sit in Atlas, which is now in Home in a weird way, is where all the money in the organization is handled. In this app, I would define two basic objects.
Budget (OpEx) - for annual budgets that we use for continuous deliveries. This is what most teams and products work with daily.
Investment (CapEx) - this is for investment projects that have their own budgets with their own cadence, often handled across budgets in the organisation.
With these two objects, I can now assign a user to one or multiple budgets and/or investments. Each assignment would have a Capacity for that individual assigned to the budget or investment. As we would get the cost for the capacity of each individual and we would have access to all capacity assignments, we can easily manage budgets and align estimations towards planning in real time.
THIS is what capacity planning is all about.
On one hand, I can easily manage people on their user profiles in Talent if I have people management responsibilities. I can easily manage my budget if I have budget responsibility, and I can get the exact cost of work being done simply through estimation and an assignee. If I run a project, I can easily get financial information in the project, and I can instantly see the impact if someone is sick or leaves the project in both time and cost metrics.
At all times, anyone with access can see if a user is overallocated, and if you add functionality like skills, multi-assignment impact (if you work on multiple things at once), and if you have indicators for mentoring that cost time if you have new people in the team, and so on, then you will get very accurate predictions in real time.
That is assuming people learn how to estimate, and of course, if they log things properly in the tools... but that is again another topic.

It is time for a holistic approach to strategy in the Atlassian platform
As much as I love that Atlassian is even looking into individual capacity after 20+ years of ignoring it, I feel that they are missing a huge opportunity here. It does not require a ton of effort to move people from their Excel sheets or steal them from horrible Microsoft PM tools, but Atlassian has to get out of their teams-first mentality and start looking at the organisation first with a holistic approach.

If the organisation is doing well, so will the teams. If the teams fragment the organisation, everyone suffers.
Strategy is a crucial part of the Atlassian platform because it will not be the success it needs to be as a task management platform alone. There are far too many strong competitors in that segment, and as a serious work platform, it has to have a holistic approach to work in all organisational types. If Atlassian makes the wrong move today, I fear they will spend 10 years trying to rework what they build today to get on the correct path...
Strategy is where work begins, not in the tasks.
--
Video on this topic.

By 💫 Jimi Wikman · September 27, 2025Sep 27

If you work in the IT industry, or similar industries, you probably have struggled with project management. Not only to execute them, but also how to define them to the customers when drafting contracts and work breakdown structures (wbs). I see this all the time, and the core reason is a misunderstanding on what a project is and when something is NOT a project. The second problem I see is that people treat everything the same in terms of responsibilities and execution, which causes a lot of problems on both sides.
Projects and initiatives are NOT the same.
If you do not understand the difference between an initiative and a project, then I suggest you start by checking out this video.
https://www.youtube.com/watch?v=L8NqP8RBYOM

3 different types of contracts
In general, we can define contract types in three categories: Fixed Price, Time and material and timeboxed. You might have different names for these, but these are the three common types of contracts and collaboration forms for projects. Let us break these down and see how they differ and then how you work with them.

Fixed Price Contract
Risk: Supplier
Success Rate: Abyssmal
Cost: Very high
A fixed priced project is a classic contract type where you define the work to be done, the time it should take and how much it should cost. This is where you get that typical Iron Triangle that all projects have. This is a difficult project form for both parties, as it demands that the scope is defined so accurate estimations can be made. As we all know, this is very rarely done, and instead people slap the Agile label on it to avoid doing the work that must be done for a fixed price project to work. Fixed price projects with an Agile label are MOD (March of death) projects, and they are pretty much guaranteed to fail.
The only way a fixed price project can work is if the three points of the triangle are well-defined. This means that for most fixed price project you should have a discovery project first to define the requirements. The more time spent on defining the scope, the more likely you are to succeed with the project. That is, assuming that the estimations are done by someone who understand how to estimate. Estimation is a dying art, and most teams don't know how to make actual estimations after decades of dysfunctional estimations using story points or just making numbers up with no learning as part of their way of working.
A fixed price project has to be limited in scope and the larger the project, the lower the chances of success become. I have successfully delivered projects between 9 months and a year in scope, but that is a lot of work as when you have projects of that length and scope, then there will be a lot of changes to handle. Anything above a year you will need to add extra time for as the amount of changes will most likely affect the project.
This brings me to the crucial part for fixed price projects, and that is that you MUST have a well-defined change process that you follow. Your team must also understand the business aspect of the project, and that is something not a lot of teams that know how to do. Every single change to the defined scope have to be carefully measured and documented. Any change resulting in an extension of time, scope or cost must go through a change board and the new impact must be accepted by both parties.
This is a very documentation heavy process, and it is frustrating for everyone involved as this slow things down significantly due to the change management process that must be dealt with.
The fixed price contract put the responsibility and the risk of the delivery on the supplier. It is their responsibility to define the contract so they do not get into trouble financially, and that is always very difficult to do. Most customers are also very bad at defining the scope and risk, so many customers lose money over a fixed price project, or end up in a long and tiresome legal dispute over contracts.
Because of the high risk and change heavy process, most customers will have a significantly higher price for a fixed price project. While it may look good on paper for the customer, then result is usually a much higher price tag and broken deadlines that can be many times longer than first expected.
I do not recommend fixed price projects unless you do the discovery and both the customer and supplier are well experienced in estimations and risk management, with 80-90% success rate over dozens of fixed price projects. You can never have a fixed price project using Agile processes, as these require project management using ways of working like Prince2.
Fixed price projects should ALWAYS have a project manager full-time on the suppliers side and a steering group connected to the project on the customers side.

Time and Material
Risk: Customer
Success Rate: High
Cost: Normal
Time and material is the opposite of a fixed price project. In a time and material project, you will not define the scope, but the cost and length of engagement. This put a lot of responsibility on the customer as they have to know what they need so they can direct the supplier to whatever value they need. Sadly, many organizations do not have the competence or experience to do this and while all deliveries are made, the customer doesn't feel that they get the full value for their money.
What is usually a good idea if this is the case is to do a discovery before the project and define the business needs, and star to define requirements before the delivery project. It is also often a good idea to have an external part helping with this, or even the supplier. The reason for this is that internally there are often implicit requirements because people know how things work. If you bring in external help for this, then they will not have this implicit knowledge, and they will ask the questions needed to deliver later on.
Unlike fixed price projects that should never use Agile processes, they are a great choice for a Time and Material project. Using an Agile process for Time and Material will allow for quick changes when new or better value is discovered. As Time and Material require less formal change management and instead rely on communication as changes occur, this will speed up value creation and make things easier and less frustrated in times of formality (red tape).
As will all things related to Agile, it requires structure though, so the benefits of agility are not countered with a chaotic ad-hoc approach.
From a supplier's perspective, this is almost always the preferred contract type, as no responsibility or risk fall on them. From the customers side this is not so well liked and if they agree to it or not will depend heavily on their trust in their own capabilities to lead a project to create the value they wish to have. It also requires trust in the supplier, and this can sometimes be hard to achieve, especially if you are just starting out.
Because the risk is all on the customers side, prices are generally lower for time and material projects. While it can look terrifying from the customer side, this is by far the most beneficial type of contract for them, assuming they can manage the project from their side.
For most cases this is my recommended contract form as it provides the greatest value to the customer and with proper preparations and in some cases external help, it has the lowest risk of failure.

Timeboxed
Risk: Customer
Success Rate: Unknown
Cost: Low
Timeboxed is similar to Time and Material, but rather than having defined deliveries, a timeboxed contract just defined the time and cost and not the outcome. This is common for design projects, for example, or for R&D and exploration project where the value is not known, but best effort is made within an allocated time. This is also the type of contract you would use for staffing, where you hire a person to help with certain tasks like support or configurations as part of the customer's team.
This kind of project do not execute based on a defined value, but from a hypothesis. This means that value can actually sometimes not be generated, and the entire time can result in nothing more than a learning experience. This is a common contract type when you work with conversion rate optimization (CRO) or when you prototype new services or products in a Research and development (R&D) setting. Sometimes you strike gold, sometimes you strike coal.
From a customer's perspective, this type of contract depends entirely on the customer's ability to direct and provide feedback to the customer. From a supplier's perspective, there is no risk involved here, beyond perhaps disputes of competence and experience.
For staffing and creative work with unknown value, this is the only contract type I would recommend.

Most Common mistake - Fixed Price handled as Time & Material
The absolute most common mistake I see is to use a Fixed Price project and trying to work as it is a Time and Material project. I would say 80% of all failed projects are because of this mistake. Often I see that customers slap that Agile stamp on the project as a way to avoid defining the scope and many suppliers go along with it as they know that means that the project will never be done in time. While that will cause conflict, the suppliers will make a lot more money from the customer's inability to define requirements. I don't say that all suppliers think this way, but many do. Sadly many customers have a similar agenda and they will purposely fail projects to get better pricing long term.
Make sure that if you have a Fixed Price contract that you have:
A Project Manager on Suppliers side
A Project Management process like Prince2 (NEVER Agile!!!)
A Defined Change process
A Steering Committee on the Customers side
A well-defined Scope with realistic estimates based on actual risks.
If you don't have this, then you are just marching towards failure...

Choose the correct contract type for the correct project type
The main goal when starting to collaborate with a new customer, or with a new supplier is to be open with what type of need there is to be delivered. As a customer be open if you are aware then your organization are not strong in project management or requiremement management so the supplier can take that into accout. If you as a customer need help with these two critical disciplines, then ask the supplier for help, or hire someone external to help out with this.
Trying to hide competence or experience on either side is just going to errode trust and make collaboration more difficult. This leads to loss of value on both sides, regardless how smart you think you are playing the other part.
Work smart and long term to build relations is always the better deal than trying to F people over for short term financial gain...
So when you decide on a contract form here is a short check list for you.
Customer Questions:
Do you know what you want and have you defined those in requirements?
Do you know how to work with a change process for scope changes?
Do you have a group of stakeholders that can guide and hold the supplier accountable?
Do you have someone that can lead the project and work with the changes that may come up?
Do you work according to a project management process or Agile processes?
If the answer is Yes to 1-4 and you work according to a project management process, then you can go for a Fixed Price contract. Otherwise you should go for Time and Material. Anytime the value created is unknown in a R&D, design or discovery setting then you always go for Timboxed contracts. Timeboxed is also the only choice for staffing.

By 💫 Jimi Wikman · September 10, 2025Sep 10

And so it came, the official announcement that Atlassian is putting Jira Data Center, Confluence Data Center and Jira Service Management Data Center to rest permanently on March 28, 2029. It is not a surprise as we have suspected that this would happen for a few years now, but the announcement still hit like a virtual truck in the Atlassian community. This is especially true for Marketplace app companies that are now seeing their hard work turn to ash.

What do we know about Atlassian Data Center end of life?
The announcement was made on September 8th, 2025 on all channels. There was a blog post about this shift that claims that 99% of all Atlassian customers are in the cloud, which is probably technically true, but not really a fair comparison when you bring in all the free products people are using to test things. This blog post is pretty much a sales post with little to no explanation on why this shift is taking place other than "the cloud is awesome". It lists some resources and promises to support data center customers to move to cloud.
There was also a blog post in the developer blog, which was very brief with a short and vague motivation to why this is happening. This was accompanied by an announcement in the developer's forum, which is a little more informative, I think.
In short, the information provides the following:
December 16, 2025 - new DC apps can no longer be submitted to the Marketplace.
March 30, 2026 - DC license sales and app sales will end for new customers.
March 30, 2028 - DC license expansions, sales, and app sales will end for existing customers.
March 30, 2029 - DC subscriptions will expire, and the environment will reach end of life.

Exceptions may be given?
*For certain Data Center customers with unique circumstances, we’re committed to offering extended maintenance by exception after March 28, 2029, ensuring you have the flexibility and support you need for a successful transformation.

Bitbucket getting special treatment
For those of you that use Bitbucket Data Center, you will have a little bit of exceptions to make this shift less painful. While this is good news for Bitbucket customers, you should expect that Bitbucket Data Center will be removed shortly as well.
Exceptions and dual licensing for Bitbucket users
For Bitbucket Data Center customers, we understand your source code is particularly sensitive. To give you maximum flexibility, we’re launching a new license option that will give you access to both Bitbucket Data Center and Bitbucket Cloud, allowing you to operate in whichever environment your business prefers beyond March 2029. In addition, Bitbucket Data Center apps will continue to be sold through the Marketplace.

Atlassian services to help you transition
Atlassian are adding services for those that want to transition to the cloud. These range from self-help for small organizations and two Atlassian led programs to basically brute force your transition to the cloud.
For customers with fewer than 1000 users, our dedicated self-service tools are designed to make upgrading as smooth as possible.

For organizations with more than 1,000 users, our new complimentary Atlassian FastShift Program offers a strategic partnership, dramatically accelerating timelines (from 12–16 months to just 2–6 months).

For customers with over 5,000 users, Atlassian’s Solution Design Acceleration program will support the most complex use cases with a dedicated partnership to plan and execute a transformation aligned to your company’s business objectives.

These programs are by no means bad and if you have a relatively clean Data Center installation, and you are dedicated to move to the cloud, then take advantage of them as soon as possible. If you have a data center solution that is messy, and you do not have your integrations in order, then I would carefully consider if a migration is the right call.
In many cases, it is a better option to not migrate, but to start fresh on Cloud and just migrate what you need for compliance reasons.
Regardless of what option you choose, you will need to dedicate a lot of time from your organization for change management. From a technical perspective, the best option is to start fresh and not migrate, but that put a lot of effort on the change management side as you need to do a lot of work to redefine ways of working. If you on the other hand just migrate the data, then you will have less effort on the organization, but you will probably suffer from an unstable platform that you will have to spend years cleaning up.
The best option is always to contact Atlassian and a partner to get a review of your platform so you can take proper decisions based on what is best for your organization, both short term and long term.

If you want my help, then you can reach out to me here:
https://jimiwikmanofficial.atlassian.net/servicedesk/customer/portal/4/create/206

I can't move to cloud, what are my options?
This is a common concern and while there is light at the end of the tunnel with two new options for moving to cloud in the form of Atlassian Government Cloud and Atlassian Isolated Cloud, they are not yet very well advertised or presented. This means that you may have options that fit your organization in those two new options, but it can also be that you may have no options in those offers that fit the need of your organization.
Regardless of where you stand, you should have a conversation with Atlassian about your options. If moving to the new cloud options is not a valid path for you, then the next step would be to ask what the future holds for your Data Center platform. Can you keep the platform after march 28th, 2029, or will it become read only as is the case today? Atlassian has not, to my knowledge, addressed that topic yet, so you should ask them and see what the options are there.
If neither option is available, then your next option is to migrate to a new tool. This is no easy task and your best option here is a discuss options with a partner that both are experts in Atlassian tools, ways of working, integrations and of course multiple alternative tools that could be suitable as a replacement.
I am fortunate to work for an organization that has this exact expertise that also exist internationally, so feel free to reach out to me or Sii located in your country if you want our help with such a conversation.

3 years is not as long as you might think
March 28, 2029, might seem like a very distant date with more than 3 years to complete a migration to the cloud, or find new alternatives. In reality though, it is not that much time as a normal migration takes 6-12+ months and if you want to do a green field shift, then it can take even longer. The time required to technically move data and configurations however is the smallest change for most organizations.
What most companies do not realize is that migrating from data center to cloud is not just a massive shift in technology, but much more so in the ways of working. Change management is very important, and many organizations will have to change many internal processes as they transition from a fairly featureless data center setup with few and easily controlled changes to a frantic cloud setup that is completely different in functionality and UI.
The Atlassian Cloud platform also offers several defined processes like the Incident process and with the massive shift for Confluence in the last few years it now offers a ton of new ways of working. In short, it is very likely that whatever processes, or lack thereof, that you have today, will benefit greatly from a rework when you move to the cloud. This is a nontechnical shift that many organizations fail to recognize, and as a result their cloud usage is less effective than it can be.
Many organizations are also stuck with old onion setups with layers upon layers of old and forgotten configurations that have never been documented. Security is often poor, with no control over the APIs or scripts connecting to them. This means a lot of time will be spent trying to clean up and prepare a data center platform to even be able to migrate. Since the platform is in use, this can mean years of cleaning, or you just have to push everything and deal with the fallout after the migration. That tend to lead to performance issues and data issues and a lot of frustration trying to untangle decades of neglect and mismanagement due to lack of authority and strategies.
The road to hell is paved with good intentions, and that is clearly visible in many old data center platforms.
So don't wait too long because the longer you wait, the harder it will be to find experienced partners that can guide you through your options and help to move to cloud, or to find new alternatives to replace your current Atlassian platform with.

The shortage of Partners
While there are many partners around the world, not many have the capacity required to handle this big shift as there will be many requests coming in, especially around 2027. While migrations are not technically very complicated, the state of many data center platforms add a lot of complexity to the process. This means that a lot of the partners will have many of their senior consultants locked up with migrations and cleaning activities, and this can cause a bit of a problem to find good partners to collaborate with.
It is also not just the migration itself that require good partners, but the planning also benefit greatly from having experienced partners, preferably close by so you can have workshops in person. While working on remote is great, sometimes you need to sit in the same room and use a physical whiteboard to be most efficient, and this is where your local partners really will make a difference. You can check what partners are available in your area through the Atlassian Partner Directory.

If you are located in Sweden and especially if you are located in Stockholm, then you can reach out to me for assistance with planning and executing your move to the cloud in the best way possible, both financially, technically and of course based on what your organization has the capacity for.
If you want my help, then you can reach out to me here:
https://jimiwikmanofficial.atlassian.net/servicedesk/customer/portal/4/create/206

Don't just focus on the downside, consider the upside
When big shifts like this happens, especially when you get forced to make changes you had no planned for or hav budget for, then of course you will get annoyed and frustrated. It is a natural reaction to change and in our hectic times where finding funds and time make big changes like this is like climbing a mountain backwards with no qequipment, there are upsides to this.
Over time all systems become bogged down with technical debth and bad decisons leading to unnecessary complexity and often performance issues. Many organizations suffer from fragmentation of work where teams have built their own silos that are now harming the organization and costing a lot of money every day.
Making a massive change to a new platform can provide the opportunity many organizations need to get some of those things out of the way by establishing strategies and governance that are aimed towards a secure, legally compliant and useable solution for the whole organization, not just some of it.
This is by no means an easy task, but if you are struggling from bad practices and bad technical decisions costing your organization valuable time, or perhaps even causing micromanagment, lack of visibility or perhaps even making valuable deliveries difficult, then this can be a great opportunity for an organization reboot.
Many, many, many data center platforms are built like patchworks when it comes to integrations and reporting, looking like spiderwebs of connections to systems that are poorly documented, if at all. This makes this a great opportunity to restructure and build proper strategies so you take advantage of the new security features in Cloud and so you can define non functional requirement for data in all projects so you can get accurate, reliable and above all, valuable reporting.
I have seen several cases where organizations can reduce a lot of cost just because their old setups no longer have to rely on marketplace apps as the new functionality in Cloud match, or even surpase them. You can also consider the cost and effort of hosting, monitoring and of course upgrading both the Atlassian platform and all the surrounding systems.
There are many, many things that add value when moving from Data Center to Cloud and if you are interested in learning more then just reach out to Atlassian, a partner and if you want to book some time with me, then just contact me here:
https://jimiwikmanofficial.atlassian.net/servicedesk/customer/portal/4/create/206

We are in for a big shift and I am ready, are you?

By 💫 Jimi Wikman · June 23, 2025Jun 23

After almost a decade of complaining about the misaligned term "Jira Project" that does not fit what it actually represents, Atlassian FINALLY announced that the term will change to Jira Spaces. I have known about this for a while, but now that it is finally revealed publicly, I can rejoice and celebrate this change fully.
For those of you that don't know what the fuss is about, the term Project has never really fit the work we do in Jira, as the majority of work for most organizations are continuous deliveries and not projects. If you don't know the difference, then I have a video for you here:
As Atlassian introduced Atlas with Goals and Projects, we also got two distinctively different features that caused additional confusion. Here is what Atlassian themselves say about this confusion:

So what is actually changing, and when will this change happen?
As with the other changes to namings, this will be a language change only.
The change to the new Space nomenclature will begin to roll out on:
October 2025
This will be a gradual rollout, so you can probably expect to have it in all Atlassian instances by the end of the year.
I absolutely love this change, how about you?

By 💫 Jimi Wikman · May 29, 2025May 29

Every organization have communication plans. Every team communicate all the time, both internally and externally with those they collaborate. We talk, email, chat and have video calls all day in an endless stream of communication.

Yet we continuously fail in our work.
Even though we praise Agile as the savior to fix the problems, or put project management tools to align and manage things... we still fail.
Projects never get done on time or budget. People still sit frustrated and confused, trying to figure out what to do next, or even how to do the work. We have managers transforming to micromanaging monsters and developers thinking they can carry an entire team of competences on their own.

Yet, we still fail.
We write emails to the point where professional writers look at us with envy. We send entire novels each day on Slack and Teams, and we spend endless house in video calls. We scribble on whiteboards or make fancy graphs in Miro and PowerPoint and we spam everyone on SharePoint and Confluence.

Still we fail.
How is it that even though we communicate so much and still collaboration do not work? Why are we still confused and frustrated, even when we shrink the circles of who we collaborate with to an almost ridiculously small glass bubble of self-isolation?

Because Communication has never been the problem!
Just like you can take the best communicators in the world and put them in the same room for the best possible direct communication, if they speak different languages it will not matter. They will still not be able to understand each other.
This is the problem I see all the time in today's workplace and I feel it getting increasingly problematic as the words we used continuously become diluted and vague.

One of the most common phrases I hear all the time is "you know what I meant". This happens when someone say something using words that mean something completely different, but when it becomes clear that it was the wrong word used, they just brush it off as if the meaning of words is not important and others should know what they meant by intent or telepathy somehow.

Words Matter.
The sole purpose of words to form a language is not so we can fart through our mouths by regurgitating nonsense. It is not to make fancy noises or express melodies, that is what music is for. Words in languages is not for communication, it is for understanding.
When we dilute the use of words and make words confusing, then understanding is reduced. When understanding is reduced then misunderstandings happen and when misunderstandings happen we make mistakes. Mistakes lead to frustration and very often financial or even legal implications at work.

All languages are broken.
No matter what language you choose it is filled with examples that make absolutely no sense logically. These come from social changes where the less intelligent and the lazy people break our language out of ignorance or plain laziness. In some cases they are even done out of pure malice, but I believe this to be a rare occasion.
These examples will then become the norm and for all foreseeable future until it is revoked, this will reduce the understanding we get from our language.

You succeed through understanding.
In many organizations the easy fix is to stop using buzzwords, which are made up words by people that want to sound more important than they are. Use descriptive language rather than made up ones that you find in a process, framework or methodology. Someone with a role that includes Owner for example have the ownership of something and someone that have the word Manager in their role manages something or someone.

Requirement Management is key
Without a shadow of doubt the area where failure happens for almost all companies is that they do not have Requirement Management. This is by far the most crucial area in any organization, no matter the size as this is where strategy is being translated to operational work. If you fail to understand this key breakpoint in your organizational workflow, then you will fail.
Sure, you can work harder and spend more time trying to understand in an ad-hoc setting, but obviously that is wasteful and prone to misunderstandings. I think we have all seem the image where a caveman show a round wheel to the others that push their carts forward on square wheels where they claim that they can't look at the round wheel because they are too busy because they have square wheels.

This is what working without Requirement Management is like.

You know I am right...
I think all of you know that understanding is the key to success because you have seen what happens when understanding fails. You may not agree that requirement management is a key ingredient in that effort, but there are countless examples of projects or assignments that have gone to hell because the requirements and expectations were unclear.
I think you all have seen the Project Management image with different expectations and how a project is perceived and delivered. I think that illustrates this problem quite well.

Use descriptive language and don't be lazy
The way to get around the constant failing is to stop using the wrong words and to define requirements. Do not let processes, methodologies or frameworks define words for you when they make no sense. Don't let the people in your organization make up words and definitions that make any sense either.
Create a glossary and make sure you use that for everything in your organization, including role names, process descriptions and so on. People will still do whatever they like, but at least this way you can point out when what they say is stupid or lazy and avoid fostering generational confusion as we have for the past 50 years or so.

Requirement Management can be many things
Many of you that think of requirement management probably think of nightmarish mega projects that are planned for years and can't be changed. That is not what Requirement Management means though, and it does not matter if you use an Agile framework or a project management methodology. Requirement management still works in all those settings.

Some might argues that defining requirements is pointless because you never know what you are doing If you don't know what you are doing, then you are either working very dysfunctionally in some form of chaotic Ad-hoc setting where you make shit up and throw it on the wall to see what sticks, or you are working with R&D and ideation. In this case you are not working with existing need, you are exploring and experimenting to find new value.
Congratulation, you are working with UX and CRO!

Requirement Management takes too much time
A common argument from teams and organizations that don't do requirement management or don't know how requirement Management works. Similar arguments are made for pair programming or mob programming for example and while the logic suggests that things should take more time, it actually don't.

If you do it right...

If you are struggling to make deadlines or get work done properly, and you think you could use someone to talk to about it, feel free to contact me. I'll happily hop on a chat or meetup for a coffee or lunch to discuss this with you.

By 💫 Jimi Wikman · March 24, 20251 yr

If you spend any time in the ecosystem of work processes, methodologies and frameworks you have undoubtedly encountered people that claim that one way or another is the only way to do things and if you disagree, then you are stupid, uneducated or even evil. These are the fanatics bordering on cultists clinging to one way to rule all ways and there is little point arguing with such people, unless you like me enjoy a bit of an argument just to see what their point of view actually is.
There is of course no one way of doing things.
Just as people are different, so are teams and organizations. Claiming that Agile for example is always the right choice makes no sense as you will always have people that do not work well in Agile settings, whatever they might be. It is equally wrong to claim that we must have strict rules, or structures for how to do things, for the same reason. Some people, teams and organizations thrive in loose structures that allow them to use their creativity and make quick decisions on the fly, while others thrive, or even are required to have more structure and processes in place.
Selecting the right balance is key, but it does not just matter for productivity, it is also very important for health and motivation.

Ad-hoc behavior is harmful for your health
I recently read about a developer that despaired and lost all interest in his work because the workplace was chaotic with a start-stop culture. This is sadly not an uncommon situation and if you have never experienced a start-stop culture, that is when work is constantly started and never get finished because it is being shut down and something else takes its place. This is one of the most detrimental ways of working as it induces a lot of stress in the individuals that are exposed to it.
There are many studies that show that unclear expectations and an unstructured workplace causes stress. Not only will this have negative impacts on the ability to do deep thinking, but it also causes long term ill effects, which can eventually become serious health issues. I have seen more than my fair share of people passing out in meetings, burning out and even being hospitalized after being picked up in an ambulance.
Stress is no joke.
The tricky part about ad-hoc behavior and unstructured work is that every individual have different tolerance levels for stress. For some it will be a slight nuisance, for others cause for frustration and for some it is directly harmful. This is why it is so important to make sure you understand the cost this comes with for your people, your teams and your organization.
Ad-hoc behavior can come from many sources. One source is that the organization is a startup and both financial constraints and the behavior of the founder drive the organization towards ad-hoc. The false pursuit of freedom is another where individuals or teams believes that if they can just get away from the "oppression" of management they can make the world a better place. A third is that an organization is made up of many subdivisions, most commonly due to purchasing multiple other organizations and trying to merge those into a larger whole.
In many organizations having too much ad-hoc behavior and unstructured work will manifest as loss of financial value as people are running without the ability to do deep thinking, sick leave is high as people get sick from stress and a high turnover rate as people leave the stressful workplace.

Red-tape behavior and micromanagement
The opposite side of the coin is where everything is controlled and everything you want to do is tightly controlled in strict processes and rules. Just as ad-hoc behavior causes stress, so do red-tape behavior, but for a different reason. Where ad-hoc behavior cause stress due to unclear expectations, red-tape causes stress because it demands so many blockers that progress crawls to a halt. In many cases it feels like actually getting permission to do something require more work than actually doing something.
Besides stress building up from constantly being held back because of long processes to do anything, micromanagement is also a common symptom. That is because just as red-tape tend to be the result of low trust in the people that work in the organization, that is also why micromanagement exist. It is not uncommon that a company start out as an ad-hoc organization and then transition to a red-tape as the organization loose trust in the chaotic nature of the ad-hoc ways of working.
From my own experience and from talking to other people on the subject there seems to be a correlation between when organizations start to expand on the proxy culture. This is where management is multiplying because the workload is too much and by doing so they create an elaborate number of levels of managers that all act as proxies. The opposite happens when organizations realize that the amount of managers doing nothing but attending meetings and relaying information is an expensive way to operate. This tends to lead to a swing towards ad-hoc again and when trust is lost again we see a raise in the number of middle managers again.
In fact, most organizations continuously vary between these two states and the impact that has depends on how large those swings of the pendulum are. If your organization is stable the pendulum will make small swings and if the organization is volatile, then it will make larger swings. These swings tend to be triggered when an organization has built up enough incompetence, so that trust is eroded. If it is trust in Management, then it will tilt towards ad-hoc and if it is in the teams trust has been lost, then the swing moves towards red-tape and micromanagement.

The impact on "creativity"
While you might think that a restrictive red-tape behavior would strangle any creativity and an ad-hoc behavior would have a positive impact, that is not necessarily true. The devil is in the details and most people do not define what they actually mean with creativity and then confuse brainstorming with creatively making decisions that benefit the organization.
If the purpose of creativity is to come up with as many ideas as possible that you throw out and see what sticks, then ad-hoc is the way to go. It has very little deep thinking and most of what comes out are brain farts, but occasionally something amazing will come of it. It is just a matter of how long your company can survive by paying for the people to throwing shit on the wall until something sticks.
If the purpose of creativity is to come up with ideas that are valuable every time, then you want to go with the red-tape option. It will take forever to find that value, and you will spend an insane about of time to figure out what to do next. You will spend more time in deep thinking and filling out forms than coming up with new ideas, which will put you in the same position and the ad-hoc behavior.

This has nothing to do with your process, methodology or framework.
It does not matter if you are an Agilist swearing that Scrum, Kanban or maybe just an undefined Agile way is the ambrosia of the gods that promises eternal bliss, or if you demand that the world bow to a traditional project management methodology like Price 2 or what we refer to as Waterfall. All of them will work just fine as long as you adjust the way you work based on the people doing the work. In the same way none of them will work if you take them too far and either don't take the people into consideration, or you push things too far towards ad-hoc or red-tape.
At the end of the day it is the work you do, the collaboration and understanding you engage others with and the value you actually generate, regardless of position. Not the buzzwords, not the rituals and not the processes. These are just the guardrails that should help you stay on the path of being good colleagues and employees working together towards a common goal.

The balance is everything
In order to maximize this and get a good work environment that will keep people happy, healthy and creative is to find the balance between ad-hoc and red-tape. This will not sit well with people that are either have very active and chaotic minds, or the people that have very rigid minds that demand structure in all things. These are the people that are the most vocal in the discussions in different forums in my opinion, and they are also the ones that drive the swings of the pendulum when they join organizations
The key towards a balanced organization is to ensure you have enough steering so the organization benefit from it, but enough flexibility so that teams and individuals can be at their best. This is an extremely difficult balance and from my perspective the only way you can achieve this is by looking at the problem from both directions.

Top Down for structure
From a management perspective we need steering and structure on the large scale. A governance model should be put into place where representatives of all disciplines within the organization are represented. This governance group should define the high level processes and the high level requirements. Things like what kind of documentation do we demand, what are the legal requirements that everyone should abide to and so on is on the highest level. Here you have the larger processes for funding projects, how budgets should be defined and so on.
This is also where the discipline specific things should be defined, like for developers we should have documentation standards, legal requirements, standard tech-stack for various type of work, standard tooling and what the developers need as input and what they are expected to have as output towards other discipline groups.
Large brushes, but without going too far into the red-tape behavior. The purpose is to define high level requirements for high level processes.

Bottom Up for creative freedom
With the governance group setting the big stage, the teams focus on how to make their group of individuals work best. Withing the structure provided by the governance team how should the teams work to be as productive as possible. This is where team leaders will be very important as most people have no knowledge or competence in team dynamics or group psychology. This is a crucial skill that the team leader need to have to ensure that we don't get strong willed individuals bullying their way for the team happen.
While the governance group have defined a standard for th whole organization, it is ok for teams to deviate from this if they see that the can do that without compromising the bigger picture and that it is adding value to the team as well as the organization. The same thing goes for things like documentation and requirements where the outcome might be defined in the governance group, but the team can decide how to get there.
At this level the teams meet the requirements from the governance group with details on how they will work towards those goals within those structures.

Leadership is the key, not management
Finding a balance between ad-hoc and red-tape require constant leadership and change management. While managers have their place, their job is not to lead the organization, but to manage the work. In order to do this effectively managers also need to have a good understanding of leadership and change management as their position will grant them a larger overview than the team leaders and a more granular one than the leadership levels or the governance group.
I also think that all teams should learn about leadership and I think many would benefit greatly from things like team dynamics, group psychology and even personality types that I know many are against. Understanding how you and others work in a group and what kind of leadership is required in what state is to me the key to a bottom up approach towards a balanced organization.
Leaders lead the way, managers manage what you already have.
--
So the question is if your organization is a leader,
or are you stuck on the pendulum as it swings,
unable or unwilling to try to make it stop?

By 💫 Jimi Wikman · March 22, 20251 yr

I stumbled upon Playbooks today by accident in my Jira Service Management settings and since I had missed the announcement I was first a bit puzzled. I went into the Release notes in my Admin section and sure enough there it was. No image, no real information and the link to the official documentation is not really providing any reason to look into this any further. Now that it has landed in my Jira Service Management instance though... Oboy, this is amazing!

What are Playbooks in Jira Service Management?
Well, the short answer is that is a combination of a checklist, an instruction and automations in one nice package. It behaves like Automations in that you create steps that can be either instructions or automations. You will find Playbooks in your Jira Service Management project configuration settings below the Automations. From there you will see the existing Playbooks so you can manage them.

The Playbook itself can be setup with some conditions, which are very few at the moment. You can set up conditions based on issue type, request type and groups at the moment, and it would be great to also have other choices like custom field values and perhaps the check for Major Incident.

When you create the steps you can choose between Instructional and Automations. The Instructional option is quite straight forward where you will add information in a rich text editor that will assist the agent. There is a limit of 500 characters at the moment, which I assume is because they are just rolling things out as an MVP. In the future they probably need to change this as 500 characters is not a lot. You can of course add links to longer documentation and for now adding a link will just output the link so you can't use the internal linking feature to show pills or full embeds.

The Automation option allows you to add any automation in scope for the project. I think it will only allow you to pick the automations that have a manual trigger though. This makes sense since it will output a button for the agent to click, so other types of triggers does not make a lot of sense.

Once you have created the Playbook then all you have to do is to save it. If you have set up any conditions then those will determine when the Playbook will appear, but you can also add the Playbooks manually in the tickets. In your tickets you will see a new section for Playbooks marked with the New label.

Once you click to expand the Playbooks area you will see a list of Playbooks and when you open a Playbook you will see the steps. Each step will display the instructions and if it is not an automation, then you will see a button that says "Mark as done". For automations the button will instead say "Run". This is a great way to keep track of what you have done and a new way to add a checklist of things that you need to do for certain tickets.

Once you have completed the activities and clicked the buttons your actions will be saved in the execution log. The execution log is showing up both in the Playbook itself and in the execution log in the Playbook session of your project configurations. For now, it seems that if you press the button by accident, there is no way to revert that action!

Once the Playbook has been run you will find the result in the execution logs where you can see the result, who did what and when.

Are Playbooks in Jira Service Management useful?
Even though this is still very bare bone, and we need some additional love for it, I would say this will solve a ton of problems that people currently are struggling with. I had a conversation with a customer this week about a scenario just like this, and it is one I have had many, many times before.
This is very useful for incident management of course, but also for service requests and basically any situation where you want to ensure things are done in the correct order and to make automations a natural part of a checklist.
To me, this is one of the sneakiest and most awesome feature I have seen in a while!
Great work Atlassian!

By 💫 Jimi Wikman · March 16, 20251 yr

Back in September last year Atlassian announced the shift from the old term "Issue" to something more appropriate. This caused a lot of opinions and Atlassian put out a poll to see what word their vocal users liked the most. This was followed by an announcement in November 2024 where the term Work was announced to replace Issue. It is no understatement that people lost it a bit over this and when the rollout was announced in March 2024 the comments section lit up quite a bit.

But what is the big fuss about, and why are people upset?

The history of Issues in Jira
Let us first start with the background on why we even have a word like "issue" in Jira to begin with. This starts back in 2002 when Jira was first released. It was released as a bug tracker and when you are working with bugs, it makes sense to refer to the work you are doing as "issues". As Jira evolved, perhaps most noticeable with the purchase of GreenHopper in 2009. This was an Agile plugin developed by Pyxis Technologies that had release planning, task management and burn down charts.
This changed Jira from a bug tracker to a more useful product capable of tracking work rather than just bugs.
As Jira continued to evolve with new functionality and new ways to use Jira, the terminology did not change with it. Work that was done remained named Issues and over time this has strangely become normal terminology among the users that have been using Jira for a while. For new users however, the term has always been confusing and many of us that has been working with Jira for a while have heard people questioning why this term is used to describe work.

The big Jira shift - Teams '24
In 2024 at Teams '24 in Las Vegas Atlassian announced the biggest change in the history of Atlassian. One of the two founders, Scott Farquhar, stepped down as co-CEO of Atlassian and the other major announcement was a drastic change of Jira as a product. For more than two decades Jira has been closely connected to development, which as even in the name up until the big change in 2024.
On stage Mike Cannon-Brookes announced that Jira Software was dead. There were no more software product in the Atlassian product line, but instead a new product called just Jira was born. This new Jira seemed to be the same, but with new functionality such as Goals and Projects taken from Atlas, another Atlassian product and a complete merge of Jira Work Management, making the new Jira less of a development tool, but now a more capable multipurpose tool to fit many different ways of working.
Massive changes to navigation and functionality were announced, and it was clear that Atlassian was moving into a new era.

The New Jira and the new terminology
For a year we have watched Atlassian change their product line by merging products together to more powerful products, but also to change the language and the way we use the tools through massive changes to the User Interface of the products. We first got the ability to rename the abused and confusing Epic to anything we want globally in our instances. This fit perfectly with the ability to extend the work item hierarchies so we can build parent child relations above the old Epic level.
Now we are getting the next terminology change, and it makes perfect sense that a word associated with problems and faults no longer should be the default wording for work, which is now any form of work. In the vision I think Atlassian is working towards with a more generic tool that can be used for any number of situations, they needed to address this very old and very bad terminology issue.
It is not something I think they do in isolation, but as a part of a far bigger strategy to reposition Atlassian and their products, which started long before the big announcement in 2024.

Work as the new collective term for all items tracked in Jira
Work as a term for what you do in Jira makes perfect sense for most people. There are people that are not actually tracking work and for them this might be weird of course. Those people are very few though and considering that millions of users have been referring to work as an Issue for two decades, I think that is a tradeoff Atlassian has no problem making. While you could have made an argument for using other terms like Task, that does not fit the overall vision of Jira I think because it is a tool used to track work and if you have tasks that are not actually work, then maybe you are better off using another tool?
Or you can just ignore the term and do what everyone have been doing for the past 20 years when we referred to work as issues.

What is actually changing?
There is an impressive amount of confusion around this change, which is actually much smaller than most people think. In the comments in the announcements you can see that people don't even read the information, and they ask the same questions as has already been asked and answered multiple times.
So let us iron out what the changes actually mean.
This is JUST a language change.
This should be obvious, but a lot of users seem to miss this. This change will replace any text you currently see using the term "issue". That means that it will change the language in the UI when users create work items, when you see listings of work items and so on. You will see this in all configuration areas for terms like Issue Types and Issue Type Hierarchy.

This will NOT change your Issue types or Request Types
Your tasks, your stories and your custom Issue types or Request Types will NOT be changed. These are data objects you have named and whatever you name them will NOT be affected by this.

This will NOT impact the API or Automations
All existing references to Issue will remain in both the API's and the automations.

This will NOT impact JQL, Filters or Boards
JQL clauses and any existing filters/saved searches will continue to support the term 'issue' to maintain backward compatibility. We'll introduce a new alias for 'work' to support the terminology updates.

In short, you can expect that everything will work just as it does today for all aspects of your Jira products. The change will be in language only and while that can absolutely confuse your users and make you a bit lost in the configurations before you get used to it, technically nothing will change.
For now.

People are upset about changing Issue to Work in Jira
It is both sad and a bit funny to see people's objections to this change as they are clear signs of personal preference and have little basis in actual logic. It reminds me a bit of the hypothetical experiment where a number of monkeys was conditioned over time to prevent anyone from climbing a stepladder to get the banana. If you have not seen it, you can see it here: https://www.youtube.com/watch?v=WkT0BtfOB-M
What most people in the comments are actually complaining about is that they don't want to change. Not that the change itself is wrong or bad, with any form of logic as to why, other than their own preference or what they are accustomed to. This is perfectly normal because humans do not respond well to change in any situation and when you change terminology in a working tool you use every day, then that have a pretty big impact. I think most of the people complaining are also suffering from stress so they don't really have time for new changes like this.
As this rolls out however I think people will realize that this change is not as big as they think. People still will call work items in their own way, and we will hear people telling others to "create a Jira" or "create a ticket" or some variations of those after this change anyway. Considering how many have complained that it more complicated to ask someone to create a "work" than an "issue" says a lot on how some people refer to their work in Jira.
I would suggest to start using the name of the work items you have actually created instead.
"Can you create an incident" or "Can you create a story" makes a lot more sense to me, plus you don't have to answer the follow-up question that you inevitably will get if you refer to the term and not the work "Which issue/Jira should I pick?". But, use whatever language you find to provide the best clarity of what to create and how to refer to your work.
As long as everyone understand each other, then you should be good.

Prev
1
2
3
4
5
6
Next
Last page

My Articles

True Agility comes from structure and clarity

The Agile Manifesto - 25 years later

Teams vs Groups in the Atlassian platform - how can we improve?

Capacity planning and capacity reporting in the Atlassian platform

How to manage projects the right way based on contract types

Atlassian Data Center is officially ending on March 28, 2029

Atlassian renames Jira Project to Jira Spaces

Communication has never been the solution, understanding is what we need.

The balance between Chaos and Red tape - the cost of failure is very high

Playbooks in Jira Service Management add much needed support for Agents

The renaming of Issues and making work as the new collective term for all items tracked in Jira

Categories

My Articles Filters

My Latest Articles

True Agility comes from structure and clarity

The Agile Manifesto - 25 years later

Teams vs Groups in the Atlassian platform - how can we improve?

Capacity planning and capacity reporting in the Atlassian platform

How to manage projects the right way based on contract types

Latest Community articles

Affordable Linux Dedicated Servers for Businesses | High Performance

Dedicated & Cloud Server Hosting Experts | 24x7 Support

Benefits of Using ReactJS for Your Web Development Project

Kotlin Vs. Java: Which is Best for Developing Android Apps?

CodeLobster IDE - free PHP, HTML, CSS, JavaScript / TypeScript editor

Who's Online 0 Members, 0 Anonymous, 14 Guests (See full list)

Account

Navigation

Search

Configure browser push notifications

Chrome (Android)

Chrome (Desktop)

Safari (iOS 16.4+)

Safari (macOS)

Edge (Android)

Edge (Desktop)

Firefox (Android)

Firefox (Desktop)