My Articles

By 💫 Jimi Wikman · August 28, 20196 yr

In the previous article we discussed what tools we should use for what purpose. Now it's time to define the work we want to do in the different Areas of Responsibility. We do that by defining what different type of work we do in each so we can create a separate issue type for each type of work. This way we can separate work and can evolve the way we work in each through fields and workflows for example. Before we dig into that however we should first identify what issue types really are and how we should use them properly.

The three levels of issues in Jira
In Jira we have 3 levels of issue types. Each level is used for different purposes so it is important to understand what that purpose is so we can map our issue types to the right level.
Epic - This is the highest level in Jira and it's purpose is to group and categorize the lower levels. In itself an Epic has no value and you can see it as a box or a rubber band that simply is used to group other items. The term epic means a story that extends over a long period of time or that it is something grand and impressive. This is also how it is meant to be used in Jira as a way to mark stories that are connected and span over two or more time periods.
Standard Issue Type - This is the middle level in Jira and it's purpose if to act as the transitional item to indicate what responsibility area currently own the responsibility to do something. This type is the one that we design workflows for that are flow chart based and not in the form of state diagrams. We will cover this when going over workflows in a later article.
Sub-Tasks - Within each responsibility area we have a need to break down the work so we can mark them as complete. These are referred to as producing items and unlike the Standard Issue Type we do not always use a tranistional workflow, but more of a task management flow of open, in progress, done .We will cover this when going over workflows in a later article. The majority of our issue types will fall into this category.
Identifying the work that need to be done
With the issue types identified we can now begin to define what issue types we need for our setup. We previously identified Requirement, Development, Test and Acceptance as our areas that use Confluence and Jira, so we will break down the work in those areas and see what we can come up with.
Requirement
Requirement: Standard Issue Type (optional) - If we want, we can use a separate issue type to act as the object which we work through the requirement process. This should be done in a separate project as it will contain a large number of unprocessed need. This would make managing the development projects less efficient, but we will discuss that in another article.
Story: Standard Issue Type - This is the output from the Requirement process and while the name might make you think it comes from the fact that many requirements are written in the form or user stories. This is not accurate however as requirements can come in many forms and shapes. Story refer to the fact that we get the need explained to us as a story, which is because as humans we communicate in the form of stories.
Design: Standard Issue Type & Sub-task - Design (UX/UI) can be done separate, which is why we have a Standard Issue Type for it. It can also be done as part of a requirement which is why we have a sub-task for it as well. In some cases we need to make adjustments in existing requirements and there we also use a sub-task connected to a Story for that purpose.
Technical Design: Standard Issue Type & Sub-task - Just like with Design we have both a standard issue type and a sub-task.
Technical Debt: Standard Issue Type - This is a rare issue type in many companies, but it is used when decisions are made that create technical debt or when clean up need to be done to optimize systems and data. These are IT driven stories in nature with the intent to make sure IT driven concerns are logged and prioritized alongside business need. It is also used to highlight decisions that will have a cost in the future. Development
Development: Sub-Task - It may seem strange that Development only exist as sub-task, but the reason for that is that development only happen when there is a need for it. This need is in the form of a Story or Technical debt. That is why development only exist as a sub-task and it is used for writing code.
Build & Configure: Sub-task - Again this is only available as a sub-task for the same reason as for Development. This issue type is used when there is no code related to the task, just configuration. It is also used to build systems such as servers that are again configurations or physical assembly tasks. Common tasks are upgrades or adding new subset of a system through configuration.
Defect: Standard Issue Type & Sub-task - The default way to create defects is as sub-tasks connected to a story. This block the story from deployment as it can never be closed with open sub-tasks. The standard issue type is used when defects are found without direct connection to a development or when you want to break out a defect as a known defect, but still close the story for deploy. Defect can only happen before code is put into production. I usually rename the standard Bug issue type to Defect if possible, otherwise I create a new issue type for it.
Incident: Standard Issue Type - Incident is used for defects that are found after the code is put into production. It is separate from defect in order to properly identify where a defect has been discovered as that can affect legal aspects. It is also used to allow proper focus and prioritization as production defects usually need high attention. All incidents are standard issue types as the stories they comes from have already been closed.
Feature Toggle: Sub-Task (optional) - This is a bit of an odd addition lately and it act as a way to determine what code is in what code based, even if it is not activated. We will not dig to much into this one as it's an article in itself. It is just added in case you work with feature toggle in your project. Test & Acceptance
Test / Acceptance: Standard Issue Type & Sub-task (optional) - This is again an optional issue type due to the fact that most test add-ons have the functionality needed to keep track of time and effort. In the event that you need a way to add time and effort outside the add-on, then you can create an issue type for this as placeholder for that information. Generic
Epic: Epic - This is standard in Jira and it is used, as described above, to group standard issue types.
Task: Standard Issue Type & Sub-task - Tasks and Sub-tasks are standard in Jira and they can be used for any task not defined in other issue types. This can be things like scheduling meetings, organize workshop or buy cake for the team.
Color coding for visual guidance
In order to make it even easier to identify what the different issue types will be used for I always create custom icons and color code them. This visualize the area of responsibility as well as the purpose of the issue types. My way to color code is based on color theories and my own preferences, so feel free to adjust if needed.
Requirements - This is an interpretation of the business need to Development. I tend to color Business in blue/teal as corporate colors and Development as red. The combination of those two is purple, so I make the Issue types related to Requirements as purple.
Development - This is the heart of the work flow. We tend to want incidents and defects highly visible as well, so we pick the color that match those requirements. We tie this into the traffic sign colors used in test and acceptance as well. This is why everything related to development is red.
Test - This is where code is either allowed to pass to acceptance, or pushed back to development for further adjustment. It is something we want to make sure it has good attention and we also follow the traffic sign color schemes used in development and acceptance. this is why test is yellow, sometimes with a orange tint to tie it closer to development.
Acceptance - This is where a need is given the thumbs up or the big GO. We use the traffic sign color scheme to signal this and for that reason Acceptance is green. I use icons that I feel is matching the issue type itself to further clarify purpose. I also use en inverted design to distinguish between standard issue types and sub-tasks. You can see some of the icons in the download section. You are free to use the icons in your Jira instance as they are created by me using the free version of fontawesome.

