My Articles Community Articles Guest Writing

My Articles

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

Ways of Working,

As the summer end and we are slowly crawling back to work from a long time working from home, people will start looking at new ways to work. Again. New buzzwords like mixed workplaces and work anywhere will mix with things like SAFe and Tribes, all driven from top management that need something new to call things. Here is the thing, though... You don't need it. Because the work has not changed and your need for control is due to a lack of trust. So let me explain why the processes are identical all over the world and how rituals may vary to improve them.
Process of making software and development.
I have to admit that I am constantly amazed over how little people understand the process of making software and develop things. Almost everywhere I go, people are so focused on the rituals that they seem completely unaware of the overlying process. Instead, they talk about Agile, Lean, SAFe and other rituals as if they were the process to make code. They are not. They are rituals on different levels. Their purpose is to add naming and rituals to the overlying process. The problem is that without understanding the process, they are just small pieces of a larger puzzle that more often than not, does not fit with other puzzle pieces.
So what is this overlying process, or master process if you will? It is the steps every development must go through, regardless of size. That is what a process is, after all. A series of activities that you repeat over and over. What are these steps then that you always take, and how can they work regardless of scale? Let us define them and see if you agree with me.

Ideation
Ideation usually involve visual design or some technical design, but it can also be feedback on the current solution. The purpose is to form some idea of something that can create value. I do not mean value for the end users, but for the company. This is an important distinction because some rituals only talk about end user value, which is actually irrelevant unless that lead to value creating for the company. This is also why some rituals are completely separated, or ignore the finance part of the process. The ideation part can be a very small tweak, a feature, a project or even a new product.
Definition
Once an idea has been formed, we define what the idea is. We do this with the purpose to make a cost and risk analysis to see if the idea can create enough value to be developed. This involves not just design and management, but input is also required from development and test to get complexity and high level estimates. Again, scale does not matter here, as we do the same for any level with more detailed work required the larger the scale becomes.
Finance
In this part, we match the value creation with cost of creation. Many rituals ignore this step and place it implicit on the role that own the financial responsibility. At large scale this has its own rituals like project planning and portfolio management, but even for small features or even tweaks we always make a cost benefit analysis. Or we should at least.
Specification
In the specification phase, we ensure that everyone involved understand what to build. We also set the rules for how to verify and accept. Again we make this at any scale where at the smallest level this might just be a verbal confirmation and an update to documentation, while in others it can be hundreds of hours of workshop and documentation. The aim is always the same: to ensure we understand each other and know how to verify that we have done things according to the need.
Realization
This is where we take the specification and realize it. Depending on our definition of done, we document what we build with the purpose to keep records of the system, so others can build upon the work.
Verification
In this phase, we verify that the specification has been fulfilled. That is all. If something fail to meet the specification, then it is returned to Realization in the form of a defect, or in large scale circumstanses, as contractual issues.
Acceptance
In the acceptance phase, we approve the development based on the specification, but we also try to determine if the specification was the right one. In the case that the specification did not yield the correct result, we can add new things into the ideation phase to correct. Making the wrong specification is not a fault of the realization, so it can not be defects.In large scale situations this is a contractual issue that is managed as a contactual conflict.
Presentation
The presentation phase is when the idea is finally presented to the end users. Usually this is done by releasing code to a production environment, but it can be done in various ways depending on the product.
Maintenance
This is the last step in the process where problems are managed within the build and presentation phases. This step can be either a time limited one, such as a post go-live support period, or it can be as a part of a maintenance project. Regardless, this phase is a bit different as it has a predefined finance attached to it and it only deals with problems such as incidents and repeating problems.

