My Articles Community Articles 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.

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.

Ways of Working,

By 💫 Jimi Wikman in Ways of working · September 27Sep 27

0 comments
240 views

Atlassian,

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 in Atlassian · September 10Sep 10

0 comments
542 views

Atlassian, Jira, Jira Service Management, Jira Product Discovery,

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 in Atlassian · June 23Jun 23

0 comments
1,219 views

Requirements, Ways of Working,

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 in Ways of working · May 29May 29

0 comments
787 views

Psychology, Ways of Working,

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 in Ways of working · March 24Mar 24

0 comments
1,310 views

Jira Service Management, Playbooks,

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 in Atlassian · March 22Mar 22

0 comments
2,096 views

Jira, Jira Service Management,

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.

By 💫 Jimi Wikman in Atlassian · March 16Mar 16

2 comments
2,258 views

Atlassian, Confluence, Jira, Jira Service Management, Jira Product Discovery,

As we are moving into March, more users will experience the new Atlassian navigation for the first time. Some of them will love it, some of them will hate it. Regardless how they feel, they have to get used to it because it is the new standard that we will see in all Atlassian products. Considering that Atlassian have already tried a sidebar main navigation before, and it was quickly changed because it was universally hated, why are Atlassian rolling this out again?
The answer can be found in this YouTube clip where Kristin Perchal go through the reasoning. This is a recap I believe from the Webinar (hidden behind a sign-up form) called Unpacking the new Atlassian global navigation experience. Kristin is doing a great presentation to explain the reasoning, so let us break them down.

The Problem the new Atlassian navigation need to solve
The Atlassian Mission "Unleash the potential of every team" and the fact that a lot of user have complained that finding things in the Atlassian products is a problem. In fact measurements show that 40% of the time spent by knowledge seekers are spent finding information in the products. The phrasing is interesting because I doubt anyone working in the tools spend 40% of their time trying to find things, so I assume what is meant here is that we spend more time finding things when we are looking for it than the fact that the navigation is bad. This has more to do with how well the users understand and know the products.
33% of the negative CSAT feedback relates to navigation and findability. Again, this goes more towards understanding the products, but also to a more interesting problem: Inconsistency.

Inconsistency in the Atlassian products
"Our product portfolio has expanded and each of the products have evolved separately, resulting in inconsistent navigation experiences across products."
This is a very true statement, and it is not just affecting the navigation and findability, but also impact the language and functionality. Teams is one such area as well as the use of the word Epic in different tools. I think this is by far the most important reason for changing the navigation and for doing so across multiple products. We also see Atlassian absorbing external platforms like Opsgenie into the standard products, which also help align consistency and increase the value of core Atlassian products.
I like that Atlassian is focusing on this and that they are working on language and functionality, even though I think their internal organization and their commitment to Agile methodologies are challenging for them. I look forward to more initiatives like this to remove bad language and align products and functionality consistently across all products.

Industry behaviors and standards in Atlassian navigation
"Our navigation lacks modern behaviors and standards that our competitors provide like
Reduced cognitive load aka clutter
Improved efficiency in completion of tasks
Alignment to other common patterns to reduce the need to re-learn behavior/pattern when you use Atlassian tools"
I am not sure these statements are true because the clutter is very much there and the readability has not improved, especially with the light font and iconography that provide little guidance for the eye. I also do not think the findability improves much unless people were having problems finding functions due to the navigation itself, which is not my experience after teaching thousands of users. The problem is naming and understanding the tool, not to find where the link to a function is located, but that is a topic for another time.

Scalability in the Atlassian navigation
"Consistent design and familiar industry patterns across our product suite that support the evolution of bringing our products closer together and service more team's use cases than ever before."
No matter if we like the design or not, it is a good thing to align into a consistent design pattern. If the future show that this is not the right way forward so we see a repeat of the Blue sidebar navigation in 2018, then a change will be done across all products, and it will be consistent. This is very good.
Will the sidebar design scale better than the top navigation? Yes, I believe it will, even if it will be a challenge to keep in from cluttering. I am curious how they will tackle the secondary navigation that is now horizontal (so we have basically switched directions) as I see that navigation is already at risk of overflowing.
Overall the sidebar design should provide better scalability, but there are of course disadvantages to this as well as you risk pushing navigation areas out when the navigation tree becomes large enough. The amount of sub-nodes in the navigation is also an issue as they are now quite many in some areas.