Setting up Issue Types in Jira
Now that we have defined the issue types and designed the icons it's time to set this up in Jira. I will set this up in my Demo Jira which is cloud based. If you use Server or Data Center version the way you set this up will look a little different, but the functionality will be the same.
In order to get the new issue types into our project we will need to do three things:
Create the new Issue Types Create a new Issue Type Schema and add the Issue Types to that Schema Assign the Issue Type Schema to our project.
Create Issue Types
In Jira Cloud we do this under Jira Settings -> Issues -> Issue Types. Please note that you need admin access for this step. Here you will see a list of the current Issue Types and in the top right corner you will have a button that say "Add issue type". Clicking on that will give you a popup where you can create a new issue type.

Once you add the name and description of the new issue type, then you select what type of issue type you want it to be. You can not add an image at the time I am writing this, so you will get a generic icon for it when you click add. Once created you simply find it in the list and click edit to change the icon by uploading a new one.
Next to the icon click "Select Image" and then "upload avatar" in the popup. Select a new image, close the poup and then click on update to save the new image.

Create a new Issue Type Schema
Under Jira Settings -> Issues -> Issue Type Schemes you find a list of the different issue type schemes you currently have in your Jira. In the top right corner you find a button with the text "Add Issue Type Scheme". Click that to create a new scheme. Please note that you need admin access for this step.
When you create the scheme you add a name for the scheme, a description and then you drag the issue types you want to add to the scheme from the list on the right to the list on the left. Once you have done that you can select "Story" as the default issue type. This will make Story the pre-selected issue type when we click on Create in a project using this Scheme. Once done, click save.

Add Issue Type Scheme to your project
Go to your project and then click on project setting in the left menu. It should be at the bottom of the list of areas for your project, but if you can not see it then you may not have admin rights for your project and you need to get some help with this step. If you have access then in the project settings go to Issue Types.
This view will show you the current issue type scheme and the issues included in that scheme. In the top right corner you will see a drop list with a cog wheel that say "Actions". Clicking this will allow you to edit the issues in the scheme, but we want the other function called "Use a different scheme".

Simply select the Issue Type Scheme created earlier by first making sure you select "Choose an existing issue type scheme" and then the correct issue type scheme in the list below. Click OK and your project will now be associated with the new issue type scheme we created and with that we now have our new issue types.

We now have the proper issue types we need to work, but in order for them to really useful we need to make sure we have workflows that match the work we do. This is what we will focus on in our next article: Setup Jira & Confluence for success - Part 3: Defining Jira Issue workflows.

0

By 💫 Jimi Wikman · August 27, 20196 yr

The first thing we need to do before we can actually build the setup in Jira and Confluence is to define the tools. What should be done in what tool. We also need to define how we will use the tools based on what need we have. This may sound easy, but it is actually a bit trickier than it sounds and it's the source of many failures when using Jira especially.

Who are we building for?
In our example, we will build a setup based on a development team. It is a traditional team that tries to adopt some agile methodologies. The company is medium-sized with dozens of teams distributed in several countries where waterfall methodologies are still the norm. Most development happen in projects, which cause some overlap, but overall this get done even if it is not always easy. Requirements have decent quality, but varies greatly between teams, and most work process related changes are driven by management and test.
In short, it is a pretty common situation for many companies. There are some challenges, but the organization is moving towards a more agile and uniform way of working. There is a struggle over control and visibility because the teams want more freedom and the managers still want to feel that they have the control because they are still a bit too far away from the teams.