You always go through these phases
It does not matter at what level you are, you always go through these phases. This is why you will feel pain when your way of working skip one or more of these steps, and in my experience it almost always happen to be Finance, Specification and Acceptance at the lower levels. This is almost always based on the rituals, however, where misinterpretation of Agile along with poor definition of management responsibilities seem to be the biggest reason as I have seen it.
You can do some very small things to adjust this, however, ranging from a small checklist to a more detailed process mapping on need. A checklist can easily be done with just a few questions, where we just verify each phase to ensure we have not skipped any of them.
What is your idea? Is it technically feasible? How difficult would it be to realize it in terms of time and risk? Will the idea generate more value than it cost to realize it? Is this idea more important than other ideas in terms of priority? Do you understand what I want, and can you realize it within the time we have set? Is what we have realized in accordance with the specification? Are the end users happy with what we have presented? --- Maintenance below is usually a bit on the side --- Are there any problems that need to be taken care of?
Define the inputs and outputs
If you want to make this a more reliable process, then the next step is to have a set of workshops with each group to define requirements of input and output. Anyone who have spent time defining work processes have probably touched on this, but usually this is a top-down process where you focus on rituals, not the actual process.
I can not tell you how many times I have sat down with people who are very skilled with processes only to see completely blank faces when asking what the requirements for the input is from the developers. They never tend to get that far down, as they start at the top with finance and portfolio management down to maybe project management.
My suggestion is to start with the part where you will make the biggest impact, and that is at the bottom. If you shave off 10 hours a month for every project manager, that might seem to be a huge win. Until you compare it with shaving off 30 minutes of time for every developer and tester. In one company I worked for, I made an extremely low estimate that they lost more than one hundred million Swedish crowns every year due to lacking in the verification part alone. In the whole work process, they probably lost more than 10 times that...
Start with the Testers
NOTE: Depending on your organization and your rituals, you may have people with multiple roles. That is ok as long as they are clear on what role they are representing in each workshop. It may be required that you direct them from time to time if they drift to another role.
So I always start with the testers. This is because despite them being very important in the process, they rarely get to be involved where they should be. This is the same as for design, but their impact is less on the overall process since they exist in the ideation and specification parts. The format for this workshop is quite simple. Put a group of testers of different levels in a room, put up a square on a blackboard or big piece of paper with one side marked as "Input", the other side as "Output" and on the bottom you add "Dependencies".
Divide the group into 3-5 people each and ask them to write post-it's for each of the three sides. Input is what do you need to do your job, Output is what do you deliver to acceptance and dependencies are things that can affect your job. Give the group 20 minutes to write these things down, put it on the square. After 20 minutes, go over the notes together and define what the testers need to do their job, what their definition of done is and what dependencies they have.
The next step is to move over to the work process and discuss in what phase they see themselves participating and what their role is there. Rinse and repeat, but limit the time to 10 minutes for each phase, since most should already be up on the big square. Discuss again and create multiple squares, one for each phase.
NOTE: If you want, you can take this opportunity to define roles and responsibilities at the same time, or keep this for a separate session.
Then move on to the Developers
The next step is to talk to the developers with a similar exercise, but at the end bring up the testers requirements. The aim here is to match the developer's output with the input of the testers. This will show the gap between expectations of these groups, which you can then discuss. From this exercise, you might need to go back to the testers and make a separate gap analysis with them, and in some cases you might need to bring both groups together to get the gap closed properly.
Move on to the business side next
While it would make sense to take the Specification phase next we purposely skip that and lump the business aspekts into one big session. The aim for this session is to identify and separate the large scale aspects of the business side since we will handle them separately. So we try to focus the sesion on two parts: project management and line work. As both work with fixed budgets this allow us to focus on what input is needed to make good finanical decisions and how to prioritize.
In this session we focus on the Definition and Finance phase to get the input needed from Ideation and how that support the financial decisions. In this case we start with Finance, even if it comes last in the chain. That is because it is usually easier to define what input is needed in order to make financial decision. That will make the definition phase easier to define as well.
The trick for this workshop is to avoid getting into discussion of rituals. How decisions are made, in what cadence or what the decisions are called is irrelevant. The only thing that is important is what information is required to make decisions. If your organization have rituals that require you to submit a form-501 for change request that include a certain financial code, then that is a ritual, not a part of a process. Just note that down as that you need financial information about billing recipients and a dependecy to the portfolio process, or whatever is relevant to your organization.
Once you know what information you need to make informed decisions, then it is time to talk about the definition phase. How do we get the information we need from the Ideation phase may sound easy, but this is where things get a bit tricky. On one hand you want the perfect information for financial decisions, but on the other hand you don't want a 3 day documentation process to submit new ideas. So this is where the participants will get a bit frustrated, because we will kill their darlings.
That is right, we will take the requirements they made for the Financial phase and we will do a YAGNI excercise on it. Yagni stands for "You Ain't Going to Need It" and we will use that to mark all data we previously marked as input to the Financial phase. The aim is to remove as much as possible, or rather to simplify to the point where we can take good decisions without to much risk.
This can be a very tricky exercise if your organization have low trust, but it is crucial for you to get a proper process.
Bring Specification to the table
We now move on to the most crucial part of the process: The Specification Phase. This is the zone between the business parts and the realization parts. As such it is the most fragile part and it is prone to a lot of confusion within most organizations. This is why we take this after we do the Finance and Development phases.
Since we now have the requirements from the Development side and we have the expected outputs from the Finance and Definition side we have a starting point. In this workshop I tend to add multiple groups because we need Developent, Test as well as Design and Finance since they are the one that need to understand each other.
I tend to start with defining the purpose of the Specification phase first so everyone is on the same page.
The main purpse of Specification (Requirements) is to ensure everyone knows what the definition of done is. Specifications are legally binding. Payment is made based on them and defects are verified by them. Not all Specifications will be Realized (financial backloop) Specifications are historical records. With that in mind we can now start discussing the input and output of this phase. You will most likely see that there is a big gap here and that roles such as project managers, requirement analysts and product owners will express concern because the requirements on their job is much higher than they thought. You will most likely aslo see a big change in attitude from the development and test when the people on the business side start to realise just how much time these two groups spend chasing information that should have come from the Specification phase.
In this workshop it is important that we do not fall into a WE vs THEM situation. This can sometimes happen if the gap between the business side and the realization side is very big. If this happen, remind everyone that we are not there to complain on what is missing, but to collaborate to find ways to add things that we need. Together.
You probably also need to explain to the visual designers that they are part of two phases, the Ideation and the Specification. Many do not know the difference and they often think everything is exploration and ideation, which of course is not true. In the Specification phase we talk about design guides and approved design specifications, nothing else.
Mind the Gap(s) and sign the process.
With this we have pretty much defined all aspects of the process with input and outputs. You may have noticed that there are some phases that we have not covered yet, but don't worry. We actually have covered all the phases, but we just have not had workshops for all of them yet.
Ideation have an expected output from the Definition phase. The Acceptance actually get their expected input from Specification since that is what they will accept towards. This is also true for Maintenance that will focus on Incidents and repeated problems that both have to be defined in the Specification.
That leaves us with Presentation that is the phase where we deploy to production and release it to the end users. Since this usually does not entail a lot of requirements more than knowing what to release and when, there are situations where a more defined process is required. if this is the case for your organization, then follow the same workshop setup as the other ones and map input, output and dependencies.
Once you have all phases done you need to check for gaps that might still exist. So ask everyone that have participated in the workshops to verify their phases, but don't just ask for a thumbs up. Request that they fomally sign a decision document where they say they approve the definitions as they are stated. This is very hard in organizations that handle approvals through a consensus decision ritual rather than a formal decision ritual, but I suggest you insist. Not only will it make everyone take responsibility and thereby look a bit extra, it also visualize that someone actually have thought these things through!
That is something that is far more important than you think.
Brace yourself, change is coming!
Once a process is set everyone will examine it and they will apply their opinions to it. This is natural and it is a good thing, if you can manage it. Change for the sake of keeping things the way they are should be shut down as soon as it comes up. Change that improve the process should always be encouraged. Sometimes the way things are will fall into the category where it improves the process and if that happens improvements always win.
One thing you will notice is that everyone who bring forward thoughts on the process do so from a position of wanting to improve things. No one ever want to make things worse. Because they do not understand the process, or the difference between process and ritual however, they will make suggestions that are making things more bloated and complex. This is because they are blurring the lines between process and ritual and if you are not careful you will end up with a custom made ritual and that can be very expensive.
So what I do is I make a proper channel for input of great ideas. Each channel is tied to one of the process phases and each phase have a group that receive and review these changes. If a change is beneficial for everyone in that phase, then it is implemented into the process. If it is not, then it will not be included in the process. The key here is to make sure that the groups that are responsible for the input and output are the only groups that can approve or deny changes to that process phase.
Remember that the process itself rarely need any changes, but the rituals often require many and frequent updates.
How we use the Process with Rituals
Before I answer that we need to define what Rituals are. In my definition Rituals are a set of nomenclature (set of words), activities and roles. They can exist to cover one phase in the process, or multiple ones. They can also exist on different heirarchies, or scale, such as strategic and operative. They all have the same benefit and problem and that is that while they provide a unified way to discuss around things, they rarely play well with other rituals and they quickly grow to be bloated and encumbersome.
So if we take an operative ritual such as Agile for example, then we know that it is not designed to work on a strategic level. We would then use that preferrably on a line work setup where we have a defined budget, but not a defined scope. For this setup we would then take our process and use it to ensure we get all the input and output done correctly as part of the retrospective.
We can also easily see where the ritual have their weakpoints. Agile for example is high in Ideation and Definition is done collaborative as a parallell ritual. The weakest point of Agile is Specification because Agile is usually more verbal than documenting. So we define together how specification fit within the Agile ritual and add that to our definition of done.
By doing this we can easily discover shortcomings of our way of working with Agile, by examining output and input to ensure we don't miss anything. We can also make small adjustments to the ritual where there are gaps.
Is this overkill for small companies?
Not at all. Understanding what you do and how your work relates to the overall picture is very useful. I almost always hear people asking the same questions in every organization I work: what is expected of me? Even having this as a two hour exercise in a single team will make you work much better together. There is no size limit for when understanding expectations on you and the work you do stop being useful.
It seems very hard to do.
I assure you it is not.
Anyone can do this because even in worst case scenario you will still have had a healthy discussion on expectations in a pretty fun and interesting workshop. This workshop also doubles as a team excercise and an excellent opportunity to bring up problems and issues that may otherwise be difficult to raise.
The tricky part is to find the right level for the input and output. If you take the input for Realization for example one requirement is of course to understand what I am supposed to build. That is to generic so we define that in more detail so we say that for visual elements I need a design or wireframe as the minimum, or referral to components if you work with that. I also need acceptance criterias so I can verify my work. Perhaps I have dependencies to instructions on how the system works or code standards so I know how to write my code.
If you do not get it right the first time around, don't worry to much. You can always iterate and improve when needed.

Defining a process is a great starting point
Once you have a process that you can use as a base of what you do on a daily basis, then you have a very good start. It is very much the foundation upon which you can build your Taj Mahal of work processes that will make your employees create new wonders for the world to see with joy and serenity in their hearts.
So don't focus on interior decoration first, it will just be a bunch of fancy named furnitures thrown into the mud.
It is easier than you think!

By 💫 Jimi Wikman in Ways of working · July 30, 20214 yr

0 comments
1,237 views

Security,

IT management software vendor Kaseya whose VSA software platform is used by other tech companies to monitor and manage customers’ IT networks, has been the victim of an audacious cyberattack. On July 2, the business issued a security advisory urging its customers to immediately shut down versions of VSA running on their own servers. It also suspended its own cloud-based VSA service.
Kaseya VSA is a remote management platform for MSPs that provides solutions such as automated patch management. According to Kaseya, the platform has been used by more than 36,000 MSP customers worldwide.
"Beginning around mid-day (EST/US) on Friday, July 2, 2021, Kaseya's Incident Response team learned of a potential security incident involving our VSA software," the company's CEO Fred Voccola said in a statement shared late Friday.
Kaseya's official recommendation is to:"IMMEDIATELY shutdown your VSA server until you receive further notice from us."
This attack already has compromised eight of Kaseya's MSP customers with 200 businesses linked to three of the victims reporting instances of file encryption. This Reddit post from huntresslabs show the progress of sorting out how to fix this ransomeware attack.
On Friday, Mark Loman, a malware analyst at security firm Sophos, tweeted the hackers demanded $5 million as ransom in exchange for the file decryptor. Image comes from thehackernews.com.