The solution to solve the problems for the Atlassian Navigation.

A solution for how you work, not the other way around
"New customization capabilities for each user's unique way of working and individual preferences."
This is where I chuckle a bit because this is Atlassian in a nutshell these days. They want the cake and eat it too. What this refers to is the functionality in the new navigation to reorder and hide parts of the navigation so you get your own structure and your own navigation tree. If you are changing a navigation pattern with the desired outcome is to provide a more consistent experience, how is this aligned with every user having their own navigation structure and their own content in the navigation tree?

Yes, the functionality for each node is consistent, but the navigation now moves from a consistent per product design to a variable solution on an individual level. I think this will introduce a lot of confusion and for content creators and product trainers this will add another challenge where our navigation structure may look very different from the users that rely on our content or trainings.
I already have seen a few cases where people get upset because they can't find something in the navigation because they forgot that they hid it from view, or because they have moved it and forgot about it.
On the upside though I know a lot of people like this, especially the early adopters. The question is just if it will add more value than frustration across the entire user base.

Enable Teams to stay in the flow with the new Atlassian navigation
"Improve user efficiency and customer satisfaction by aligning to a pattern users are familiar with while paving way for an AI-first experience."
The idea to take experiences from other tools to reduce cognitive load does not really make sense to me, because the top navigation is a well known pattern. Not having to jump back and forth and having more room to expand the navigation than in a top navigation makes more sense to me. The downside with a sidebar navigation that expands however is that once your navigation become long enough you will effectively push navigation areas out of sight, which can have negative effects.
The top navigation can use the "More" functionality so it breaks off the navigation nodes that can't fit, which has its advantages and disadvantages. I don't think the sidebar navigation will be better or worse in that regard. The visibility is a bigger concern, but that can be enhanced, perhaps with a selection in the personal settings.

A modern look and feel for the new Atlassian navigation
"Revitalize the navigation by delivering a fresh modern product experience"
I have always despised these buzzwords because there is no such thing as a "modern" anything and when you add fresh, it just means they wanted something new. Nothing wrong with that, but just say that you were bored with the old design and wanted some new eye candy.

The result from user testing the new Atlassian navigation
The webinar show some impressive stats, but without the actual data on how those numbers came to be. This is typical when you want to hide the actual data, or when you don't want the viewers to focus on the metric, but the message.
For example 97% stayed with the new navigation once they had it, which makes sense since this will be the new standard. There is no advantage in reverting, unless you are just so disgusted that you absolutely can't use it, or you want to stay with what you know a little longer. These tests were done in an EAP and later in an open Beta, which means you got the early adopters taking the tests. Still, it is a good indicator that we will not see the repeat of the blue sidebar mistake.
Stats without any data attached to them are thrown in for good measure and I would take those with a grain of salt since we don't know the metric for those.

More Active Users
More Active Teams
More Cross product usage
More efficient navigation to progress your work

Considering the claim that users spend 40% of the time spent by knowledge seekers are spent finding information in the products, it would be strange if these things were not true, but the question is what are the measurement points and to what extent are these arbitrary measurements measured?

When will the new Atlassian navigation roll out?
This has been a bit of a mystery because it has not been published anywhere as I have seen. You can only see this roadmap in this webinar and even there it is noted that dates are subject to change. There are five dates in this roadmap, starting with the EAP and Open Beta that started in October last year, and it ends with full rollout in September 2025. Here are the dates and when you can expect to see the new navigation in your Atlassian products.

March '25
Start rollout for Standard edition
All Free Edition
All new Trials
Opt in for all Sandboxes
July '25
Start rollout for Premium edition customers
September '25
Start rollout for Enterprise edition
December '25
100% all customers on new navigation

What is my impression of the new Atlassian navigation?
My personal impression of using the new navigation for a few months is that it is not bad, but as a long term user it takes longer now as I am not familiar with the new icons, the new structure or even where functionality is located. I often find myself scanning the tree trying to figure out where in the tree I am currently at and then trying to find out where to go to find things like board configurations as those are a little hidden.