The Areas of Responsibility
In order to see what tool is best suited for what task, then we need to identify who do what. We start this by breaking down areas of responsibility so we know what areas we hand over responsibility to. In our setup, we identify the following areas:
Business - This is where the need originates from. This is actually a whole process in itself, but we just consider the output as a responsibility area. This is represented by the Product Owner. Requirement - This is where the need is defined and translated to actionable information for the development team. We include design (UI/UX), technical design and non-functional requirements such as legal as part of this area as well. This is because they are supporting the requirement process. Development - This is where the need is realized in the form of code. Test - This is where we ensure the development have good quality. Acceptance - This is where business ensure that the need has been fulfilled. Doing so also conclude the legal agreement between business and development. Deployment - This is where the need is made available to the end users. Support - This is where feedback related to the need is managed. Since we are building in Jira and Confluence, all of these areas are not going to be represented due to the limitations and capabilities in those tools. In order to identify the best tool for the job, we identify the need for each area.
Business - Jira Align
This is a big area that are actually made up of multiple processes. In this area we need to be able to organize people, money and resources into initiatives that span the whole company. We need to follow up and see when cross initiatives have issues in order to mitigate. This area do not just deal with IT, but include things like marketing, product development, human resources and so on. Jira and Confluence are not a good match for this area. Instead, portfolio tools such as Jira Align or Portfolio for Jira are better choices.
Requirement - Confluence
This area work with documentation to break down a need into actionable items. Design is delivered in multiple versions and file formats. Technical design include flow charts and tabled specification of data. Legal and non-functional requirements are usually global, so we need to be able to link in from other locations. We also want to prioritize work, add estimations on multiple levels and eventually create work orders that can be traced back to the original need. Since a requirement is both a translation of a need to an actionable task and a legal agreement on what need to be done, we need to be able to control the requirement. This means that we need both version control to identify changes and the possibility to restrict editing when agreed upon. We will use Confluence for this area for the final documentation. We will also use Jira as an optional tool to drive the requirement forward until it is ready to be locked down in Confluence.
Development - Jira Software
This area work with code where they need to have tasks on what to do. This task is actually the work order, and as such it must be connected all the way to the need. This area also need to connect the work with the code in order to trace work to code packages. We need the ability to assign work, so someone is responsible to fulfill the need. We want to see what is ready to be worked on and if the code package is ready to be deployed. This means that we need to be able to see other areas as well in a workflow. For this purpose we use Jira and connect to the requirements in Confluence. The Development team will also use Bitbucket to manage their code.
Test - Jira Add-On
This area work with making sure that the code we produce are in accordance with the requirement and that it has good quality. We need to be able to create test cases for what to test and then a way to connect to series of test. These must be reusable so we can use them to make the same tests multiple times. We need a good way to report when something is not working so we can bring that back to the development team to be fixed. We need a way to get reports on progress and result of the tests. Jira and Confluence does not support this fully, so we will add an Add-On for this to extend that capability and connect it to the development tasks.
Acceptance - Jira Add-On
This area work with making sure that the need is fulfilled. It is testing in the same manner that the test area, but on a different level and with a different responsible group. We will use the same setup as for Test with the same Jira Add-On, but connect to the requirements instead of the development tasks.
Deployment - Bitbucket Pipelines / Bamboo
This area work with making sure that the code packages created by Development are moved to the different environments. In order to do this they need a way to deliver code between the environments. This in not something that we can do in Jira or Confluence. Instead, a tool like Bamboo or Bitbucket Pipelines will be used. We will however use the Release feature in Jira to connect the code base with the deploys for traceability. We will also use Confluence to document deployments to production for traceability.
Support - Jira Service Management
This area work with supporting the code that is available in production. This requires the ability to manage incoming support requests, identifying resolutions and when needed to create work tasks for different teams. Continuous communication with the reporter is a must, and there should also be a way to resolve repeating requests to reduce duplicated requests. For this Jira and Confluence is not fully what we need. Jira Service Management is a better option for this.

As we can see from this our setup for Confluence and Jira will support Requirement, Development, Test and Acceptance. We will connect with Deployment as well, but the full capability will not be in our setup. Now that we know what we are going to support, then it is time to start looking at what work we actually do in each area so we can define the issue types.
This we will go over in our next article: Setup Jira and Confluence for success - Part 2: Defining Jira Issue Types

3

By 💫 Jimi Wikman · August 27, 20196 yr

I often get questions on how I think the best setup for Jira and Confluence should look when I meet organizations. Because of that I will make a series of posts about this where I setup Jira and Confluence from scratch. This will include not just how I do things, but also the thought behind it. I hope you will find this useful for setting up your own setup in Jira and Confluence.
This series will be divided into several parts. This is because adding every step in a single post would make for a very long blog post. Dividing into a series also make it easier for you to look at specific parts that is most interesting for you at the moment. The parts that I have in mind could change as I write the series, but at the moment the plan is this:
Part 1: Defining the tools Part 2: Defining Jira Issue Types Part 3: Defining Jira Issue workflows Part 4: Defining Jira Screens & Custom fields Part 5: Defining Jira security & access Part 6: Defining Confluence Information Structure Part 7: Defining Confluence Requirement Templates Part 8: Defining Confluence Design Templates With the setup completed in Jira and Confluence, I will probably add a second series called "Work processes in Confluence & Jira - From Need to Deploy" where we go through how to use the setup from a practical point of view. It will be a more generic process, so it can be used in any methodology with some minor tweaks. If anyone wants, I could also add a post about how to use the power of Jira and Confluence for programmers without ever leaving your IDE.

Is there anything you miss from this series that you feel I should add?

0

By 💫 Jimi Wikman · August 11, 20196 yr

