I am rebuilding this site (click to read more)
Jump to content

Articles

wdfw w ff wdf sfsfd sfdwdfsdfwerw r werw erwe rwe rwer werwer werw erwer we r we rwerewrwe rwe rwer wer werwer werwe

My Articles
Community Articles
Guest Blogging Information

My Articles

Show all categories

Atlassian acquire Percept.ai - strengthening their ITSM products even further

Atlassian announced yesterday that they have acquired the small California based company Percept.ai, a company that focuses on AI technology to automize support flows, in quite impressive ways. This will strengthen the tool set of Jira Service Management with a new automation technology in the form of a no-code virtual agent that I think will add a lot to the Jira Service Management experience.
While Edwin Wong, the Head of Product Management at Atlassian, did not go into any details in the announcement, it is clear that this will be an important part of the future of Jira Service Management. I also think the acquisition of Percept.ai and their virtual agent technology will find its way into other areas of the Atlassian suite, and I would not be surprised to see an AI driven onboarding agent in the future!
I think this is a strong acquisition and an important one for the Jira Service Management product specifically and for Atlassian in general.
 
Jimi Wikman
💫 Jimi Wikman

Jira Product Discovery - The missing link between business and IT?

Atlassian has just released their new product called Jira Product Discovery in Beta. It is a new project type in Jira Software, just like Jira Work Management, and sadly it is equally a bit lackluster when it comes to functionality. It is however a very nice addition and it has the potential to bridge the gap between business and IT, which is currently being done with creative setups in Jira Software.
So what is Jira Product Discovery?
In short, it is a tool for adding good ideas where you can define value and cost in order to make educated decisions on what to focus on first for your different products. Or just to start new products and value streams. Right out of the box in the Beta, we find many good features such as visual fields for effort and goal impact, the ability to score ideas and the most powerful aspect is the connection to create epics in other Jira projects to truly connect ideation with delivery.
Jira Product Discovery is a very nice new product that can compete with other tools like Aha!, but it is also a typical Atlassian product with limited functionality that may or may not expand down the road. This has been a problem for Atlassian in the last 5 years or so and it can affect the sales of this new product, unless it becomes part of the core like Jira Work Management is now.
 
Functionality looks great!
Even with the risk of having a less advanced feature set than some of the competitors, Jira Product Discovery have a good feature set already.  Things like goals, what can target strategic values, or even smaller product goals is something I work with a lot. Things like effort ranking, key customers and connections to time periods and something they call buckets are all great features.
The ability to add automatic calculation of value is great, but I would like to see the ability to add negative values as well for things like risk and effort. Overall the score system is quite simple and it needs a more granular setup for it to be useful in large scale organizations.
Overall, I think this first iteration of Jira Product Discovery looks impressive and it will most likely fit many companies need as is.
 
It is a Beta
It is easy to point to things that are not awesome right now, but it is important to know that this is a Beta. As such it will be features that are either not yet there, not finished or that will change during the Beta. While I see several things that I think are essential for the future success of Jira Product Discovery as a product, I would not discourage any organization from trying this out even in its Beta format.
That is because this fit a very critical gap in the current product flora for Atlassian and I think this hit the spot pretty close to what a lot of people have been asking for, for a long time.
Don't take my word for it, though, head on over and try it out yourself.
 
Introduction Video
 