This seems to be quite nasty and here in Sweden it has affected one of our chain of groceries stores as they are unable to make payments due to this affecting their cashiers. In the US hundreds of companies have been affected and it is safe to assume that many companies in the EU and elsewhere might be affected as well.

By 💫 Jimi Wikman in Ways of working · July 3, 20214 yr

0 comments
981 views

Security,

If you have the "Print Spooler" service enabled (which is the default), it means that anyone with access can execute code as SYSTEM against the Windows domain controller. At present, there is no patch from Microsoft. So take a break from your vacation and turn off the service immediately.
From Tenable's blog:
E5GOlYUXwAUyqzU.mp4
More information from Microsoft: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-1675

By + Kryptera.se in Ways of working · July 3, 20214 yr

0 comments
829 views

Development,

Atomic Design, or Functional Design as it is also referenced, is a bit of a weird beast. On one hand, it is a programmatic shorthand feature that allow you to use short code in development that then render CSS based on that, but it also a philosophy of sorts on how to organize CSS. A philosophy that very much resemble the inline-css era of old.
The problem statement
I think this statement says a lot on how ACSS and to some degree Atomic Design itself see the world of CSS. Anyone working with wild or free CSS development can certainly recognize some of these pain points. This is not uncommon in scenarios where many developers work in the same project or you have to work on top of a not so well-designed product.
The question is, though, how many still work in that way and why?
In a scenario where you have a defined design pattern, which should be the norm these days, this is rarely an issue. Regardless if you do atomic design or component design, your styles should be easy to maintain and define. Despite this I still see a lot of JS developers adopt inline styling and duplication of CSS in components. This is more common in libraries like React and Angular, I feel (personal experience, no real numbers to support that).
So it is not surprising to see a rise in areas like Atomic Design or ACSS since that help bridge the gap in skill levels some JS developers have and the inherent despise we have to spend more time than we have to on things we don't really enjoy doing. Not to mention, there are some benefits that should not be overlooked.
ACSS - Atomic Design as a preprocessor
ACSS is a preprocessor that will transform inline HTML variables and create CSS from it. It has a fairly simple syntax and it works by looping though the HTML and scrape up the variables and then make a CSS file from what it finds. In many ways, this is similar to inline CSS, but you would get a static CSS file instead of just printing it out in a style tag.
If we borrow an example from the excellent CSS-Tricks site that I highly recommend you check out, then here is a snippet of code where we declare some classes and input a variable to each.
<div class="Bgc(#0280ae) C(#fff) P(20px)">Lorem ipsum</div>The output from this would then generate the following CSS:
.Bgc$#0280ae$ { background-color: #0280ae; }.C$#fff$ { color: #fff; }.P$20px$ { padding: 20px; }This may seem quite useless compared to a well-defined CSS with variables declared that I could just input, but you could use both of course and use this to override in certain situations. Similar to how you would use inline styling.
The biggest benefit of this however is that the CSS generated would be as small as you could make it. This is because the CSS would be based only on what can be found in the HTML. This can be useful for development in for example Angular and React, where I assume this is mostly used.
In situations where you have classes reused over many components, like this website however, that would not really be as beneficial as having multiple CSS files is never a good thing and you would see duplication of classes. This is of course if you generate the CSS on a modular basis, but not if you render it globally on load somehow.
Overall, I do not see any need for me working with sites like Invision Community and I feel it would not really work well in an atomic design situation with defined styles in both the UI and the HTML/CSS that is reused across components.
I may be completely wrong about that, as I have not tried it and if so, sign off in the comments to tell me I am wrong 🙂

Atomic Design as a Philosophy
The idea of Atomic CSS is simple and, to be honest, not very new. The idea is to create single attribute classes and then stuff the HTML with them. Kind of like you would do using Inline styling, but with a global definition of the styles. It would look something like this.
/* naming utility classes */.relative {position: relative;}.mt10 {margin-top: 10px;}.pb10 {padding-bottom: 10px;}I say that this is nothing new because this has been around since before inline styling even existed. One reason it is not widely used is because it makes the HTML cluttered and hard to read. It is also a bit annoying to work with compared to having well-defined CSS classes as you will have a ton of attribute shortcuts basically rather than a library of styles.
If you are used to working with frameworks like bootstrap, then you are already familiar with the concept, since those frameworks also have libraries of smaller styles that you can mix and match. Atomic CSS is much smaller however and rather than having for example a flexbox class that have the standard values you use all over the site you have to build those up with a set of classes inline in the HTML.
Is it a terrible idea?
Atomic design as a concept can be traced back to October 2013 and an article written by Thierry Koblenz. It has since evolved and you will often see it in reference from the new breed of JS developers that work in frameworks like React and Angular. While it may be a bit unfair to say that these new JS developers do not have that same deep understanding of CSS as the "regular" front end developers, I do see this distinction growing.
For the JS developers however, this is pretty useful as they can focus on function rather than form. You have probably seen the mess that sometimes happen when JS developers mix inline styling, component specific styling and global styling. It is as bad as having multiple novis CSS developers trying to use EM when they do not control the output containers...
I hear some arguments that this makes it easier to avoid specificity issues, but I do not agree with that. If you control your code, then you are a pretty bad developer if you can't handle your classes properly. It all comes down to planning and setting structures after all, unless you are just playing around like I do on this site.
I digress though and to answer the question if this is a terrible idea I think there are use cases for when this can be useful. Since that article in 2013 however, I think those use cases are less now, especially with the introduction of CSS variables. I do however think there is a very good case for using this same idea for defining variables and to keep your classes small as a philosophy.
I do think there are certain scenarios where it is a good idea to use the concept of Atomic design, and that is for overrides. Things like fonts, colors and spacing can be useful to sometimes just make a small adjustment rather than building new components.
Also, if you generate your content at runtime on the server, there are benefits to this since you can combine it with CSS-in-JS to dynamically generate very small CSS files. I guess this is why React and Angular developers are liking this way to organize your CSS classes. You can still do this working with regular CSS, but the files will be bigger since you are bound to have duplicate attributes in your classes.
So it is not a terrible idea, but it comes with some issues.
Allow me to explain...
My Thoughts
While there are benefits in some cases, there are some negatives as well. The biggest issue for me is that while we reduce the CSS, we instead increase the size of the HTML. The HTML also becomes much more cluttered and harder to read because unlike CSS where we can group classes, or even split them on multiple files, HTML will just be one big garbled mess.
Consistency is also an issue because the idea of recreate clusters of classes to achieve the components is done manually every time, then you will see consistency go out the window. We see this all the time in wild or free CSS, where pretty much every component have its own class styles uniquely. This is especially problematic if you have JS developers that are not very good at using CSS and you try to set up a design library.
At the end of the day however, front-end developers are flexible and resourceful people. All of these potential pitfalls can be managed and if Atomic CSS works for you and those that you collaborate with, then go for it. Just don't make the decision just in the development team as you need to work well with both Design and Test so they should have a say as well. Also, your way of working must work across teams, so don't start using Atomic CSS if you at any time will have other teams working in the code as well.
You know all that of course, but it is something that you can never repeat too many times.

Do you use Atomic Design today?
If you do, what benefits and pitfalls have you uncovered?

By 💫 Jimi Wikman in Ways of working · June 27, 20214 yr

0 comments
1,204 views

Ways of Working,