In an article in the Swedish newspaper DN it is proclaimed that it is difficult to find successful managers, even if we spend a lot of money on leadership training. The research looked into middle management and could not find any scientific proof of increased success. This is not surprising since there are very few correlations between managers and leaders after all.
The article is critical towards the trend of managers taking classes to become better leaders. As leadership is not something you can learn I kind of agree with that, but at the same time anyone can improve the chances of becoming a leader if they know how to. By educating yourself on what a leader is and is not, then you can take steps to move towards leadership. This however is often wasted on managers as they are to far away from the employees to actually make much of difference.
There is also nothing wrong in not being a great leader. Managers that does not lead groups of people directly often do the "boring stuff". This includes budgets, resource planning, contract negotiations, stakeholder relations and a whole lot of sales discussions. This is not something that you need leadership skills for. You need authority and organization skills. This is an extremely important role to have.
I know several managers that are the absolute best in the world that I would never let lead a development team for example. They are exceptional managers, but no leaders. Then I know of a few managers that are not great managers, but great leaders. Lastly you have the saddest bunch of them all and that is the group that are amazing leaders that are terrible at management. These are completely wasted in a management position.
I know that saying that leaders and managers are not the same is not 100% true because they share certain traits. Regardless if you are a manager or a leader you need the ability to communicate and to have a clear message (even if it is wrong). Where a leader should inspire and lead by example a manager need to communicate a vision and a direction. Managers direct the workforce towards a goal and the leader makes sure the road to get there are enjoyable and productive.
So the fact that this study did not find any proof of successful leaders among middle management is kind of normal. Increased knowledge of leadership does not make management leaders. It makes them more understanding of leadership and hopefully it means that they will work better with the leaders. That in turn would improve the working conditions for the workforce if all goes well. If a middle manager would become a great leader then by definition it get isolated as that person often have others between themselves and the workforce. Those leaders can be bad leaders so even if the middle manager inspire them to greatness, it will not reach the workforce.
We should also recognize that most managers are completely buried in work and often are forced to content switching that cause stress. That alone prevent room to actually lead as they are jumping from one area to the next with little to no pause for reflection or processing. It is very difficult to develop any form of leadership skills in such environments. This is also a cause for poor decision making that we will discuss in another article.
To become a better leader require a profound change of self. This is not something that can be done by anyone else as you do not develop compassion and respect in a classroom. That comes from within as part of growth of self. This can be triggered by education of course, but the actual transformation happen within. If you are a greedy, self centered, performance driven individual with low empathy then no matter what you do you will never be a great leader. It is as simple as that.
Does this mean that the many leadership training's that exist out there are worthless? I do not think so. Understanding what good leadership is will make more people strive towards that. The fact that we see so many articles, training classes and blog posts about leadership is forcing organizations to evolve. We no longer accept bad leadership and especially in the IT world people will leave companies with bad leadership for companies with good leadership.
This put pressure on many organizations, but it is important to understand the difference between a manager and a leader. Today I think we mix them together and many managers feel that they are bad leaders. The thing is that this is ok, as long as they are great managers and they make sure all work forces have a great leader. This leader does not have to have a title, just the trust and respect of the work force they lead. If you have that and everyone understand the dynamic in the work force then things will be great for all involved.
In theory at least 🙂

0

By 💫 Jimi Wikman · August 9, 20196 yr

Seven years ago I met this young developer named Ornamo. Pretty fresh out of school there was something about him that made me think that this guy will go places. Today I see that I was right and still his journey has just started.
The thing that struck me back when we first met was his passion for code. It was not just something he did for work, it was something he really loved doing. He did code on his free time and every moment he looked at ways to improve. He was hungry and eager to become the best version of himself.
Our first years we mostly worked side by side. I had the seniority, but Ornamo had the skills. Even with my 15+ years experience in front end development, Ornamo was way ahead of me from the first time we met. Later on as I was pushed a bit into project management Ornamo was always the one I looked to for the role of architect and leadership.
I nudged him a bit here and there and pushed him to take on more responsibility and he just excelled every time. This just confirmed my feelings that Ornamo is destined for greater things. Not only is his skill set amazing, he works extremely well with everyone around him as well.
As most front end developers he understand the design process and the UX principles. In fact I think he could easily move into that field professionally if his love for code was not so strong. He is a natural leader without trying. People simply follow him because they want to rather than some artificial role give to him. This is something that I think will eventually lead Ornamo to the same path as I have been given when sooner or later he will become a more formal leader as a project manager or product owner.
I know few people that are as kind and generous as Ornamo is. He is loyal and respectful and will always give you his absolute best. He is diplomatic and is naturally attuned to the dynamics in any work group. Although he prefer to be in a position where he can learn from the other members of the team, he have no problem taking on the mentor hat and share everything he knows. There is no prestige or ego driving Ornamo, only constant improvement and making the best possible solutions.
So now, seven years since we first met, I no longer see a young developer in Ornamo. I see a man who not only have become a skilled professional that is well respected by his peers and his clients alike. A married man who I expect soon will not only be a loving husband, but also an amazing father. A successful man that in a very short time have impressed me beyond words.
I am deeply honored have the privilege to work side by side with a man that have a future ahead of him that is well beyond anything I could ever achieve. I have watched Ornamo grow with every challenge presented before him and I am certain that he will continue to grow for many, many years to come. Already today he is one of the most skilled and experienced front end developer I know.
Ornamo Antar is a true unicorn with a bright future that will be amazing to follow.

Learn more about Ornamo Antar on Linkedin:
https://www.linkedin.com/in/ornamoantar/

0

By 💫 Jimi Wikman · August 7, 20196 yr