Jimi Wikman
💫 Jimi Wikman

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

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 and cons, and which one will fit your app project. Let’s look at. Kotlin Programming Language
Kotlin Programming Language
Kotlin is mostly the integrated environment used for developing apps. It is also able to create statically JavaScript as well as Java Virtual Machine language (JVM).
Kotlin is a blend of functional and functional programming. It is more simple, less messy and more efficient to build than Java. Kotlin can convert the code into binary code and run it under JVM. Therefore, it’s suitable for almost every platform & device.
Java Programming Language
Java programming language can be described as an object-oriented language. The language is easy to learn, strong, robust, and durable. Java is ideal for Android apps, web applications, server applications, embedded systems, large data and more. Open source is a mix of many elements. Java is the basis of a lot of Android apps and also significant portions of Android.
Kotlin Vs. Java: What We Need to Know
Kotlin Vs. Java can’t be used simultaneously for any mobile application development, so it is important to discover which is the most suitable. We’re now going to take a look at the pros and cons of both languages, as well as what makes each one better for certain types of Android applications.
Data Classes: Kotlin Vs Java
Java-based Android application development requires you to create variables or fields that can be used to store information. Additionally, you must create constructor, getter and setter methods, as well as toString() and the equals() and hashCode().
Kotlin automatizes these tasks. You only need to include the word “data” in the definition of the class. The compiler is able to automatically create fields and variables like the setter, getter, constructor, among others.
Volume & Coding: Kotlin Vs Java
Kotlin code load is less than Java’s similar programs. Kotlin reduces the chance of errors in code and eases the work of Android app developers. Because of its ease of use, Kotlin is preferred over Java for massive mobile and web application development projects. Kotlin code is easier than Java.
It doesn’t require constructors to create objects, classes that hold information and get value from declared fields or classes that store the data. Kotlin code is compiled in less than the time required for writing Java code. This accelerates development and deployment.
Null Safety: Kotlin Vs Java
Java has many drawbacks, one of which is Null Pointer Exception. The occurrence of a Null Pointer Exception is only triggered when the user is explicit in throwing it. Inconsistencies in data can occur due to Java code problems with initialization, as well as other issues. Kotlin is unable to run when a Null Pointer Exception is generated.
For the best Kotlin Vs. Java choice and usage, look to hire Android app developers with professional expertise and excellent knowledge.
Wildcards: Kotlin Vs Java
Kotlin is not able to use wildcard types. Declaration variance & the type projections are Kotlin’s wildcard choices. Java allows wildcards. Wildcard codes are typically an unidentified kind. It governs the type security of Java-based codes within a software.
Operator Overloading: Kotlin Vs Java
You can make use of a range of mathematical operators within Kotlin such as subtraction, addition & division. It is possible to compare objects and conduct quality checks with symbols. The Java programming language relies on particular Java data types with mathematical operators. The Kotlin Vs. Java debate is won by Kotlin in terms of Operator Overloading.
Performance: Kotlin Vs Java
JVM runs ByteCode which is written using Java as well as Kotlin. It is however hard to assess their memory consumption. It’s difficult to evaluate and monitor their performance. Kotlin has more features than Java which makes it more practical.
Multithreading applications are made simpler with Kotlin Coroutines tool. Because of its plethora of features, it compiles & runs a bit slower than Java. Java is however much less complicated than Kotlin which means that it is faster to compile.
For top assistance, you must seek assistance from a Best Android app development company and hire Android app developers with great expertise.
Stability: Kotlin Vs Java
It’s the stability that lets us detect distinctions. Let’s begin with Java. Java is one of the languages with an extensive history. Java Version 8 & Java Version 11 both provide extensive support. If anything goes wrong, the Java versions can be upgraded via patches.
Despite Kotlin’s long history, it is still a relatively young language. There is no official version yet. Java and Kotlin can be considered to be stable languages. If you are looking for stability, Java is the best option.
Final Words
We’ve got the complete list to offer on our analysis of the Kotlin vs. Java Debate. Hopefully, you will be satisfied with our analysis and choose the best option based on your preferences. Be it Java or be it Kotlin, everyone has their era and today’s era is inclining towards Kotlin programming Language.
Erma Winter
° Erma Winter

5 new features in Confluence to kick off the new year with

Nothing makes starting a new year as exciting as getting new, fun toys to play around with, and for Confluence we have five of them to talk about today! Not only will you get some nice new ways to present your pages and data withing, but we also get some features that might very well change the way you work. So let us dive in.
#1 Page Status - a game changer?

I don't think I have seen anyone using Confluence without having a status in the page properties to indicate the current status of a document. Now we get a built-in function for this that looks very useful indeed. I can think of a million uses for this, but the question is how this works with things like page properties reports and different listing macros.
 
#2 Presenter Mode

The presenter mode looked a bit weird at first, but it has quite a few use cases where it works very well. One being training or education, and another is to present reports to stakeholders. I think it is a pretty nifty feature to be honest!
 
 
#3 Table visualization

The wet dream of so many managers is to visualize data with graphs. While this may be a very limited experience compared to other tools, it is very much a step in the right direction.
 
#4 Multiple Excerpt Macros

For me who advocate the usage of one source of truth, this is a very good addition. I often use excerpts for design documentation and for non-functional requirements, and I have sometimes wished I could have two or more sections to embed in different ways. With his update, I can now manage these things more freely. I like it. A lot.
 
#5 The new Confluence Home

This change looks really great and I can't wait to see it live. If you want to read more about this change, then check out this article: https://community.atlassian.com/t5/Confluence-Cloud-articles/Say-hello-to-the-new-Confluence-Home/ba-p/1892543
 
These are just a few of the new changes coming to Confluence in 2022 and I will do my best to cover all of them here on the blog and on the YouTube channel.
Which is your favorite of these and why?
Jimi Wikman
💫 Jimi Wikman

Long Workflows in Jira - Multiple processes in one workflow is problematic