I think that the users that have working in the products will have their productivity go down initially as they have to re-learn patterns. This is normal when you change navigations and it is a temporary issue. It is however something you need to take into consideration for when the new navigation is rolled out for your organization.
I also believe that this change will see a good amout of resistance, but that this resistance has more to do with the human nature to resist change than that this new Atlassian navigation is bad. As a UX designer and experienced user of the Atlassian products I have opinions, but as with all design opinions will always differ and at the end of the day it is Atlassian that have the final say if this new Atlassian design fit their vision of their products.
I also find the clarifications on the design decisions, not just in the video where Kristin Perchal go over the business decisions, but also in the article by Tarra Van Amerongen, Head of Design Jira Platform where she go through the design decisions in a very nice way. The article is named Designing Atlassian’s new navigation and you can find it in the Atlassian Blog.
Comparing this with the old blue sidebar, which was not received well, I don't think we will have the same issue with this design. The old blue sidebar had a very bad navigation switch system, which we still have for Jira Service Management by the way, which switched the navigation with a new navigation. This was very difficult to navigate and you often got lost, not really knowing on what "slide" of the navigation you were currently on.
Back in 2019 when Atlassian changed from the blue sidebar to the top navigation people where very happy necause the experience was very confusing. You can see the comparison between the old blue sidebar and the new cloud on this page written by Rachel Wright on her excellent website Strategy for Jira.
I don't think we will see the same situation this time, but that all depends on how vocal people will be about resisting this new design for the Atlassian navigation across all their products eventually.
Overall I am positive about this change and I think it fit well into the new direction I think Atlassian is heading where they are tightening their product portfolio and rather than selling products they are aiming for one product with multiple modules...

What do you think?

By 💫 Jimi Wikman in Atlassian · March 9Mar 9

0 comments
1,955 views

Opsgenie,

Today Atlassian announced that Opsgenie, the On-call and alert management tool that has been widely used for Data Center customers and Cloud customers alike, is being decommissioned. The first end date is end of sale – effective June 4th, 2025 from when no new licenses will be available. Then on April 5th, 2027 there will be no more support for Opsgenie.
This is of course devastating news for many Atlassian Opsgenie customers as they now will have to find new solutions for their on-call and alert management. If you are on cloud, then you will find that almost all functionality from Opsgenie is already in Jira Service Management, and you also have a few extra features like automations. While tricky to fully migrate everything, as long as you are on a cloud instance with a Jira Service Management license, you should be fine.
For those of you that are using a Data Center solution however, there does not seem to be a plan for you. The migration tool is only for Cloud and as far as I know there are no solutions for you on Data Center that can replace Opsgenie.
I don't know how Compass is included in this since it is not an on-call or alert system, but I do know that since Compass is a cloud only product, it will not help those of you with Data Center instances. It is a bit unfortunate that the blog post where Atlassian present their thoughts on why they shut down Opsgenie is written clearly from a cloud perspective as it does not even mention the Data Center clients.
I don't know if there is a plan to announce that Opsgenie functionality will be added to Jira Service Management for Data Center as well, but I think if that was the plan they would have added that in the blog post to avoid the angry customers that no doubt will complain about this (and rightfully so).
UPDATE: Atlassian have added this to their Migrate from Opsgenie FAQ for Data Center Customers
As part of its cloud-first strategy, Atlassian has been working to embed Opsgenie’s functionality across the Atlassian platform and products. Since Opsgenie is a cloud product and does not have a Data Center deployment available, Data Center customers will have a two-year period to plan and carry out their migration to either Jira Service Management or Compass to retain functionality like alerts and on-call management capabilities.
Personally I think this is a good thing to move away from standalone products and merge things into the platforms. I also think this shows the way Atlassian sees the Data Center customers, even if I think we could ascertain that Data Center is not a high priority for Atlassian.
At least not at the moment.

By 💫 Jimi Wikman in Atlassian · March 6Mar 6

0 comments
2,677 views

If you are serious about keeping your Data Center secure and high performing, then making sure your API is not being hammered and that data is not moving in and out of the API without your control.
In Data Center, we can control what is happening in our API in several areas:
Account - allow us to control what accounts have product access and can create tokens to be used to connect with the API
Rate Limiting - allow us to define what connections we allow and how many calls they can make before they get throttled.
Allow list - allow us to control from where we will allow connections.

Account
The first thing you want to do is make sure that you control the accounts used to connect to your API. You do this by creating local accounts following a special standard, so you set the account name and email. This will ensure that you are in control of the account and no one can access it or reset the password to gain access.
Example:
Username: SAINT001
Full Name: SAINT001
Email: SAINT001@yourcompany.com
Once the account has been created, you log in as that user using the Switch user function in the User Admin section. Go to Profile ⇾ Personal access tokens and create a token for that user. Make sure it expires in 6 months, or a year. The length depends on how often you want to set up the review of all integrations to make sure the integrations are still active and the documentation of the integration is up to speed.