Requirements are abused almost daily and it is a fact that most projects that fail miserably do so because the requirement process failed. Lets go over what requirements are and how to make sure you control the requirements and in doing so also control your project.
That is pretty much the summary of what a requirement is, but it's a bit more complicated than that as a requirement is made up of three different parts:
Business need - What people usually think a requirement is. Its a description of a need that should be fulfilled and it can come from the business or the end user perspective. The technical elaboration - The part that is most lacking and the cause for so many failed/costly projects. This takes the business need and extend it with the technical elaborations that make it possible to design or code the solution. The verification aspect - This part is where each part of the requirement is defined in a way that it can be verified with true or false statements. It ensures that the requirement have the right level of clarity. Once you break down the requirement in these three areas you will naturally see the need to involve the correct users in the requirement process. The business need comes from the product owner, who also own the requirement. The technical elaboration comes from the developers and the verification aspects comes from test.
Once the concept that a requirement is a trinity and not a simple request or wish, then you will have come a bit closer to how to get great requirements that are easy to work with and to understand, without having to spend endless hours to formalize them. You can focus on making sure each of the three parts get improved and making sure that there is a natural handover between the requirement phase and development where the development team approves the requirement instead of just inherit it.
In order for this to work there are some things you should make sure you either stop or start doing. Here is my list of some of these things:
Make sure you add business value to your requirements. Requirements cost money and I don't mean when they are being developed. The cost for elaborate on a requirement also cost money so do not waste money on requirements that does not provide a clear value for the product. Make sure you do not forget the "Why" in the user story! The Why often explain why the requirement exist and its what you compare against when deciding if a requirement is valuable enough to warrant the cost to realize it. Make sure you break down user stories to avoid huge requirements. It is easy to end up to high in a requirement, but you need to break it down so it's easy to understand and so it fit within one development period if you are in an agile work process. A requirement is NOT equal to development! There is no 1-1 relation between a requirement and development, just as there is no 1-1 relation between development and test. So unless you will start to write your requirements as a function specification do not expect development to be 1-1 with the user story. Don't refer to other requirements or share user story for multiple development. Each user story is atomic and should be able to survive on it's own completely independent of other user stories. Link to solution designs and things like that, but never to another requirement in order to explain the acceptance criteria. Don't describe solutions. It is up to the developer to decide on the proper technical solution and the requirement should refrain from describing solutions as the technical solution can change based on other development. Never add variables in a requirement by using words like and, or, with, approx. , etc. and so on. Make the requirement clear and free from interpretations. Never use indefinable terms like future proof, faster, user friendly, versatile or robust. Also refrain from using the term responsive as it's also open to interpretation. Don't ramble. Each acceptance criteria should be short and verifiable. If you feel the need to explain the acceptance criteria, then it's probably not properly defined yet. Make sure each acceptance criteria is verifiable. Think of them as check boxes that can be either true or false. If interpretation is needed then the acceptance criteria is not good enough. Make sure that most of the questions from the development team is answered. Instead of repeating the answers over and over, write them down. In order to get this make sure you involve the developers so they can ask the questions right away. Make sure the requirement take the work process in consideration. If you ask for a new component where you want to set a font color for example, then define how you would want to do that. There is a big different between getting a drop list of predefined colors, an input field for hex codes or a color wheel and it will affect your work process. Always let the developers approve the requirement. This ensures that they take over the responsibility and they verify that they understand what you want them to build. Once the development team have taken ownership never alter the requirement by adding or removing functionality. Only clarifications should be done at this stage or there will be mayhem and scope creep. Find the right level! There is no need to go bananas and spend weeks on a requirement unless the organisation need it to get the requirement properly defined. The better each of the three parts of the requirement become at defining the requirement, the faster it will go without loosing quality. You need to find that level where the requirement is optimal for your team. These are just some small notes on what you can do to improve the quality of requirements. I have worked with clients that knew nothing of requirements and did the Agile/Ad Hoc version where they never got a project out in time or on budget. Once properly trained they not only mastered the art of requirements, but they also managed to keep deadlines and budgets.
I aim to write a bit more about this topic later on, but perhaps there is a specific topic you would want me to address right away?

0

By 💫 Jimi Wikman · July 30, 20196 yr

As soon as you step into the office of a company you can sense what kind of company it is. It's in the decoration, in the way people dress, the body language and in the eyes of everyone working there. That is because great companies have great attitude that go beyond just doing great work. It's a passion and a love for what they do that no amount of skill or hard work can match.
I am sure you have felt it many times stepping into an office regardless of what business you are visiting: The stale and boring office where work is the only thing that matters where silent people stare at their computer screens with faces of stone that indicate a high performance company with little to no love for their employees. The bright and a little messy office where people talk and laugh, walking around with that enthusiastic light in the corner of the eye indicating a passionate company who cares about their employees.
It's a vibration in the air, a smell of freshness and a soft light that seem to be around everyone that works there. It is as if everyone is just full of life and creativity. It is in companies that can maintain that passion that you will find the best value because everyone will go out of their way to make sure their clients not only get what they think they want, but also that they get what they need.
It is also in these companies where change is always welcome and even encouraged. New ideas are born spontaneous without fear of rejection, no matter how silly or strange and everyone are open about their opinions on how things can be improved. This is where the employees come early and leave late and it's in companies like this where not all work is being charged because the people will work on it even when they are no longer at work. Not because they have to, but because they want to.
I have had the great fortune of working for several companies having this great attitude. I also work with clients that have this same great attitude and the thing that they all have in common is that its easy to make changes and people are passionate and willing to make things better. These are the companies that grow and become successful, not because of the products or services they sell, but because people will go above and beyond to make success happen.
I have also worked for companies that are the opposite. Stale and almost impossible to make changes happen, even if it's obvious to everyone that change is a necessity. Companies that treat people like numbers in a spreadsheet that use protocol and rules as ways to make others feel bad because they themselves are unhappy at work. The employees in these companies will never go the extra mile because they have learned that no one cares if they do and their passion have all but died inside them.
So the next time you consider doing business with another company think about what you want from that business arrangement. Do you want someone that will just give you want you ask of them even if it may not be the best solution, or do you want someone that will be passionate about giving you the best possible solution, even if it's not exactly what you ask for?
Do you want a silent grey production machine or someone that will work with you to get the best possible solution for your business?
Greatness is just around the corner, you just need to have the courage to go for it.

