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

How will large organizations handle next-gen projects in Jira Cloud?

Atlassian is continuing to push for their cloud services and many new and innovative features for Jira Cloud are added to the new next-gen project type. This is the most open and flexible project type ever created for Jira cloud, which can cause serious headache for large organizations.
"In next-gen, projects are entirely independent from one another, meaning you can change something in one project and it won’t impact anything in another. In next-gen, workflows live within projects and will be tied to specific issue types. So for example you could have a specific workflow for your bugs and another workflow for your stories. Because the projects are entirely independent from one another, it gives teams more autonomy to adjust and continuously optimize their workflows without impacting other teams or having to bother administrators." - NextGen roadmap
The total freedom to create your own workflows and customize the way you work is a dream come true for many project owners. For method and process offices however they are a nightmare unless you are one of the few enterprise companies that actually work with work processes in Jira on a daily basis.
Many of the companies I meet struggle to even maintain a common way of working with a strict workflow policy. The idea of letting every project getting the power to create their own way of working could be a nightmare for those companies. So what can you do to control the way of working so people can work cross projects and still allow for freedom and autonomy within the projects?
I believe in education and freedom under responsibility.
That being said I think that next-gen should not be treated any different than Jira in general. If you have a defined way of working, and I do not mean what words you should use based on methodology, but an actual way of working. Then teach the users. As long as the way of working makes sense to the users, then they will naturally follow it.
You also need coaches to support the teams. This is important, not just because we want to give the teams the best possible chance to succeed, but also so we can capture new ideas and improvements to the way of working. This way we can continuously improve the way we work together.
If there is one change I would like to see in large organizations, then it is to have a proper center for way of working: The WOW office. Many have similar offices, but they almost always follow a top-down approach where they focus on processes and methods. The concept of defining a method rather than asking the users how they want to work is for me a complete waste of time.  I see so many companies focusing on defining words instead of describing what is actually done. So I would suggest a bottom-up approach with each capability having it's own organizations.
If you have proper support for the teams and you have a healthy WOW office that can train the teams on how to use the tools in your organization, then you are going to have a great time. If you on the other side do not have a WOW office with a defined way of working that is aligned with the users or a support organization to train and support the teams....then do not allow the creation of next-gen projects in your organization.
Next-gen projects have the potential to fracture your organization, or form mega projects with thousands of users. It can form barriers making working cross projects impossible and lead to customizations that will quickly make life hard for everyone. This is the same issue many organizations face when they have a loose policy for customizations, but with next-gen projects you will loose any possibility to control the way each and every project will define their work processes.
With the push from Atlassian towards Cloud and the changes to licensing models for large organizations this is not something you need to look at in the future. This is a reality now and you better prepare for it before you end up in a bad situation.
Next-gen projects is the future. With right preparation and investment I think it will supercharge your teams to a productivity and creativity that you have never seen before. Make sure you have a plan for it and how to align all that power to a common way of working without crippling the teams autonomy.
Are you prepared?
Jimi Wikman
💫 Jimi Wikman

Why are Requirements so difficult to master?

Requirements are very important. In fact I would say that 95% of all failed IT projects can be traced to a poor requirement process. This is baffling because requirements are really not that complicated and yet I see people fail in organization after organization.
After I started to look into the different flavors of Requirements I start to understand why things are so very hard to understand for many. There are such confusion about what type of work you should actually do, who you actually work for and what you actually should deliver.
So let us define what a requirement is first:
 
"A Requirement is a legal agreement between the requester and the performer."
 
That statement alone will surely get a few people raising their eyebrow for the simple reason that it does not fit in their job description. Again this baffles me that we have so many different work description for a single discipline. My only explanation is that people are confused on what different levels you work with requirements.
If we simply break down the three most common way of working I have seen: Facilitate, Investigate and Document. Then add it to the three common areas of work: Business, IT and translation between the two, then we can make a nice matrix. From there we can see what actual roles people have.
 

 
For me I think that anyone working with facilitating meetings as their primary function is a manager. Anyone who just document the need is a secretary. Those two types of "requirement analysts" I see frequently and in my opinion we should make sure that we call them for what they are so people do not think that this is requirement work.
In the investigative category it is common to work in all 3 areas depending on who you work for. Business analysts help business to define their need and IT analysts help IT define their need. This is however not requirements as their final product, but need. That comes BEFORE requirements. In this matrix we can see that the only role that actually work with requirements as the final product are the Requirement Analysts. This makes sense since the definition of requirements as a final product is:
 
"The outcome of a Requirement is a translation between need and realization of that need."
 
This is where many fail. I see many, many requirements that are nothing more than a granular break down of a need, but lacking the translation.  Many are often either to undefined and border on a business need, or other times I see technical specifications instead of the need. My theory is that people do not understand what requirements are and who they are for.
We can see this in the delivery of requirements as well. I do not know how many times I have seen people claiming to work with requirements simply dump a bunch of documents on the development team and move on to next project, or next iteration of the project. This way of working when you build walls and throw packages over it is NOT a proper way to work with requirements.
As we can see in the matrix above a requirement analyst sit between business and IT. There she function as a bridge between the two, translating need in both direction to ensure everyone understand and agree on what should be realized. This can only be done with active communication, person to person, and you never deliver a requirement, you make a handover.
I think that this is the key for making requirement processes work: handover and asking development and test to take over the responsibility of the requirement. To ask the most important question there is: "do you understand what business want and can you realize that need with the information you have been provided?" If the answer is no to that question, then you are not done with the requirement.
If you just understand your place in the requirement process and you understand what a requirement is, then the requirement process will be easy for you. If your organization understand that as well, then life will be great for everyone.
 