Rate Limiting
Rate Limiting have two purposes in our setup: limit the amount of requests that integrations can make to prevent performance issues and to control what accounts can access the API.

Enable Rate Limiting and set it to Block all requests. If you have an old Jira with a lot of unknown integrations, or if people are treating it is a playground, then first set it to Limit Requests. This way you can turn down the number of requests, so people notice that something is happening, so they contact you about it.
This is assuming their integration actually has been built with response management and rate limiting support, which they should if they know what they are doing. If they don't, then they actually pose a danger to your Jira, and they should not connect to it anyway.
Once you have activated this, and it is blocking all requests, then no one can access the API. This is not what we want, so we add all our integration accounts to the Exemptions list. This will allow those accounts to connect to the API again.
Set the rate limiting to whatever limit makes sense in general, depending on the configuration of your hosting hardware and perceived impact from the number of integrations you have. If you see that an integration account show up in the List of limited accounts repeatedly, then talk to the integration owner and see if there is a problem, or if that integration need a more generous rate limit.

Allow list
The Allow list will give you the ability to further control access to your API by preventing access from any source that does not match what you have defined. This prevents someone from gaining access to one of the integration account to connect from outside what you have defined.
It also prevents users to share their integration account and token with other groups in your organization, which you should absolutely not allow.
The Allow list should be activated, and the settings should be set to allow authenticated users. You can then add domain names, exact matches, wildcard expressions and regular expressions. Be careful when adding wildcard expressions since users will often request whole networks and that will reduce the effectiveness of your allow list.
Always be as specific as possible. This means that it is far better to add a dozen specific endpoints than adding a wildcard for a full subnet.

Access to data
As a Jira administrator, you should have no involvement when it comes to managing access in Jira. All licenses should be managed by your AD, even if you are a small company, and all project access should be managed by the teams that work in those projects.
This is very important because if you are responsible for licenses and project access, then you are also legally responsible for how the integrations handle the data they have access to.

Make sure that all Jira projects are hidden by default!
I know that sharing is caring, but oversharing is not something you want to spend time in jail for. Make sure that all projects have the same settings for this, and that is that all Jira projects are hidden unless you have a role in that project.
This ensures that integrations also can only access the data that they have access through by the teams manually giving that account a role in their project.
If you absolutely must have everything open to everyone in the organization, but still want to restrict the integration accounts only, then that can be done with AD groups. Just assign all employees in the organization an AD group, and then use that in your permission settings to give all employees access to every project.
Since the integration accounts are local, they will not have that group (unless you stupidly add it of course, but that kind of defeats the purpose of having it...). This way those accounts still need to be assigned a role, and you are able to control the data they have access to.

Secure, Compliant and responsible
These three simple words should always be your mantra when you are working as an administrator in Jira and for integrations they are extra important.
If you do not control your API's, then you not only risk exposing things that should not be exposed. This can be secret projects or god forbid information about your internal infrastructure or customers that a malicious hacker can exploit.
You also risk legal actions based on how the information your Jira provide to other systems, should they use them incorrectly. While Jira in itself do not handle a lot of sensitive data, the tickets themselves can have a lot of this, especially if your users have requested custom fields that hold this kind of information.
And finally, I think everyone can see that if anyone in your organization can connect to your API and do whatever they want, there is only a matter of time before this will start impacting performance.
At the end of the day, it is your job to make sure your Jira is Secure, Compliant and that you configure it responsibly.

--
These are very small steps you can take to secure your API access, and there are other ways as well. Do you have additional steps on how to secure Jira API, or do you think this is not the way to do it?
Sign off in the comments!

By 💫 Jimi Wikman in Atlassian · October 23, 20241 yr

0 comments
1,097 views

Assets,