0

By 💫 Jimi Wikman · July 30, 20196 yr

As a leader, no matter if you are a business manager, project manager or team lead your job is to improve the team spirit of those that you lead. This can be done in many ways, but I have 3 quite fun ideas that I use in my projects to lift the spirit of my team.
When working in a project you go through many phases with your team and as you grow in to your role as a leader you will start to see the signs when your team is in need of a little energy boost or just need a soft break to smile more. This is when you can do small things that takes only a few minutes, but have great impact on the team.
The three things described here are designed to get the team to smile because smiles release tension and release a lot of positive things in your body. They are designed to not disrupt the work to much, while at the same time engage the whole team in one way or the other. They are also quite fun for you to do as well, which makes it a win-win for everyone.
---
Number one - The Post-it.
The post-it is a super easy way to provide a short appreciation for the team. Simply write a post-it for every team member with a few words of appreciation and then walk over to each and every one and paste it on their screen. I usually do this in complete silence to let the post-it do all the talking and place a hand on the shoulder or do a fist bump to make the words connect on a more personal level.
A short message like "You are awesome!" or "You Rock!" are all it takes as long as you show that you really mean it as well. In most projects these post-its stay on the screen or get moved to the wall next to the person you gave it to, making it a constant reminder that you appreciate their hard work.
Number two - Let there be cake!
Nothing says I appreciate your hard work like cake. I try to always buy cake for my team when a new sprint is about to start. It's a great way to show that you appreciate the teams work from last period, regardless of what happened and combined with some well chosen words you can solidify the feeling that you as a leader really appreciate and trust your team.
It also lift the spirit right there and then and I usually have a sprint startup where we go through the work for the coming sprint. With a bit of cake the team become more active (not just because of the sugar) and discussions improve a lot as people feel secure to lift problems and come up with solutions.
Cake can be substituted with pretty much anything that the team like and I almost always pay for it myself to show that this comes from me personally. Sometimes the cake can come from the client or from the company if it is necessary to improve connection with them instead of within the team.
Number three - The water game
This is probably the silliest and most challenging thing of the tree things in this list as it require preparation or fast and creative thinking. What you do is that you get water and something to drink out of for each of the team members. I started this as I wanted the team to drink more water, but to make it a bit more fun and to make the water feel a bit more special I started to make up a story for each member.
So instead of just getting water they got frozen tears from a Tibetan Yeti that had been transported by blind monks to the far east where they got melted in a golden bowl at the top of the pyramids during an eclipse before it was bottled up in sacred flasks and shipped to the team.
The result of this game if you get it right is that people will not just stop working for a few minutes to listen to your stories, but they will drink the water with a smile and ask for more. Its a fun and challenging way to keep your team hydrated and make people smile and laugh for a few minutes.
---
If you can get your team to smile and laugh for just a few minutes every day with you that will lift the spirit of your team and you as a leader will get closer to the people you lead. It is one of many ways to get people to follow you instead of just doing what you say because it show them that you care about them.
These tree suggestions only work if you do it with genuine care for the people you lead, but as a leader that should not be a problem. Once the team feel that you care about them, any fun thing you do will be appreciated, but if you have not made that connection yet then focus on that first.
I hope you will find these suggestions useful and fun and if you have suggestions yourself, please share so we can become better leaders with happier and more productive teams that love to come to work with us!

0

By 💫 Jimi Wikman · July 27, 20196 yr