If you work in IT, you have probably heard the words projects and maintenance many times. Usually it is in reference to different teams and organizations, but not always. Sometimes the same team can do both projects and maintenance, which can cause some confusion. To add to that confusion, you will sometimes hear the word line work as well. As these all see to be a bit malleable, it can cause some annoyance. With this article, I hope we can make a definition so we all know what we are talking about.
These are all financial constructs
Before we begin, let us define what these three terms refer to, since they are sometimes confused with processes or even methods. Projects, maintenance and line work are all financial constructs. This means that they exist as a way to manage budgets and resources. In most cases, projects and maintenance exist together and form sequential ways of working (waterfall, RUP and so on) while line work is the basis for iterative forms of working (Agile). This is also reflected in their financing where projects and maintenance mostly have fixed budgets and scope, while line work have fixed budgets, but scope is more loosely defined against value themes.
Project
A project is usually the easiest to define of the three. This is because most of the work in IT are still project based, so most people still work in projects. Projects are by their very nature sequential, meaning that they follow a step-by-step process to get funding and approval based on certain values. These values are often defined as features, but in some cases it can be other types of values. The difference between projects and line work is however that value need to be measurable and once set it normally can not be changed.
Projects are defined as time limited bubbles of time, scope and resources that can span across different borders such as systems, organizations and even companies. When this happens, the project is split between the different areas and placed under an umbrella structure we call program. This makes projects the easiest form of financial structure to organize when you need to span multiple areas.
Most companies that have been around a while also have a strong culture of organizing external resources around temporary work as projects as well. This is usually well-defined in their vendor management structure as well. This is why projects are the most common form of financial construct in most companies.

Maintenance
One of the most misused term of these three as it is often used for anything that is not project based. It also comes in two very different forms based on how contracts are defined in Vendor management.
At its core, maintenance is nothing more than making sure the systems are working properly once a project has ended. This means that as a project ends, there will be a list of items that need to be taken care of, usually in the form of known bugs and technical debt. After the handover, maintenance handle unexpected incidents in production, problems and in some cases it also includes enhancements such as refactoring to make the system more stable.
In some cases the maintenance get to work right after a release. This is when contracts are written without post go-live support, meaning that as soon as a delivery is accepted and released, the team in charge of the development no longer are responsible. This is often an awkward situation where the maintenance team and the development team can start to resent each other if there are a lot of incidents being released to production due to poor testing and acceptance processes.
All of this is handled in a service management process that is matched against a contract with SLA and a budget for the work to manage the system or systems. This is often paid for by the product owner(s) or a business area within the organization on an annual basis, which is often managed through maintenance plans.
Unlike project and line work, maintenance are not generating new value. The purpose of Maintenance is to maintain value, or to correct loss of value due to problems and incidents.

Line work (line organization)
If you have ever worked in maintenance where you also do development for new features as part of your work, then you are probably in some form of line organization doing line work. The term refers to a manufacture line where you continuously build things. Unlike a manufacture line, where you do the same thing all the time, line work in this context refer to continuous improvement when it comes to development.
Line work, just like maintenance, usually have an annual budget. Unlike maintenance where the goal is to maintain value, line work have the same aim to produce new value in the same way as projects. In line work, however, this value is usually defined in terms of focus areas, or themes, and larger goals rather than defined ones as you have in a project. This makes line work better suited for exploratory work such where value creation is iterated based on result.
Line work often employ a flexible workforce, allowing them to quickly adjust resources based on need. This also works well for larger initiatives where the flexible workforce simply expand their numbers for a period of time and then shrink again. This however require a different way of handling vendor management and contracts as you can not define them around deliveries, but rather against value creation.

The confusing mix
It does not really matter what form your financial construct have, because at the end of the day you will adjust your preferred way of working anyway. You can work in an Agile methodology within a project and you can do waterfall in a line work setup. There will be challenges of course, but people do it every day all over the world.
It is when things get mixed up you start to get problems. This usually happen with line work and maintenance, or projects and line work.
Anytime you hear that maintenance also should so development of new features, then you are fading into a mixed situation, or are moving towards line work. This is confusing because you mix the concept of not generating new value in maintenance with creating new value as in line work, but without the flexibility in financing. This can cause headache, not just for managing the budget, but also because maintenance usually do not have a requirement process defined. The situation can be fixed however by moving over to a line work setup instead.
The most common situation however is when projects try to mix fixed time and scope with exploratory methodologies. This is often done by implementing a sequential scrum methodology and an ad-hoc requirement process. Scope creep are very common and frustration high from confusing requirements and trying to iterate value within a confined time frame with fixed budged and deliverables. The solution for this is usually to focus on requirements to reduce the ad-hoc situation and try to iterate within the limitations presented in a more flexible way, rather than agile.

I hope this helps
As I see these terms used on a daily basis and sometimes in a very confusing way, I hope this definition helps. If you disagree with my definition, feel free to write a comment and we can discuss things. If you like this article, or better yet, find it useful, a comment or like is always welcome 🙂

By 💫 Jimi Wikman in Ways of working · June 8, 20214 yr

0 comments
1,543 views

Employment, Professional,

We have all been in those interviews where the interviewer completely botch the interview. Weird IQ tests, being asked to do design or code on the fly or questions that are irrelevant to the work at hand. Sometimes it may even be that the interviewer is completely the wrong type for the interview and so on. In this article I will list my five top interviewer tips for interviewers to land that awesome employee contract for a senior IT or design person.
Tip #1 - You are the one that have to sell the position
Surprisingly many interviewers have the attitude that they are doing the potential employee a favor by letting them come to an interview. This may be true for other types of work, but professional IT people are in very high demand and for a senior person it really is their market, not yours.
So if you come from another field where there are more people to hire than there are positions, you need to adjust that mindset. Otherwise, you will have a very hard time attracting people or worse, keeping them.
People that are junior or new to the field often bend over backwards to land a job at a prestige filled company, but most seniors have already filled their CV/Portfolio and are done with the backfilling process where you endure crappy jobs just to build a CV/portfolio.
These people know that they can afford to be picky, both in terms of job descriptions, workplace satisfaction and of course salary. You often compete with a dozen or more other companies for a senior employee.
So rather than asking them to prove to you that they have what it takes, you need to prove to them that you are worthy of their time. That is quite different compared to dealing with junior employees or recruitment in other fields.

Tip #2 Don't waste their time
Unless you are offering someone's dream job that you know they will do anything to secure, don't waste their time. Asking a senior employee to do code tasks or design tasks to "prove" their worth is a sure way to turn many applicants away. The only people that will put up with that kind of nonsense are people that are unemployed or are still building up a CV/Portfolio.
If you are looking for a senior employee, they will rarely put in extra work just to get to an interview. They have other options that don't require them to work for free anymore. Besides, they can easily pay someone a few bucks to do that assignment for them anyway, so it is kind of pointless from a validation perspective anyway.
If you want to verify someone's skill, then just have another senior developer in the interview and have them go over some code or design together in a think aloud fashion. The other senior employee will pretty easily spot if the person know what they are talking about or not.
Just be mindful that a lot of people get brain freeze during interviews, so this should not be your only interview point.
IQ tests and personality tests are not uncommon either and I would strongly advise you not to use those. Most people don't like these kinds of test and they are likely to drop you as a potential employer because of that. They also do not really give you any information that is beneficial for your decision to employ or not.
I kind of enjoy doing these, but that is because I already know my IQ is high and I have done a lot of personality tests so I know what to expect from them. Others don't like this kind of surprises as much though...
If you want to have a psychological test that is actually beneficial, then you should look into the dark trinity traits, but then you are diving into a whole different set of pitfalls and problems.