I remember when I first saw Insight in the Riada office and I was blown away by the potential. When Insight was split off into Mindville later I thought that Insight would take off like a rocket. And it did so well that Atlassian eventually acquired Mindville. I had no reason to think that Insight would not become a new product with Atlassian that would rock the world, but I was wrong. Very wrong.
In July 2020 Atlassian announced that they acquired Mindville and thereby took ownership of Insight as a product. Since then things have moved on for the Data Center version where things like improved UI and Auditing have been focus points, making it an even better administration tool for Jira Administrators.
For cloud... well, it has been pretty dead in the water.
Sure it has the base functions, but there are so many things missing!
Differences between Data Center and Cloud.
Import data types
Cloud: CSV, JSON, Assets Discovery
Data Center: CSV, JSON, Assets Discovery, DB, LDAP, Jira Users and Groups
Integrations
Cloud: Jira Service Management Services, Marketplace Integrations for Cloud
Data Center: Cloud providers (AWS, Azure, Google Cloud), Mobile device and software management (JAMF, SCCM, Snow), Other CMDBs (ServiceNow, Device42), Atlassian ecosystem (Jira & Bitbucket, Confluence, Tempo), Others (NVD)
REST APIs
Cloud: Public REST API, External Imports API
Data Center: Public REST API
Object schema templates
Cloud: Coming soon!
Data Center: ITSM, HR, FM

There is more...
While this just show the high level differences I think you can see that there is a substantial gap in high level functionalities. In addition to these changes we also miss features like the ability to upload scheme specific icons and automation. There is also no file management for CSV imports and so on.