So do you still think requirements are difficult?
Jimi Wikman
💫 Jimi Wikman

Goodbye Killjoys and thank you for the entertainment

After almost 5 years Killjoys has come to it's last episode. It has been a bumpy ride with it's up and down, but for a very long time now this show was my Sunday entertainment on HBO. That is now over and it feels a bit sad to be honest.
2015 was a good year with 2 new science fiction series starting to air on Sundays: Killjoys and Dark Matter. In 2017 Dark Matter was cancelled and ever since I have enjoyed some lighthearted, humor filled kick-ass sci-fi through Killjoys. Yesterday that all changed.
The last episode of Killjoys was aired.
I will be the first to admit that the show has been struggling a bit since season 3, so it is not surprising that it was cancelled. Don't get me wrong, season 4 and 5 has been great, but I feel that season 3 was the peak of the show.
It is strange that you can get emotional over a tv show ending, but after 5 years and 50 episodes watching Hannah John-Kamen  and Aaron Ashmore  expand their family with Luke Macfarlane as Aaron's older brother, Thom Allison as the gay warlord/bartender, Kelly McCormack as the weird scientist, Rob Stewart as the estranged father figure, Patrick Garrow as the grumpy military guy and Mayko Nguyen  as the grumpy noble woman to mention a few, you kind of grow fond of the cast that comes to visit every Sunday.
I will miss following the unlikely heroes of the Quad and share a laugh or two with the charming cast as they kick alien butt. If you have not seen the show yet, then I suggest you give it a go over at HBO.
Goodbye Killjoys and thank you for the entertainment.
 
 
Jimi Wikman
💫 Jimi Wikman

Procreate 5 - five new features

Procreate 5 has been announced and with it comes some cool new features such as brand new cutting edge graphics engine and the new brush studio. I will try to tell you about five of them that I think is pretty cool and that i think will really make this upgrade worth while.
Procreate 5 is built on a new graphics engine called Valkyrie. This will not only improve performance, but will also allow new features such as importing Photoshop brushes and customizable brush options.
"the new cutting-edge graphics engine designed to elevate Apple Pencil and iPad Pro to new heights."
 
Brush studio is a brush editing tool that will let users combine two brushes to create custom Dual Brushes, and features over 150 different brush settings. Users will be able to manually adjust the Apple Pencil’s pressure and tilt settings, and use the built-in texture generator to create their own brushes. This will give you get hundreds of different brush variables to play with.
"Seeking the perfect brush to suit your style? Craft your own from the ground up. Using the built-in graphically accelerated texture generator, you'll be able to make the brush you need in seconds."
 
Animations, which was introduced back in April is given an upgrade as well. Animation Assist has features like onion skinning, (which shows a faint outline of the previous layer, and instant playback.

 
Colors are given some new dynamics options which will allow multiple colors in one brush stroke based on how much tilt and pressure is applied. We will also see support for CMYK, which is great for users working with print, and RGB ICC profiles.
"Enjoy a level of control unmatched by any other platform. Transform colors on the fly with complete control using Color Dynamics and Apple Pencil's pressure and tilt technology."
 
We will also see a new interface where the users will be able to move around the floating Color Picker and the transform and selection modes have been redesigned for better visibility on the canvas. There's also a new Clone Tool so you can  duplicate textures.
"Working in harmony with the entire suite of Procreate brushes, the new Clone Tool and CMYK support will change the game for concept artists and digital painters. There’s something here for everyone."
 
Jimi Wikman
💫 Jimi Wikman

Official integration between Jenkins and Jira Software Cloud

Jenkins is used by many teams around the world and for a while now the plug-in integrating Jenkins with Jira Software has been unsupported. However now Atlassian have announced an official integration with Jenkins.
The integration itself allow build information from Jenkins to be posted throughout Jira Software Cloud. This is similar to other CI/CD tools where you can automatically send build and deployment information from Jenkins and display it across Jira issues, boards and query it via JQL. In addition to this Atlassian also have built in a new way to integrate using OAuth Credentials.
"In addition to the Jenkins integration we also build a brand new way to integrate your behind-the-firewall apps with Jira Software Cloud. You can now generate OAuth Credentials (2LO) to securely connect these tools without having to open any holes in your firewall. The credential is tied to a specific Jira site, can be generated by Jira admins, and is used to communicate between a self-hosted application (e.g. a Jenkins server) and your Jira Software Cloud site."

Using OAuth Credentials is interesting since it will allow for secure connections even through firewalls to connect to Jira Software Cloud.
"You can now generate OAuth Credentials (2LO) to securely connect these tools without having to open any holes in your firewall. The credential is tied to a specific Jira site, can be generated by Jira admins, and is used to communicate between a self-hosted application (e.g. a Jenkins server) and your Jira Software Cloud site. The OAuth credential is currently scoped to only send build and deployment information via the Jira APIs."
This is great news for all Jenkins users and good news for all Jira Software Cloud users.
Jimi Wikman
💫 Jimi Wikman