Tip #3 - Do your homework
Just as the person you interview will do their homework to look up your company and it's values, you should also do your homework. I don't mean that standard homework to make sure the person you employ is not a hateful bigot or a criminal, you should also try to find out as much as you can about the person.
Introverts and extroverts are quite different in terms of what they need and how the information you present should be done. Introverts often prefer more structure and information as bullet points with clear decisions and distinctions. Extroverts often like conversation and more visual information and so on.
Some people are social hotspots and can chat up rocks, while others are less comfortable and prefer others to lead the conversation. Knowing what type you are meeting allow you to design the meetings accordingly.
Knowing things like hobbies, passions and peeves can help you connect far easier, even with more closed people. It also offers a way to make the person you are interviewing to feel more familiar and comfortable.
If you have someone close to you that know the person you are about to interview, talk to them and ask them about the person beforehand. This will help you tremendously in your interview.

Tip #4 - Represent your culture
I have seen this a few times when the person doing the interview is not a good representative of the company culture. It can be that you have a company that is all about the people in the company and making a difference in the world that has a recruiter that look and behave like a sneaky car salesman. Or it can be a sales oriented company that is all about winning and celebrating victories where the recruiter is all about caring and making the world a better place.
The problem you face if your style does not match the company culture will most likely happen later in the process where the potential employee will meet other people in the organization. Or it will happen after employment which often lead to that person leaving very soon, or become a source of negativity in the work place.
So make sure you adjust your interview technique and your look to fit the culture and values of the company you represent. As you are often the first point of contact, your impression will be crucial in landing the right kind of employees that will fit into the company's values and culture.

Tip #5 - Don't brag about hiring people to fill a quota
It's not that common for people like me that are white males, but I have seen it and heard about this way too many times. No one want to be told that the reason you are called to an interview is because of your age, gender, race or your sexuality. Also, no one like to hear that they did not get a job because another applicant was of the preferred "type" and you were not.
I know that it is generally a good idea to make sure you have many types of people in a company and I love working with people from all walks of life, but never, ever, discuss this during interviews! It is offensive and in many countries even illegal to discriminate in such way.
If you have two applicants that are equal in qualifications and you like both, then it is up to you which one you want to hire and adding more diversity is almost always a good idea. If however one applicant have better qualifications and you still hire someone else based on other things than their qualifications, then you are digging your own grave.
Not only are you discriminating people, but you are also making the life of the person you hire difficult as other employees will notice that that person is less qualified than her role demands. This leads to friction and envy from other employees and the person you hired will suffer more from that feeling of being a fraud and not good enough.
Be fair and hire the best applicant, regardless of other qualifications not related to work. There are plenty of amazing people of all "types" out there, if that is your goal.

Don't be a bigot.
This is not a tip, it's common sense. Or at least it should be. I know a lot of people that feel that they must change their name to get work due to bigotry. So if you discard applicants based on name or how they appear in a photo, then you are an idiot. And a bigot.
Not only will you must definitely miss out on some amazing employees, you also put constraints on your business because you will miss so many amazing points of views and experiences.
I have worked with people from all over the world and it has been the best experience you can imagine. I have worked with Jews, Muslims, Christians, Buddhists and other religions. I have worked with people from all political affiliations as well as people from the whole rainbow of sexuality (almost). I have worked with disabled people that have taught me more about my work than I could ever have imagined.
I have worked with people from simple and poor backgrounds and people from rich backgrounds. I have worked with people that could not read a book if their life depended on it, but they can build anything with their hands. I have worked with people that could not handle a tool if their life depended on it, but who could solve any problem with their mind.
Some of the most amazing people I have worked with have been from other countries such as Lebanon, Morocco, Vietnam, Syria, Germany, Croatia and India to mention a few. I have learned so much from these people that goes beyond work and as someone as work in a male dominated field I constantly have my mind blown by amazing women that can see things differently than I can.
I can tell you from experience that being afraid to the point where you get prejudiced is normal. We all fear what we don't know or understand. The best way to break that is to take a leap of faith and get to know the things you fear and more often than not you will find that the prejudice you have are wrong.
So don't be a bigot.
Be Awesome.

By 💫 Jimi Wikman in Professional · May 23, 20214 yr

0 comments
1,106 views

Management, Ways of Working,

Employees don’t leave organizations, They leave bad bosses. We have all heard it and we all probably have a bad boss experience or two in our career. But what is a bad boss really? Are they just terrible monsters that tear organizations apart, or are they just people like you and me?
Just as people are different, so are our perception of what a bad boss is. What I consider to be a bad boss, may not be a bad boss to you. It all depend on who we are as individuals and what we currently need. Regardless of who we are though there are three mental types that everyone dislikes and those are psychopaths, narcissists and machiavellians. This is how Birgit Schyn, Barbara Wisse and Stacey Sanders describe these types in their article Shady Strategic Behavior: Recognizing Strategic Followership of Dark Triad Followers:
“Narcissists have a strong sense of entitlement and a constant need for attention and admiration. They are arrogant and consider themselves to be superior to others. “Machiavellians are sly, deceptive, distrusting, and manipulative. They are characterized by cynical and misanthropic beliefs, callousness, a striving for … money, power, and status, and the use of cunning influence tactics. In contrast to narcissists, Machiavellians do not necessarily have to be the center of attention and are satisfied with the role of puppeteer, unobtrusively pulling the strings.
Psychopaths “are unlikely to consider the needs and wishes of others and are unafraid of crossing moral boundaries. … By creating chaos in the organization, as well as in coworkers’ personal lives, they can pursue personal agendas without detection. They do not only enjoy hurting people, they strategically use humiliation and bullying to direct other people’s attention away from their hidden selfish activities. … psychopaths are often viewed as the most malevolent ones of the Dark Triad.”
We call these collectively Dark Triad personalities and when you encounter them there is very little you can do but to leave the organization. These are not bad bosses, they are bad people with mental issues that can hurt you, so stay away from them whenever possible.
These are not the bad bosses we are looking for however, because there is another group, that is far more difficult to handle than the Dark Triad bosses. I am of course talking about the Sudden Asshole Bosses and the Micro Management Boss. These are people that actually are very good people, but they suffer from insecurities and inexperience as leaders.
These are usually people that others like because they are caring, well-spoken and often action driven people that listens and take care of problems in a way that make everyone happy. Then when they get appointed to a leadership perspective they change overnight to become a controlling asshole of a boss.
Why do good people become bad bosses?
My personal experiences and observations is that this happens to new and inexperienced people due to a shift in the direction of care. By that I mean that as an employee my direction of care is usually towards my co-workers. That would be the other employees. As a person moves up and become a manager you have new responsibilities to people above you in the hierarchy. That means that you naturally shift your direction of care upwards.
This is nothing bad, but if you add stress and the feeling of not being a hundred percent sure of what you are supposed to do as a manager, then the need for control start to take over. As we know stress does not help with maintaining a kind a generous disposition, so that does not really help the situation either.
We also tend to adopt behavior from those that we work with. If a new manager are unfortunate to have others around them that belong to the Dark Triad, or that have fallen into the trap of micromanagement, then it becomes natural to be drawn into that. This is not because they want to be bad bosses, but because they need something to cling to as managers very rarely get any leadership training before they are tossed into the new roles as managers.
People that feel insecure, or that are in a position where they feel they have to live up to certain expectations due to their gender, religion, sexuality or race, they are more prone to this in my experience. Not because they are any worse or better than others, but because they fear failure or letting down others more. Fear is a great motivator, unfortunately it often motivates good people to become bad bosses...
How do we get bad bosses to become good bosses?
Most Sudden Assholes and Micro Managers tend to get over the initial shock of becoming a manager. With time, they will again shift their direction of care to the people they are in charge of. They will learn how to navigate the minefield of leadership and distance themselves from behavior that is detrimental to the people under their care. They will also realize that micromanagement is not a healthy or sustainable way of working and as they feel more secure in their roles as leaders that need will dissipate.
As people feel more secure they will also realize that the very reason they were chosen for leadership in the first place was because they are awesome. More often than not it is also because they add something to the company that is missing. For this reason it does not make sense to conform to what already exist. Many leaders blossom greatly when they realize this and a lot of people transcend from bad bosses to amazing bosses.
For some however the bad boss attitudes get stuck. These are people that need help to break free from the bad boss loop. In my experience there are three things that seem to work well on most people:
Time - One of the bane of new managers is stress. Helping your manager to reduce stress is a great way to help them get over the hurdles of transition from bad boss to great boss. Be proactive in providing information and take care of problems and you will quickly see a transition in attitude.
Proximity - Being away from the people you are supposed to lead make bad bosses feel more connected to other bad bosses instead of the people you are responsible for. Break this by asking the bad boss to spend more time with the team. Don't let them hide in a closed room, bring them out in the open and in close proximity of the team. The bonds will naturally reforge with the team and the bad influence from other bad bosses will be reduced.
Respect - Even if you are getting treated like crap and you are frustrated, show respect to your boss. Remember that they are probably struggling badly with things you have no idea of and with a show of respect you can ease that stress. Also remember that they are human and that the goal is to help them over the speed bumps of being a bad boss so they can become great bosses. Showing respect reduce their insecurities and remind them how awesome you are as well. I am not saying this is easy or even feasible in some cases, but just remember that bosses are people just like you and me and they have things going on in their lives you probably have no idea of.
I know of one middle manager that was pretty much ambushed by several teams that gave him hell for almost 30 minutes before he broke down crying and told them that he had cancer and did not know how to deal with that.
A woman I read about a while back was struggling because she was gay and was afraid that people would find out and she would be fired, only to find that everyone already suspected it and loved her regardless.
Some are struggling with addiction, others with family issues such as divorces or deaths in the family. Some are struggling with bigotry from higher up in the company, some have asshole bosses of their own to deal with. Others may have illnesses or suffer from anxiety. There are a million reasons why someone may behave poorly in certain times of their lives.
Just be open to the possibility that bad bosses may just be amazing bosses trapped inside their insecurities, bad company and a stressed out mind.
You may hold the key they need to break free.