The Gap is not the worst part...
While having a big gap between Data Center and Cloud is bad, there are other things that in my opinion are even worse and that is accessibility. I don't mean the UI, but the fact that on Data Center Assets is available for free, while on Cloud you have to double your annual cost and go premium to get your hands on it.
The fact that a single agent license cost a whooping $47 (compared to Jira Software's $15 per license) is cause for many mid-sized to large companies to immediately regret trying out Assets in Data Center.
This cost and the fact that you can not even try it out in a limited capacity make Assets something that only those willing to buy on a leap of faith, or people that already have experience with the product, to actually experience it. This is the same problem that Atlassian have with Jira Align and I think it is also why both Jira Align and Assets are growing a lot slower than they should.
Assets as a Jira System Administration tool is amazing
If you have used Assets on Data Center or Server, then you probably already know what an amazing tool it is to keep track of your Jira system. The Jira environment import not only spider though your system and keep you updated on changes, it is also a very nice one stop database for all your administration needs.
It will allow you to keep track of all integrations, service accounts and anything else that you have that is not directly included in the import. If you have a messy system with a lot of technical debt from migrations and things like that, then it is an amazing tool to keep track of what you need to clean up and what you should consolidate.
It also provides a very useful tool for your support desk where you can connect all tickets to existing configurations. For example, you can connect all configuration requests and automatically assign an approval to the project lead. This speed things up and you can simply ignore tickets that are not approved, seriously reducing time you spend on tickets.
If used correctly you can also connect all tickets to the configurations involved. This type of historical documentation really help to maintain your system well-kept and organized.
I hope to see much more development on Assets Cloud
I really, really like Assets. It is one of my favorite features for Jira Service Management and as such I really, really hope we will see a lot of improvements when it comes to the Cloud version. The Jira environment import is a must I would say, but also AWS and Azure import is really, really important. I think many will also miss both Tenant and Yamf imports.
When it comes to the Jira environment import it has some areas where it should absolutely be adjusted. For example, you should be able to follow the full chain of configurations regardless of starting point and there is no Permission schema, which is odd on Data Center.
The road forward if I was in charge
I am no fan of the forced Premium features that Atlassian have. I think it goes against their core values and I think you should be able to explore all products regardless of subscription level. So what I would do is either break out Assets as its own product or add it for free with limitations in the free subscription tier.
If you can make 3 schemes and only have 1000 items in each for free, then more people will want to try it out. More people trying it out means that more people will see how useful it is, and more people will want to get the full version. More people means that more companies will build more apps for it... and so on.
--
Well, for now I will continue to enjoy the amazing features that Jira environment import provides on Data Center. I hope that one day I will not only consider moving to Cloud, but actually yearn for it!
Let's get Assets on Cloud Amazing!!

By 💫 Jimi Wikman in Atlassian · September 21, 20241 yr

0 comments
1,158 views

Atlassian, Jira Service Management,

I currently own two websites, atlasstic.com and jimiwikman.se. and I want to set up support for both of them. I don't want to spend a lot of money doing so, as I have other things to sink my money in, like hosting for example. So I want to set up a dual support using just one license. To make this a bit trickier I want to make it so that the two setups will feel and look completely different.
So let us plan this shall we?
So I have one Jira Cloud instance and one Confluence instance. The Jira instance is a premium license, because I want to play around with Advanced Roadmaps. I have a standard Jira Service Management on top of that and my Confluence setup is also a standard setup. I want to take advantage of all the Atlassian products I can, so I also have Jira Work Management, Jira Product Discovery, Compass, Bitbucket, Status page, Trello and Beacon. So I have a pretty extensive toolbox to play around with.
My Key add-ons at the moment are Refined that I will use to split the support portals, Scriptrunner for all kind of magic and Microsoft 365 for Jira for all email/teams/Jira combinations. I am also running BigPicture Enterprise and StoryMap for planning and for making some videos.
One Support project for both sites.
The core of the support setup will be one Jira Service Management project where all tickets from both sites will aggregate. This makes sense since there are not a lot of tickets flowing in. If I want to split this later on that will not be a big problem as Refined allow us to make these changes quickly and with ease.
I want to show open incidents and tie in Status Page to show on the portal. I also want to display Confluence pages to answer common questions, but as a content block and to show when a user writes a ticket. Since I have two sites I want to have this with two sets of projects and spaces.
For support, I want to have different types of requests depending on what the person submitting a ticket for wants. I also want SLAs to measure my response and resolve times as well as timers to help count down and remind customers automatically in different time intervals. I want to automate the status transitions during conversations so I don't have to change the status manually every time.
Let us plan the project setup
The first thing we need to do is to plan the issue types so we know what kind of requests we want to handle. While you technically can use any issue types as you will define the actual ticket types, there are some nice features built into Jira Service Management that we can use.
ITSM is a pretty good standard for must use cases and in Jira Service Management we can add those under Features in the project settings. So in the Work categories section we will activate Service requests, Incidents, Problems and Changes. We will also activate post-incident reviews but mostly to try that out rather than it being anything we probably will need. As I don't have Premium I can't activate Customer Service Management, so we leave that one for now.

Now that we have these activated we will get extra sections in our project that act as Queue categories, which is very nice. Since we have these defined now as sections, or categories really, it makes sense to also have these as our issue types.
The next step will be to map the different request types towards these sections.
Planning Request Types
The first thing we need is something for when people email in. This will allow us to separate these from other requests as the quality of these are usually very poor compared to portal created tickets that we can control the content from. We also need an incident type, so people can report problems of course. I do get some collaboration tickets also of various types, so we need something for that. Suggestions sometimes come in as well and we want those to go to Jira Product Discovery for processing. Legal is always good to have in case we get requests or demands from legal sources.
So, let us break that down into actual request types:
Incoming Email Incident Collaboration Suggestion Legal General questions I think that will be a good start and then we can build upon that later when we see the need for it.
Asset Management
I love Jira Assets and I work extensively with it in my role as Atlassian Platform Owner at Sinch, but in order to use Assets I need the premium version of Jira Service Management. At $47 monthly for just one Agent that is a bit much, so we will settle for the very limited Services feature for now. It is not a very good feature compared to the actual Assets product, but it will work for connecting tickets to the different parts of the two websites.
Create the project
Based on this we can go ahead and create the project. We could go for the ITSM template, but it adds a lot of things that we don't need that we just have to clean up later, so we go for the blank project for IT teams instead. In the screenshot below I had to add another Key since I already have this setup. I choose company managed because I like structure and order and I do not like team based projects.
Now t
Now that we have the project it is time to tweak some things and I started with the issue types. I decided that I would change them up a bit and this is the list I can up with.

As you can see I have created a new Issue Type Scheme since I like to name things so they look good rather than having generated names. On top of the four standard issue types that comes with ITSM (Incident, Problem, Service request, change request) I also added one for Post Incident Reviews since we have the feature activated. I also added Ask a question for more open type and then Consultation for collaborative things. Finally, I added one issue type for Email request as well.
From there we can now begin creating the request types and the forms we want to go with each request type. I just add them one by one and map them to the request categories and issue types.

Most request types end up in Service Request, but we get a few in each except for Problems. This is fine as problems are internal tickets.
Building the Request Forms
I like my tickets clean without too much clutter, so when designing the request forms I go super simplistic and then I can add later if I need to. I also like to use Forms since that allow me to ask for any type of information without adding a ton of custom fields.

For the request form itself I always make sure I have the Summary field, even when I work with Forms. This is because the summary is what trigger the suggestions from Confluence and it also ensures that I get variations in the summary instead of having them all the same if you choose to hide it.
At the bottom you can see that I have added a form to this request type as well, which we will cover in a different post.

For the Issue View I just have the Description and Summary in the top section for this and then I add the fields I feel I want for this request type. I did add tabs for this project and I will show how I did that in another post so you can see how that looks and what you can do with it. Adding the tabs require you to go to the Screens and this article is already a bit long.
Since we do not have that many request types I will just add two Portal categories, one for General requests and one for Incidents for now. We will experiment a bit with this in Refined later so we might come back and adjust this then. As we can place individual request types in Refined rather than just display the project setup, this is not as important as if we had not used Refined.

Now that we have our issue types and request types setup we need to create the workflows and set up the automations we will use. This is the topic of the next article, so if you like this so far make sure you keep an eye out for the next chapter.
This is a rather high level article, so let me know if you want me to dive deeper into a topic in another article.

By 💫 Jimi Wikman in Atlassian · September 21, 20241 yr

0 comments
547 views

How to manage projects the right way based on contract types
How to manage projects the right way based on contract types

💫 Jimi Wikman · September 27Sep 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 pro
- project management
- Ways of Working,
💫 Jimi Wikman

September 27Sep 27

💫 Jimi Wikman

September 27Sep 27
- 0 comments
- 240 views
Atlassian Data Center is officially ending on March 28, 2029
Atlassian Data Center is officially ending on March 28, 2029

💫 Jimi Wikman · September 10Sep 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 Cente
- Atlassian,
💫 Jimi Wikman

September 10Sep 10

💫 Jimi Wikman

September 10Sep 10
- 0 comments
- 542 views
Atlassian renames Jira Project to Jira Spaces
Atlassian renames Jira Project to Jira Spaces

💫 Jimi Wikman · June 23Jun 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 conti
- Atlassian, Jira, Jira Service Management, Jira Product Discovery,
💫 Jimi Wikman

June 23Jun 23

💫 Jimi Wikman

June 23Jun 23
- 0 comments
- 1,219 views
Communication has never been the solution, understanding is what we need.
Communication has never been the solution, understanding is what we need.

💫 Jimi Wikman · May 29May 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, tryin
- communication
- reqirements
- Requirements, Ways of Working,
💫 Jimi Wikman

May 29May 29

💫 Jimi Wikman

May 29May 29
- 0 comments
- 787 views
The balance between Chaos and Red tape - the cost of failure is very high
The balance between Chaos and Red tape - the cost of failure is very high

💫 Jimi Wikman · March 24Mar 24

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
- Psychology, Ways of Working,
💫 Jimi Wikman

March 24Mar 24

💫 Jimi Wikman

March 24Mar 24
- 0 comments
- 1,310 views

Benefits of Using ReactJS for Your Web Development Project
Benefits of Using ReactJS for Your Web Development Project

°selena emani · February 3, 20232 yr

Introduction ReactJS Development Company is a software development firm specializing in the development of web applications using the ReactJS library. ReactJS is a popular JavaScript library for building user interfaces, and it is known for its improved performance, reusable components, ease of use, and strong community support. At ReactJS Development Company, our team of skilled developers has extensive experience in building complex and scalable web applications using ReactJS. Our developers h
- frontend
- reactjs
- Development,
°selena emani

February 3, 20232 yr

💫 Jimi Wikman

October 27Oct 27
- 1 comment
- 1,032 views
Kotlin Vs. Java: Which is Best for Developing Android Apps?
Kotlin Vs. Java: Which is Best for Developing Android Apps?

+ Erma Winter · January 20, 20223 yr

For more than two decades, Java was one of the more sought-after programming languages used on a variety of devices. Since the beginning, mobile apps developers have relied on Java to create hundreds of applications. In May 2019, Google announced that Kotlin was the preferred programming language for the Google Play Store for Android applications. To develop a successful mobile app, it is crucial to choose the best among Kotlin vs Java languages. Let’s learn what these languages are, their pros
- java
- kotlin
- Development,
+ Erma Winter

January 20, 20223 yr

+ Erma Winter

January 20, 20223 yr
- 0 comments
- 48 views

Sign In

My Articles

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

The New Atlassian Navigation and the thoughts behind it

Opsgenie end of life on April 5th, 2027

How do you secure your API for Jira Data Center to control what data flows in and out of it?

Assets - the lost potential

Let's build a two site support setup with Atlassian Products - part 1

Categories

My Latest Articles

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

Latest Community articles

Benefits of Using ReactJS for Your Web Development Project

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

Who's Online (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)