Jira is a great tool, but it is often abused by trying to make it do more than it does. One such abuse I see a lot is excessively long workflows, which is usually introduced by management. This is problematic because the longer the workflow, the more you will need to go up in scope for each issue. This is because there is no 1-1 relation between the different areas. This is the most common cause for having huge stories with tons of subtasks.
Before we go any further, let us first define what Jira is not.
Jira is not a project management tool, but it can be extended using Advanced Roadmaps to provide some support for this. Jira is not a resource management tool, but it can be extended using Advanced Roadmaps to provide some support for this. Jira is not a deployment tool, but it can have features that can provide information about deploys. Jira is not a code repository tool, but it has features that can provide information about code. Now, let us take a look at a common process flow for a company.

 
Based on this we can see that we can build something that support the Ideation where we make designs and prototypes. It would probably make more sense to just have a project with some tasks and then use Confluence, as much of what comes through ideation are never going to be realized. Definition is when we document more about the things that comes from ideation, and we would do that in Confluence most likely. Finance has nothing to do with Jira as we don't have connections to budgets, resources and so on. This is where Jira Align would be best suited.
Specification is the requirement process and that happen in Confluence and then we create stories in Jira for things to prioritize based on cost vs value creation before we hand them off to Realization. Verification is usually a part of the realization flow, but more often than not you would use an add-on for it. Acceptance is either a separate activity that also use the same verification add-on as test, or it is just informally part of the workflow.
Presentation is done completely separate and since we release groups of stories it rarely makes any sense to even have this in a workflow. This is what Releases/Versions are for in Jira. The whole maintenance bit where we deal with Incidents and problems is not connected to the realization flow, but it ties into the Specification. This, since the requirement, define what is an incident and what is not.
So based on this, we see that there is a clear distinction for where Jira is designed to work, and that is between realization and acceptance. This is the optimal fit and then you can extend this using Advanced Roadmaps so you can connect Realization to Finance to get that full span all the way up to strategic level.
What if I want to have a longer workflow?
Nothings says you can't have more. Jira is very flexible and you can do pretty much whatever you want. Before you do, however, make sure you understand who you extend the workflow for and what it means.
Extend with Deploy
This is probably the most common extension as a lot of people are used to having deploy, or rather release, as a part of their physical boards. Adding this to the workflow will add a blanket step. By this I meant that this step has no real purpose other than to inform people outside the deployment process where particular code has been placed. Using the version field will actually give this information in a much more organized way. You can also connect your CI/CD tool to automatically connect release information to your stories, which is probably the best solution if you work with continuous deploys.
If you add this in the workflow instead, then someone in the team will have to manually go over what stories are part of a package and then transition them one by one to next status at the time of the release. Considering that this step often happen well after the development, test and acceptance has been closed, it often happens that this is missed, leaving stories open long after they have been completed. Even if you remember it, you will still have multiple stories open in your boards, which will be a problem if you for example release infrequent or need to delay a release. If release is not done by the team, you will also have actions from another team in your board, which is a bit weird.
If you must have a way to visualize where different code is, then you should always use version. This will clearly show what code package a story belong to and you can filter it and also have a dedicated section for managing versions that you should tie to release notes and so on.  If you absolutely can not communicate where a story has been released without having an issue on your board for it, then I suggest you connect all the issues to a release ticket. That way, you can manage the release just like any other task.
Adding this to your workflow means that you skip the version feature completely and since it is a blanket step it is prone to mistakes and lingering stories that very likely will mess up your statistics. If you have problem communicating releases to management and stakeholders, then I think you have bigger issues than your workflow...
 