By 💫 Jimi Wikman in Ways of working · May 14, 20214 yr

0 comments
1,112 views

Ways of Working,

Value stream management, probably most noticeably introduced as a part of the SAFe framework in nothing new. It is a simple visualization of the value creation process connected to the financial aspects. In short, it is a way to organize work based on finance and perceived value to the end user. This approach is another top-down version and as such it comes with both positive aspects and negatives. If handled correctly it can be mostly positive however.
Let us begin by setting the stage for what Value Streams actually are: artificial constructs designed to match value with cost. In a sense that is the same as a line organization that continuously create value, but with a specific value in mind that is not tied to IT structures such as systems.
This is where the first problem usually start to show itself: what is value and to whom?
If you have spent any time with Agile or Lean evangelists then you know they will talk about the end users experience as the one and only metric of importance. I find that to be a naive and narrow point of view because as a company you are in the business of making money. That means that the metrics that matters is what do we benefit from as a company. In order for the company to benefit you usually want end user satisfaction, but it is not the only metric.
There is no benefit for the company if the end user is satisfied, but the company lose money because of it.
In order to set any form of metric to measure value you need multiple perspectives and this is very difficult when you have experts that either focus on end user satisfaction or company profit. The answer is in the middle, but very few companies have the capability to bridge the gap and find that value.
Defining what value is
What happens is that value often are defined in services rather than value. Customer support for example or E-commerce. In some cases it even is split into business areas such as countries or brands. Neither is probably what constitute a value stream, but then again value streams are artificial constructs that still are very poorly defined other than "what drives value" in a typical theoretical abstract manner.
My advice for this is to define what value are you driving and how will the company benefit from it. This is something almost all companies already have as it is a part of Portfolio management. Everything that you have a budget for already have value creation as part of the metrics used to motivate the funding. The only thing you need to do is to take your portfolio and sort the items in there into recurring areas. You can do that with a simple card sorting activity because if you work with Portfolio management you probably already have this in place in a way and you just need to challenge the structure a bit.
It is worth mentioning that value streams are not organizations or departments. They are time limited artificial structures that you should treat as long term project or programs. Eventually these value streams will change, in fact you should have a process to re-evaluate value streams annually or at least bi-annually to verify that the value creation are still in line with what you expect from a value stream.
Value Streams live on top of systems
This is as true for Value Streams as it is for programs and projects. All IT organizations are system based and no matter what financial body you place above it should live above the system structure. What I mean by that is that each system should have one truth when it comes to documentation and competence. So financial bodies that touch the system will "borrow" competence from that system and they will share documentation with other financial bodies that touch that system. This prevents fragmentation of information and duplication of technical roles such as architects and test.
It is common that when you define value streams that you will define entire systems as part of that value stream. This makes sharing systems less of an issue, but you should still keep in mind that the value stream is more or less hiring that system to deliver value and that other can, and usually will, have reason to pass through that system as well.
Measuring Value. Actual value.
When you start working with the value stream you will have certain things that you measure to see how well you deliver value. If you have defined the value correctly as suggested above, then you will get multiple points of value to combine into the actual value. This is where it is common that companies realize that they do not have the tools to actually collect the metrics. In some cases they get the metrics, but do not know how to combine them into actual value.
My advice here is to make sure that you define value the same throughout the company. Don't use arbitrary points of measurement like t-shirt size or story points because they will be useless at scale. You also need to measure cost, for real. Most companies only start to measure cost after the requirement phase, which provide a very skewed perspective as there are a lot of costs involved in defining a need.
So start measuring all aspects of the processes before the need hit the development team and you will probably be amazed about how much time is spent defining the need. Ideation, meetings, workshop, decisions, estimations, technical solution design and requirement analysis easily add up to 50-500 hours of work for even small needs. I have seen features that added only a visual effect on the side with negligible value cost well above $50.000 just in meeting costs to argue about the correct implementation.
You also need a way to translate other arbitrary measurements such as customer satisfaction into something useful. Hopefully you already have a template for this if you work with ROI from CRO, or at least you have some way to measure how an increased customer satisfaction also increase profit for the company.
When you measure actual value and not just a part of the value creation, then you usually will have very different results than if you only measure single points.
Value Streams. For real.
Like I said, value streams are nothing new and most organizations already have it based on either financial value or customer value. The trick is to combine the two into value streams that give you the real answer to the big question: what creates value for the company and how do we improve that.
Combining soft values such as feelings with hard values such as money is no easy feat however. As you dive into the esoteric and abstract world to try to combine the intangible with hard realities you should expect to fail initially. There are no magic formulas for working with value streams, which is why you should be aware that this will probably be a very expensive exercise of futility unless you truly commit to making it work.
If you commit and you find that sweet spot between measuring too much and not measuring enough, then I firmly believe you will have a big advantage compared to your competitors. If you also work with predictive activities to test theories before you commit to them, use predictive data analysis and engage with the end users to drive decisions, then you are a winner, regardless of what field your business operates in.
Just don't throw in Value Stream Management as some form of magic bullet, because it is not.
You will not be the best in the world by adding a new way of training, you still need to put in the hard work. This is true for sports and it is true for business processes as well. You do the work and you commit to it. Or you fail.
Commit, or fail.

By 💫 Jimi Wikman in Ways of working · April 18, 20214 yr

0 comments
1,026 views

Employment, Marketing,

LinkedIn has recently announced some additions to their services that has been received with some skepticism. While I understand the thought behind adding a more permanent version of Stories and the debated gender pronouns, I don't think it will benefit the users. The only change I really liked was the Live Broadcaster showing the broadcast in the banner.
Pronouns

Pronouns are heavily debated all over the world, even if it is mostly affecting lives of people in the US and Canada it seems. While I see why adding it can be a good thing for those that think these things are important, I fear they will add another roadblock for gender fluid individuals. I know for a fact that some companies will not hire anyone putting anything other than he or she in there. I also know for a fact that some companies will not hire anyone with he or she in there, but they are far less if I should venture a guess.