In most projects there is that one perfect moment when you look up from your screen and observe the team you are leading only to realize that they no longer need you. It is both terrifying and absolutely the best moment you can have.
As a project manager I have my own style that comes from many aspects of my life. From my brief time in the military I bring my sense of protection of the people I lead and from my childhood upbringing I bring a desire to encourage and treat others with respect. On top of that I add a touch of my need to understand the things around me and a curiosity to learn new things.
These things make me be the first one to start the workday and the last one to close my laptop at night. It is also the reason I gladly spend hours upon hours to make sure everything is prepared before my team start their work. Not because I want to control their work, but because I deeply feel that my single purpose as project manager is to make their life easier.
In order to do that I will put my heart and soul into solving as many problems as possible before my team ever need to know that they exist. This so they can focus on the work at hand and on becoming more than just a group of people working together so they can become a team.
I do not control my team, because I trust them completely and because I know that they work better if I give them the tools to manage themselves. In the beginning I steer the the team towards a work process I have used before and then I encourage the team to make changes together so we fine tune the process based on the need of the team.
By focusing on their need and by making sure everyone feel that their voice is heard and respected the team grow towards a sense of unity. I give responsibilities and make sure everyone in the team is pushed a little bit beyond their abilities or comfort zone. Not to punish, but to help them grow as I am there to support and assist every step of the way should they feel insecure or have doubt.
Then somewhere along the course of the project that perfect moment will happen. Usually when sitting at my desk on the outskirt of the team as I try to make sure the team sit closely together with me on the outside. In that moment it is like the sound of the room will change and become almost inaudible and as you look around you see the team engaged in work, helping each other or discussing solutions together.
Instantly you feel that the team no longer need your guidance and you no longer need to help them find their place within the team. They are a team now and all the heard work to build that up is now over. There is a positive energy over the team and you will see them smile and laugh together and then returning to their work with an amazing focus and efficiency.
In that moment there is a pride in your heart that threaten to bring you to tears. Not because of your accomplishments, but for theirs. As a proud parent you will see the growth of each of the team members and you will see how they take on responsibilities because they want to, not because they have to. They respect and protect each other as a team.
It is in that moment you have accomplished the most important aspect of leading a group and that is that you have managed to make them all feel safe. Safe to speak their mind and safe to take on any task knowing that it is ok to fail and try again. Safe because everyone share the same vision and motivation and safe because that they all know that no matter what happen you will always be there for them and have their back should they need it.
While you are no longer needed to guide them and to help them become a team, they still need you to be there to support them. Your role will change from that point on and you will spend less time managing and more time leading. Your team will look to you for decisions and clarifications, but other than that they are from that point on more than capable of managing their work on their own without you.
It is truly one of the best feelings in the world.

0

By 💫 Jimi Wikman · December 24, 20169 yr

Personalization, omnichannel, SEO and SEM. These are the things you hear people spend tons of money on in 2016, but only recently have you started to hear more about UX. Unfortunately the term UX is used as some form of collective phrase for all things related to design and conversion optimization, which it is not.
When discussing UX you will almost always have conversation drifting into topics of visual design, Interaction Design (IxD) and of course Conversion Rate Optimization (CRO). Now this is fine because UX certainly are closely connected to these fields, but the problem is that no one seem to explain that they are just that: connected. Instead everything is just "UX", which leads to problem with expectation and actual result.
Lets start by breaking down what UX is and is not by defining the different aspects of a design:
Visual Design
There are many types of visual design and the most common for enterprise companies is the creative visual designer. This is because enterprise companies use creative agencies, even if there is no creative aspect of the visual design to begin with. A creative visual designer is an artist. The creations are all master pieces to be admired and praised and the format of advertisement and commercials are where the creative artist truly will shine.
E-commerce for example have very little creative freedom because it is limited in function and expectations from the users. To put a creative artist on the task of designing an E-commerce site is like asking Michelangelo to select the color palette for window frames and door dressings for 15.000 apartments in Los Angeles instead of doing the Sistine Chapel ceiling. It's a waste of time for the artiste and the result will be to complex for the purpose.
Instead you use a GUI designer with an expertise in the system you are designing for. Unlike the creative visual designer that will spend endless discussions on what font to use with what pantone so the kerning will amplify the shades of the fall collection the GUI designer will focus on usable design, best suited for the platform and purpose of the site.
The GUI designer will live in the borderline between visual design and the front end developer and they have a decent understanding of IxD and UX based on previous experience. There are no visual masterpieces created by GUI designers, but they are the true masters of making usable design that generate sales and clients love to browse their balanced and well constructed designs.
Interaction Design
The interaction designer is all about the interaction between the system and the user. The sole purpose of the work done by the IxD is to ensure the interaction is the best possible for the user so that person can get to where they want to go as fast and as easy as possible. In order to do this the IxD is armed to the teeth with tools to structure information and data, how to optimize search and navigation structures, if the target group prefer popups, slide ins or any other type of front end behavior to present information.
Unlike the visual designer colors, fonts and other visual aspects, are not an important aspect of the interaction process. So wireframes are the tools of the trade for an IxD, even if that is slowly making way for prototypes these days as it has many benefits beyond mere IxD.
User Experience
The UX designer is all about feelings, but not just any feelings: the users feelings. This is when the visual design come together with the interaction design in a way that is most appealing to the users. The UX process is all about finding out what the users want, what they need (that they might not even know they want) and then to adjust the visual and interaction to best fit that need.
The UX designer spend lots of time identifying and understanding the users so they can form that emotional bond that make it possible to make the best possible experience for them. The tools for the UX designer are all about communication and psychology so interviews, think aloud testing, eye tracking and analytics are all part of the UX designers arsenal as well as a sound understanding of color psychology and the ways the human brain interact with the digital world.
Conversion Rate Optimization
The Conversion Rate Optimizer is all about psychology. The CRO expert build on top of the IxD and UX designers work and they dig deeply into the more advanced areas of visual design and of course the greatest tool of all CRO masters: the communication between the user and the site called tonality.
Things like the reciprocity, directional cues and copywriting are heavily mixed with psychology such as color psychology and the Gestalt Laws. Behavior patterns and content management become target for optimization where each funnel is examined and dissected to find the optimal flow with the optimal design and optimal tonality.
Conversion rate optimization in itself have many, many different flavors. Some CRO are experts in getting forms to convert, others are experts in structure and trust while others are experts in SEO/SEM returns or Email campaigns.
Get the right designer for 2017
So what kind of designer do you need for 2017, really? It all depend on where you are in your design cycle. Most sites already have a design, flawed as it might be, but instead of spending millions on a redesign, which will most likely just cost you money unless you do it right, I suggest you consider the three steps building blocks of a great design.
Interaction Design - Ensures that the site CAN be used. User Experience Design - Ensures that that people WANT to use the site. Conversion Rate Optimization - Ensures that people WILL use the site. I would say that 75% of all E-commerce are in dire need of an IxD. That is because so many sites still struggle with site structure and interaction. To many have fallen for the lure of using a creative designer and are stuck with a design that the user do not understand how to use or that is not actually usable at all.
20% of all E-commerce sites have a structure that the users can use, but the design lack pleasure and clarity and for that reason a UX designer is needed. This is where magic happens almost daily and it's a wonderful time for a site user to bond with the users to truly begin to understand them.
Only 5% are in the state where they have the structural stability and easy usage focused on the right user group and it's these 5% that are in the exciting phase of Conversion Rate Optimization. This is when a site truly enter a golden area and exceptionally few sites ever reach this state.
Regardless of where you are in your design you should seriously look at your site today and ask yourself this:
Do you know who you are building your site for and have you confirmed this with actual data so you know that is actually true? Are your content such as images, texts and visuals communicating with those people in the way that is appropriate for that target group and have you verified that with data as well? Will your site win awards for ease of use if your visitors would vote for your site honestly every time they visited your site and have you confirmed that with the users? Is there anything about your site you are not 100% satisfied with and is it safe to say that your users will feel the same as you? Do you want to make more money and have happier clients in 2017 by taking care of questions 1-4 as well of hundreds others that affect your sales and customer satisfaction? If the answer for #5 is yes, then I suggest you take a long look into your budget and consider not wasting money on SEO/SEM or redesign efforts before you have a serious look at your UX and CRO, because if you read all of this I assume you are dedicated enough to already have done your IxD work...
...am I correct?