Extend with requirements
Another common way to go is to use Jira as a requirement tool and by doing that extend the workflow to add more steps before realization. There are three major drawbacks to this, however: you need to have more fields added, requirements are not 1-1 with development, and Jira does not have version control or documentation capabilities.
As the requirement process have a different ritual and workflow than development, we need to add more fields. While this is usually not a big issue, it will clutter the backlog, as well as the content of each story. Each Jira project would need multiple boards to handle the two processes so it does not add confusion for the people working in each of the two processes. Overall, it will add more clutter and add complexity to the work in Jira.
In order to fix the second problem with requirements not being 1-1 with development, you would need to lift the abstraction level of the requirements. If you don't then you would make the user story 1-1 with development and that would mean that each development would have to be a subtask instead of a story. That makes it impossible for the developers to break out their own work further. This, however, often make each story an epic, which then means you no longer have any way to group several stories into a feature. Each story will also have quite a few development tasks compared to having multiple stories created for each user story.
The first two issues you can probably deal with, but the fact that Jira does not have documentation capabilities or version control should be a dealbreaker for any real requirement analyst. Not having a way to structure your requirements so you can find them and maintain them is a big issue, and it is why most people choose Confluence or an add-on to manage requirements. Not having documentation capabilities is also a big issue since you will be limited in what information you can add to your story, and you will most likely feel that this is claustrophobic and difficult to get a good overview of since there are so many other things displayed in the story.
Version control is a must for any requirement tool. This is for two reasons: you need to know what was agreed upon, and you must have a way to continue working. With version control, you can set points in time that you can restore to if needed. If you have worked with IT development for a while, then you probably have had a situation, or two, where unlocked requirements caused a lot of problems. This is especially true for design documents that are supporting requirements.
While it is certainly not impossible to add the requirements part to your workflow, you are again adding steps from a completely different process that have little to no relation to development stories in many cases. This is because requirements can, and will, become obsolete or too costly to be picked up for development during the requirement process. Just like with deploy, you will add complexity to the workflow and the boards, and the team will have information in the stories that are irrelevant for their area of responsibility.
The most common effect of adding requirement steps to a workflow is that there will be (at least) two boards. One for working with requirements and one for development. It is also very common that the stories will be larger to the point where work will mostly be done through sub-tasks to compensate for the lack of 1-1 relation.
 
Extend with business processes
This is not as common, but I see it from time to time. This is not a very good thing because the abstraction level goes way up and even the subtasks will be very large as the workflow starts on a project, or even program level. Even at the smallest amount of statuses for each step you will have a minimum of 14 statuses and I have seen workflows with up to 27 statuses. I do not think I need to tell you how painfull that was for everyone involved...
The problem with having business workflows included in the build workflows is that the business workflow and the build workflow are completely different. The business workflow is all about financing value creation and the build workflow is about realizing the need that has been approved in the business workflow. This means that there are three hard decision points that can stop the progress of the issues:
Ideation - Do we think the theory of value creation is motivated by the value the idea creates? This happens before we even consider looking into the issue further. Financing - What budget will the feature fit into? If it exist, do we want to prioritize it over other features and if it does not, how do we fund it? Specification - When we have broken down the feature so we know better how to realize it, is it still worth doing and if so should we prioritize it? While you certainly can extend the workflow and make a behemoth that will plague everyone in all aspects of your organization, you should consider the next aspects of mega workflows: Complexity and bloating. In order to support multiple processes in one workflow you need to extend the information in Jira as it is built for the built process. That means that you will need to add a lot of additional custom fields. This is bad because not only will it be much harder to work with a bloated issue where the majority of information will not be related to th work you do, it will also slow down the project a lot.
This problem will be even worse when you consider the amount of people that will need to have access to the project. Since you involve everyone up to a strategic level it means that everyone from business level down to realization will need to be included and working in the same projekt. I have seen Jira projects where thousands of people have worked in multiple teams, all with cusomizations to the workflow and content leading to hundreds of custom fields. Loading times could be as high as 3-4 seconds in a DC setup with load balancing and anytime you tried to look at the workflow the browser would crash.

Having the business processes in Jira is not a bad thing, but you should divide between business and build processes, preferably with Confluence as the middle layer to document requirements and tecnical solutions. Tools like Advanced Roadmaps or BigPicture can help extend the capabilities towards the business side as well.
 
Will it stand on its own?
One thing I always ask is if you can take the extended parts of your workflow and let it stand on its own, or is it actually a part of a singular process? I do this to see where people are in their mind so I understand how they think about the work. On one hand, I do understand the need to have an overview of the work from strategic level down to the smallest task in the operative level. I just don't think that Jira is the tool for that, because it is a task management system, not a program, or even project management tool. This is where Advanced Roadmaps and Jira Align comes in. These are the tools that should give you the overview (Advanced Roadmaps on Operations level and Jira Align on Strategic level).
When the users understand that having multiple steps in a process, where the outcome is not 1-1 with the next step, might not be the best solution, then you can show them what a board will look like with all those steps. The number of columns alone should be enough to see that a long workflow like that is not very useful. I have seen a workflow that required 27 columns, which of course is not something you can actually work with.
Use the correct tool instead
The solution in most cases is to not add more steps to a single workflow, but to extend the hierarchy and use something like Advanced Roadmaps, or split the work into two, or more workflows that can exist independently in different Jira Project.
In the series Setup Jira and Confluence - Introduction to setting up Jira & Confluence for success, that I will rewrite and make videos of in 2022, I will go over the tools and the setup in more detail.
 
I hope you found this usesful, and as always if you have any questions feel free to ask. No questions are stupid and if there is one lingering in your head, you can be sure others have the same questios, so you would make them, and me, a favor by asking it ❤️
 
Jimi Wikman
💫 Jimi Wikman