Cover Stories
Video cover stories is next and it is an extension of the existing stories. The current stories only exist for a day, but Cover Stories are supposed to be a more permanent. It is kind of the old video presentations that was popular back in the days. Until it turned out that people were discarded as candidates based on physical attributes before anyone even looked at their resume. I fear this will have a similar effect and I see several people already have addressed this and how it goes against the trend of having less identifiable data to determine the best candidates.

Live Broadcaster
Now this was a pretty cool feature, even if it may not be the ultimate experience for anyone wanting to view a broadcast. Whenever you broadcast your banner in your profile will start showing your broadcast instead of the image. Not only does in look cool, but hopefully it will draw some people to your broadcast. I hope this also will bring in more people trying out broadcast.

My Thoughts
Will these new feature make it easier to get a job or find new candidates? No, it will not. It will be nice toys for people that are already doing great at interviews and for people who love video presentations. In some areas where presentation skills are important it will add value, but in every area where the job is to focus and build things it will probably not be very useful.
Pronouns are something I still don't understand how it is supposed to work as it is arbitrary labels that can not be discerned visually, making them kind of pointless unless you already know the person. It makes a lot of people uncomfortable and I think it will be something that can lead to exclusion or getting hired based on virtue signalling. Neither of those options will do the gender fluid any favors.
I also think that some companies might demand that their employees either add video and/or pronouns, or forbid them. This is because both can add or reduce the chance of getting contracts for the companies. That can cause some bad situations and cause discomfort among the employees.

On the upside you have a great new tool to promote yourself using video. This is great for some groups and I think a lot of people will love to add that to their otherwise dry resume. It is also a great way for young people that don't have a resume yet to still show their enthusiasm and their passion for their chosen field.
For anyone who really feel that pronouns are important it is great that this feature now is added. I know that some people will feel a great relief over this and to be honest, what harm can it possibly do if it is voluntary? If it helps the gender fluid community feel more at ease, then I am all for it.
The Live Broadcaster feature...yeah, it is all good.

While I do see some concerns for these features I think it is great that LinkedIn experiment. Try out new features and see which ones are appreciated and which ones that are not. As they are optional it gives the users the power to decide what they want to use and what they don't want to use, which is great.
Overall I give these changes 2 thumbs up and some fingers crossed that they will work out fine for the people that use them and that they will improve the chances of finding work instead of the opposite.
What are your thoughts?

By 💫 Jimi Wikman in Professional · April 2, 20214 yr

0 comments
1,169 views

Yesterday I got a mail announcing that Insight, the powerful CMDB tool from Mindville that was recently acquired by Atlassian is going to be included in the Jira Service Management Premium & Enterprise plans. This is a huge announcement and I very much look forward to seeing this rolled out in the coming weeks.
If you don't know what Mindville Insight is then you can check it out here. In short, it is a tool that allow you to manage all your assets and configuration items in an easy to overview database. With the connection to Jira Service Management and Jira Software Insight give you all the information you need in one overview.
We will write more about Insight later to show you it's many features.

By 💫 Jimi Wikman in Atlassian · April 1, 20214 yr

0 comments
1,087 views

Atlassian recently announced a reboot of their Jira Core, which was practically unused by everyone due to its lack of unique features. The reboot comes with a new name, Jira Work Management, and a new setup focused on business teams. This is a great change and it will make Jira a bit more interesting for business teams in the future.
Four views to rule them all
Jira Work Management focuses around three main views: Board, List View, Timeline and Calendar. There are of course other features as well, such as a form builder experience as in Jira Service Management and the ability to pick a background color. The focus is on these four views however and they will determine how the business teams will react to this reboot.
The List View

The list view will appeal to anyone who spend a lot of time in Excel, or if you use something like Asana or Tasks in Teams. Inline editing and individual settings for the visual changes are big selling points, even if I foresee a bit of confusion when the views differ from user to user.

Timeline View

The timeline view is pretty much a slightly watered down version of the Roadmaps feature in Jira Software. It will work well for team level, just like Roadmaps in Jira Software, but not much more.

Calendar view

The Calendar view is nice, even though I am not so sure how useful it actually is. if we could tie it to our tasks in Outlook, then maybe the calendar would be more useful, but for now I think it will be more of a glance tool, just like the list and timeline views. I could be wrong though and I would need to try it out to test it out for real.

Board View

The board view is the only view that existed in Jira Core as well and it looks pretty much the same. This is very similar to Trello and it will be a nice alternative to Teams that are used quite a lot for this kind of view for many business projects.
Conclusion
The four views will pretty much satisfy most need from a business team, but my question is how these boards will tie in with the steering products Advanced Roadmaps and Align? I see this as a common theme with Atlassian lately with the same concern for Next-Gen projects and so on. It's something I will bring up in another article though.

Introducing Forms

It is interesting to see that forms are moving out from Jira Service Management as a way to create input and display forms. I think this will probably show up in Next-gen projects down the road as well. It is a good change and I think it makes perfect sense to make input and output presentation in this way.

Background color

Adding a background color to your project will not make or break the customers' appreciation of it, but it is a nice icing on the cake. I don't see what the point is to restrict to standard colors when you could just add a color option to the surrounding text as well and let users add whatever color they want. I foresee images coming soon as well, just as for Trello.

So why do you want this?
Adding business teams into Jira are a good thing. Earlier it has been a bit difficult to convince them to join, but I think that the List View will be a big selling point to be honest. Maybe even the Calendar, even if I am not seeing it at the moment.
Having the business teams in Jira means that you can bring in a lot of processes that currently live outside of Jira. This will allow easy management of early project/program planning, procurement processes, staffing, legal and security management and not to mention brick and mortar projects such as store building.
This is of course the first release of Jira Work Management and it will very likely evolve quite a bit in the coming year or so. For now, it is also free for all Jira owners, so once you get access to it, I suggest you take some time to check it out and see what it can do for you and your organization.
You can sign up on the waiting list here:
https://www.atlassian.com/software/jira/work-management

By 💫 Jimi Wikman in Atlassian · March 23, 20214 yr

0 comments
1,127 views

As organizations grow it will always increase the number of middle managers to stay organized. If the organization assign the wrong type of managers you may notice that that number start to grow a lot. You may also notice that the level of trust that exist between the different areas drop as well. This is what I call The Proxy Organization, and it is very damaging for your company.
Every organization forms a hierarchy. This is how we make sense of the world around us. We define structures such as responsibilities and mandates to make sure we know our place in the organization. In an organization where these structures start to be confusing or poorly defined you often see the number of people between the leaders and the people that make things happen grow. This is because not only is it very difficult to handle a poorly defined workload, you also start to have meetings for everything. Not to take decisions, but to form consensus since it is not clear who should take the decisions.
The more meetings you have, the less time you have to think about what happen in the meetings and the more help you need to go to more meetings. And so you enter into a running organization. Meetings happen all day and without time to reflect you start to make poor decisions and reduce time to communicate outside the meetings. So you hire more people to handle that, but soon they also get sucked into the meetings, and they need to hire more people.
As these people start to get more and more stressed they feel the need to attend more and more meetings to keep up to date with everything that happens. As stress sets in the need for control grow. We introduce KPI's that are designed, not to make teams work better together, but to make the team accountable if anything goes wrong. We implement restrictions and control points in our systems to "ensure" people work "correct". Morale drops and segregation begin to foster a "we vs them" attitude.
Slowly the organization split into silos, and we have more managers than people actually working. The managers spend all their time forming a biological proxy network with a single purpose to receive and send information in the endless meetings. People start to get sick from stress and start to leave the organization as the distance between the workers and leadership is made up of dozens of proxy positions all focused on control from a top-down perspective.

Sound familiar?
This is a very common thing as companies grow, and it is actually not that hard to turn around. It will require a lot of effort, and it will take time, but you will save a ton of money long term and most importantly you will stop hurting your staff.