0

By 💫 Jimi Wikman · August 27, 20169 yr

UX design, visual design, interaction design, creative technologist, GUI designer, usability consultant, information architect. The titles are endless these days and as someone who work with all of these pretty much every day I am starting to wonder if we are breaking things down to much these days, or if it is actually necessary to get things done?
10 years ago most of these titles were pretty uncommon, at least compared to the way they are used today. They still existed, they just were not as clearly defined and separated as they are today. Most just called themselves "designer" and that was pretty much ok.
When I had my own design business there was no distinction between a visual designer or a UX designer for example because without the knowledge of one you can not do the job of another.
Without knowing the information structure and the technical limitation of the platform I am designing for, I can not set the interaction design. Without the interaction design I can not set the UX and without the UX I can not set the visual design. It's not quite that linear as they all blend on multiple levels, but you get the idea.
So for me these things are always connected and maybe that is why I never felt comfortable focusing on just one area. How can I best help a client if I do not understand the whole picture? How can I create a solution without understanding everything from psychology to visual principles to information architecture and interaction patterns in the different touch points in a customer journey?
As the fields expand rapidly, just as they do for front end development, the information flow becomes almost unmanageable. Is this perhaps the reason why we see people that proclaim to be UX designers, visual designers or interaction designers? Or is it just that they still are "designers", but just focus on one area of expertise more than the other fields?
Unfortunately I see a division, just like the division happening for the front end developers, where we have designers that put the creative power of the visual design as their only craft and others with the intellectual focus of interaction and psychology as a separate craft.
I have been in projects where this division have worked fine and I have been in projects where this does absolutely does not work at all. It all depends on the people and the methodology where communication is always the key.
As we dig deeper into the psychology of design and user behavior, for the web in general and e-commerce in particular, does this mean that it become to difficult to stay on top of the development in all these fields so a division of discipline is required?
The tools we use suggest the opposite however and the borders between visual deign, interaction/UX design and even code becomes more and more blurred. So from a technical point of view we move towards where I was 10-15 years ago where you are doing just "design".
As of now I am not really sure what is the best way moving forward. Is it better to have very focused individuals that form teams to get the full width of the design process? Or is it better to have less focused individuals that can handle the full range of disciplines on their own? What does this mean for methodologies and work processes, does it matter at all?
What are your thoughts on this matter? What direction do you think we are headed and how do you feel about that?

0

Setup Jira and Confluence - Part 2: Defining and setting up Jira Issue Types

Setup Jira and Confluence - Part 1: Defining the tools

Setup Jira and Confluence - Introduction to setting up Jira & Confluence for success

It is hard to find successful managers according to science

7 years working with Ornamo Antar

15 tips to master requirements to avoid scope creep and costly delays

Great companies have great attitude!

3 fun ways to improve team spirit

The perfect moment of being a Project Manager

Will 2017 be the year when we get serious about UX and CRO?

Are We Overcomplicating Design?

Categories

My Articles Filters

My Latest Articles

True Agility comes from structure and clarity

The Agile Manifesto - 25 years later

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

Capacity planning and capacity reporting in the Atlassian platform

How to manage projects the right way based on contract types

Latest Community articles

Affordable Linux Dedicated Servers for Businesses | High Performance

Dedicated & Cloud Server Hosting Experts | 24x7 Support

Benefits of Using ReactJS for Your Web Development Project

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

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

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

Account

Navigation

Search

Configure browser push notifications

Chrome (Android)

Chrome (Desktop)

Safari (iOS 16.4+)

Safari (macOS)

Edge (Android)

Edge (Desktop)

Firefox (Android)

Firefox (Desktop)