Step 1: Define roles.
The first thing you should always do is define the roles in your organization. Make sure all roles are clearly defined, following a standard that is the same in all areas of the company. Don't make up roles like scrum manager or other combined roles. Stick to proper roles that are the same across the globe. You are not unique, so stop making up unicorns because you don't live in an imaginary fantasy world. Define responsibilities and mandates for all roles, so everyone knows what is expected of them.
To avoid a situation where you pretty much play the whisper game and just forward information you define what input and output for each role. Every role should have some value passed in the output that is higher than the value they receive in the input. If the role does not add value, then consider why that role exists in the first place. If it actually reduces the value, then remove that role.
In this step you should also match the role definition with the skill and experience of the manager(s) that hold that role. You will often find that you have the wrong person in certain roles, and you should try to match the roles with the people to get the best result. Never put a manager in a position on the merit of being with the company a long time. That is not the right experience to promote.

Step 2: Define decision processes
Endless meetings often come from poorly defined decision processes. So set clear decision processes that either comes as part of the portfolio process, or inside the teams if the team and product owner are given mandate. If everyone knows what need to be decided and the process to get that decision, the number of meetings are reduced drastically.
Defining the decision processes also prevent "ghost projects" that are driven in isolation without coordination elsewhere in the organization.

Step 3: Define information flows
One of the reasons why proxy organizations exist is because the information flow is poor. By that I do not mean that you don't have information flowing, I mean that it is difficult to get the information you need. This is just as common with an overwhelming information flow as with an underwhelming one.
Make sure that information is properly classified, so it is easy to find the type of information each person need or is interested in. Also make sure you make the information easy to overview with short snippets that I can drill down if I want. Lastly make sure the information is both sent in regular intervals when it is information that affect the whole organization, but also, so I can subscribe to get information of my choosing.
If you do this right, then confusion and uncertainty is reduced. This lead to less stress and better decisions from everyone as they are better informed.

Step 4: Define Meeting guidelines
In a proxy organization meets are used as crutches by managers that are afraid to take decisions. Either because they don't understand what they are supposed to take a decision on, or because they feel unsure on their mandate, so they seek to get as much approval from others as possible.
In Step 1 you make sure that you have the right people in the right position. This alone will help mitigate the endless meeting syndrome. Next you require every meeting to have a set agenda, what outcome should come from the meeting and most importantly a cost for the meeting. This will discourage meetings that are not really necessary, or that people that actually just want to have control join without having any impact on the desired outcome.
The last thing to do in this step is to set limit on meetings. If all you do is going to meetings, then what do you actually produce in value? Everyone need time between meetings to reflect and take care of the actions undoubtedly coming up in the meetings. Enforce 30 minutes waiting between meetings and 2 periods each week with 2-4 hours of consecutive meeting free time. Sometimes it can be a good idea to have this hard blocked in the calendar for everyone in the company, especially during the change process.

Step 5 : Introduce bottom-up evaluations
In most organization evaluations of people's performance within the organization is done top-down. To best understand the performance of the people in your organization you should also have the opposite represented. As a manager your job is to ensure that those below you in the hierarchy have what they need to be successful. In a Proxy organization this is often forgotten and a blame and punish attitude is used towards those below you in order to look good to those above you. This should be removed and introducing bottom-up evaluations is a good way to do that.
This should be done often as a way to determine where in the organization people are running off to meetings instead of taking care of their people. It will also indicate where you have the wrong people in place or where people have too much responsibility to manage.

Don't think you can change your organization "organically"
While these five steps seem easy to implement they are not. This is not something you can throw into your organization in the form of "read this article and make it happen" kind of activity. This is something you need an organized change management process for, and it will cost money and time. As with all change you must commit to it and pay the price short term to enjoy the benefits long term.
It will hurt, and it will not be an easy journey to stop running in an eternal meetings based proxy organization, but it will be worth it. If not for the financial gain, then for the well-being of the people.

By 💫 Jimi Wikman in Ways of working · February 14, 20214 yr

0 comments
1,332 views

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

💫 Jimi Wikman · September 27Sep 27

If you work in the IT industry, or similar industries, you probably have struggled with project management. Not only to execute them, but also how to define them to the customers when drafting contracts and work breakdown structures (wbs). I see this all the time, and the core reason is a misunderstanding on what a project is and when something is NOT a project. The second problem I see is that people treat everything the same in terms of responsibilities and execution, which causes a lot of pro
- project management
- Ways of Working,
💫 Jimi Wikman

September 27Sep 27

💫 Jimi Wikman

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

💫 Jimi Wikman · September 10Sep 10

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

September 10Sep 10

💫 Jimi Wikman

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

💫 Jimi Wikman · June 23Jun 23

After almost a decade of complaining about the misaligned term "Jira Project" that does not fit what it actually represents, Atlassian FINALLY announced that the term will change to Jira Spaces. I have known about this for a while, but now that it is finally revealed publicly, I can rejoice and celebrate this change fully. For those of you that don't know what the fuss is about, the term Project has never really fit the work we do in Jira, as the majority of work for most organizations are conti
- Atlassian, Jira, Jira Service Management, Jira Product Discovery,
💫 Jimi Wikman

June 23Jun 23

💫 Jimi Wikman

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

💫 Jimi Wikman · May 29May 29

Every organization have communication plans. Every team communicate all the time, both internally and externally with those they collaborate. We talk, email, chat and have video calls all day in an endless stream of communication. Yet we continuously fail in our work. Even though we praise Agile as the savior to fix the problems, or put project management tools to align and manage things... we still fail. Projects never get done on time or budget. People still sit frustrated and confused, tryin
- communication
- reqirements
- Requirements, Ways of Working,
💫 Jimi Wikman

May 29May 29

💫 Jimi Wikman

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

💫 Jimi Wikman · March 24Mar 24

If you spend any time in the ecosystem of work processes, methodologies and frameworks you have undoubtedly encountered people that claim that one way or another is the only way to do things and if you disagree, then you are stupid, uneducated or even evil. These are the fanatics bordering on cultists clinging to one way to rule all ways and there is little point arguing with such people, unless you like me enjoy a bit of an argument just to see what their point of view actually is. There is of
- Psychology, Ways of Working,
💫 Jimi Wikman

March 24Mar 24

💫 Jimi Wikman

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

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

°selena emani · February 3, 20232 yr

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

February 3, 20232 yr

💫 Jimi Wikman

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

+ Erma Winter · January 20, 20223 yr

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

January 20, 20223 yr

+ Erma Winter

January 20, 20223 yr
- 0 comments
- 50 views

Sign In

My Articles

Rituals and Processes - How to make them work, for real

Criticial Ransomware Incident - Massive cyberattact through tech provider Kaseya

Serious vulnerability in Windows Print Spooler "Print Nightmare"

Atomic CSS - what is it and is it useful?

Project, Maintenance or Line Work - what is the difference and does it matter?

5 interviewer tips - for landing a senior employee

The bad boss - what is a bad boss and what can you do about it?

Value Stream Management - another top down approach to ROI?

Linkedin adds pronouns and video - is it really what we need?

Insight free with JSM Premium - Jira Service Management just got a lot better!

jira work management Jira Work Management - What is it and why do you want it?

The Proxy Organization - five ways to battle a wasteful culture

Categories

My Latest Articles

How to manage projects the right way based on contract types

Atlassian Data Center is officially ending on March 28, 2029

Atlassian renames Jira Project to Jira Spaces

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

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

Latest Community articles

Benefits of Using ReactJS for Your Web Development Project

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

Who's Online (See full list)

Account

Navigation

Search

Configure browser push notifications

Chrome (Android)

Chrome (Desktop)

Safari (iOS 16.4+)

Safari (macOS)

Edge (Android)

Edge (Desktop)

Firefox (Android)

Firefox (Desktop)