Professional

15 articles in this category

The Problematic Epic - the undefined term that cause confusion
Epic. It sounds so cool and people love to use it. It is that bucket of undefined things that is just...large, that we love to throw things into and proclaim that it is an Epic. But what is an epic? There lies the problem, because the term Epic is defined in many ways in different methodologies and in different levels of the organization. This makes the Epic arbitrary and confusing, because the value of the epic depends on the context, which is rarely known.
Most people are familiar with the Epic through a tool like Jira or ServiceNow. These systems have adapted the Agile, or rather the Scrum, which defines an Epic as "a big chunk of work, which can be divided down to smaller bits". Atlassian, the makers of Jira, takes that a bit further:
So in both examples it is something big that can be broken down. In other words, it is something that has not yet been broken down fully and remain a bit vague because of that. This vague definition of something big, cause all kinds of problems, especially if what the Epics are broken down to are poorly defined.
In Jira for example you have a Story (Not User Story as defined on their website. A User Story is related to Requirements, not tasks), which in the best case will be defined as some form of work that can be done within an iteration (sprint most commonly). This means that you can have pretty much any size of task in a story, and it can be anywhere from full features to a small configuration.
Since much work starts on the business side even in Jira, then it is very common to have the Jira Epic turning into a Portfolio Epic...
 
Portfolio Epics in SAFe.
If we go up a bit within the Agile sphere, then let us see what SAFe says about their epics:
SAFe even have a specific definition to define that an Epic is not a project, which should tell you how vague the Portfolio Epic is in SAFe. It becomes even muddier when Portfolio Epics in SAFe leads to Business Cases with high level estimations, which projects also need. The difference seem to be that the Portfolio Epic is a funding without scope or time frame, which to me is the same as an extra budget for research and development or some form of business operation scenario.

Epics everywhere...
Epics can be found pretty much in all tools you look at, and in companies you will find that the term "Epic" is just as abused as the term "project" or "Initiative" as it is applied to everything. Are you working with strategic themes? I bet you have some strategic Epics as well, right? How about focus areas? Do you have epics there as well, maybe? How about your requirement process, I am sure you have heard your product owner talking about Epics on multiple levels as just things that are undefined in their mind?
Just to make things worse, you even have methodologies named EPIC.
 
Epics in traditional development.
In traditional development, we don't have Epics, but we can translate it based on the definitions used in Agile. I found this definition I thought fit pretty well:
I think Epics are more similar to top-level requirements, but I think the fact that they can also be similar to mission threads illuminate the problem with Epics. As a top level requirement it fit both the team or system based focus as in Agile methodologies like Scrum, but it also fit the SAFe Epic definition, which I think is interesting.
That would suggest that an Epic is defined on the level where it is placed and depending on how you divide between need and requirement the term Epic would be a top-level requirement in both situations, or they would be a top-level need when defined as a SAFe Epic.
 
So how should we think about Epics?
Regardless if you work in an organization that claim to be Agile or not, you will most certainly come across the term Epic. If not in your systems, then people will use the term based on how they have used it in the past. So you need to deal with them and you need to define them in a way that makes sense for every scenario.
My suggestion is that you define the term Epic as a level top-level requirement. This way you know that whatever is in that epic, it is not useful until it has been broken down into smaller pieces. As such, an Epic is a container that is meant to hold actual requirements once defined properly.
If you have Portfolio management, then define a Portfolio Epic as a top-level need. A need is a loose description that will lead to one or more requirements should the need be funded.
If you want an even more clear definition, then you can define the Epic as an operational Epic and a portfolio Epic as a strategic Epic. This should help define the level of the Epics and place them more clearly in the strategic and the operational areas.
 
Do not use Epics as Themes or focus areas.
If you start using Epics, of any level, as a way to categorize things based on strategic themes or focus areas, then you will start muddling the waters and the definition of an Epic as a top-level requirement or top-level need will be pointless.
Themes and focus areas are directional based, while requirements and need are action based. Having them become interchangeable means that you will either only work with directional goals with no actions defined, or you will only have action items and no direction. None of those scenarios are very good or healthy.
An epic should never be a direction or a goal, it should always be a defined activity that lead to a certain goal. So an Epic should always be connected to a theme or focus area, but it should not replace it or live in limbo without the connection.
 
Epic should be defined, or it is nothing.
I have spent more time discussing what an Epic is and is not when working with work processes than any other term. Without a definition, an Epic will cause confusion and frustration as it will become a change shifting monster that represent everything from a strategic theme to project to idea to design task. And beyond. It will be this go-to phrase for anything undefined that we don't want or have the experience to actually name correctly, or work with properly.
It will be everything and also nothing.
 
Epic in Jira could be a feature.
In Jira, I always define operational Epics as Features. It is a top-level requirement of something that once released add value as a separate feature. That means that when released, the Epic will be closed in Jira.
This is because I never have requirements in Jira, as Jira is a temporary work tool that should never, ever hold any documentation. In Jira, you should only have instructions on how to complete the task. That means that Epics in Jira should only be connected to top-level requirements in Confluence, not be the actual top-level requirement.
Unless your company have decided that you do not document requirements, then you don't need to define where to put them and can do whatever your team desire.
 
How do you use Epics?
I have seen many ways to use the Epics and even more ways to describe all kind of things as Epics, but I am always eager to learn more on how others use it.
So how do you use it, and why have you set it up that way?

Written by: Jimi Wikman
Category: Professional
February 26, 2022
0 comments
385 views
• 

The Importance of Communication - when TRUST dies horribly and organizations fail
This week alone, I have seen two great companies stumble and suffer serious damage to their brand. Not only did they alienate customers and cause short term financial loss for themselves, they also cause long term damage to their brand and reputation. This is something that could have easily been avoided by simply following standard practices and putting effort into proper communication. In this article, I will give you my point of view of the events and some ideas on how this could have been avoided.
Atlassian - removing features and failing to communicate it
Atlassian have had problems with communications for a while now, and this in itself is a big problem. This week, however, I was preparing for introducing Advanced Roadmaps to a company I work for, and I was very surprised to notice that some features was missing. As it turns out, this was announced back in May on an obscured page in their documentation.
I assume that a notice was sent out around that time, but it seems it did not reach everyone (I never got the mails) and then apparently they did not think any more of this. A minor notice, barely noticeable in the release notes, can be found for the July 26th release. No marking to indicate that this will reduce functionality and rather than explaining what is being removed they refer to "live plans", which almost no one know what that is in reference to.

My question is: what information did new customers that signed up AFTER May 10th get regarding the fact that functionality they were buying would be removed later that year? When I upgraded to Premium, there was no warning and no mention of this, and I have not received a single email regarding this change.
To make matters worse, it seems that not even support knew this was happening so when I submitted a ticket to ask where my features had disappeared to, they referred to the differences between cloud and DataCenter. Obviously, they had no idea this feature was removed or that it had ever been a part of the cloud product.
So, how should this be handled to avoid upset customers that suddenly loose functionality from a premium product they pay a lot of money from? Well, the simple answer is of course to communicate. In this case, you have 2 communication paths to cover: existing customers and new customers.
Existing customers - Direct communication is a must. No one have time to read release notes or blog posts. People have companies to run, and removing functionality from a premium product is almost unheard of without a replacement product or alternative. On May 10th this should be a focused email to all premium customers where the changes in the product would be clearly communicated and detailed.

3 months before the removal, another letter should be sent to remind the customers about this change. Then again every month to ensure no one misses this information. Every release note from May 10th should have a notice at the top reminding of this change as well. This notice should be properly marked in red with a warning sign to illustrate its importance.
  New Clients - Present changes up front. In the upgrade and order form, you should add a notice that the current implementation of Advanced Roadmaps will have changes happening soon that will remove features. You don't want to start a relation with a new customer with the feeling of lying and not being honest. While not a lot of clients was effected by this change, it has significant impact on TRUST. Not only do I not trust that Atlassian will keep me updated on changes to their products, especially when it comes to removing features, I also do not trust that they will be open with me when it comes to financial issues. This is a huge problem and I know that this is not just me feeling this way as I hear many other Atlassian consultants and customers starting to feel the same way.
Atlassian needs to step up their communication as they seem to be stuck in their corporate bubble lately and focusing more on making money than their customers. I think Pete Morris, the roadmaps/Advanced Roadmaps product owner, displayed this well in his response to me.

While Pete is a great guy and his response is kind and professional, it also shows a distinct lack of understanding of how to communicate with customers. In-product notifications are nice, if you assume that people actually read those, or even understand what they mean. Passive communication does not substitute direct communication, and more often than not the people who need the information are not the day-to-day users.  It is the people in charge of tools and work processes and finance that need it, as well as the system administrators.
I will of course reach out to Pete and discuss this with him and others at Atlassian, not to point fingers, but to give my point of view to hopefully prevent similar situations in the future.
 
Invision Power Services - massive surprise price increase and reducing support without notice
IPS, the company behind the software I use here on the site, stepped into a hornets nest this week when they sprung a massive surprise change on their clients. Instead of a simple update to pricing and their support, they now have a PR nightmare on their hands. Their new website refresh that was supposed to be filled with praise over the new design is now a sad tale of angry and disappointed clients. When writing this the thread has 384 replies and it is bad...

So what really happened to warrant such a massive surge of frustration? Well, it was a combination of things, where I think the biggest issue was that people realized big changes to pricing and support by browsing the new website. There had been no information on this change beforehand, and the changes was quite substantial.
Price updates - This was a huge price change where people not only saw their price go up with anything between 30% all the way up to 300%. Most seemed to get a 50-60% increase in price, however, and while that surprise in itself was bad... Billing cycle changes - Payment periods was to pay the license fee every 6 months, but after the update this was changed to 12 months. Not only did people see a 50%-60% increase in license costs, it also doubled in size since it is now a yearly cost. For me, this meant that I went from $105 every 6 months to $310 every 12 months. That is a 50% increase for me. No more support, unless you pay for it - This was a very strange one as IPS now will shift everything towards community support unless you pay a whopping $1250/year. Yes, you read that right... $1250. Unless you pay over 100 dollar a month for ticket support, your support experience will be going through an open support forum. IPS claims that you can ask for private support or use the contact form if you do not want to post sensitive information in public, which seems very odd to me. For me, that just add a step for IPS support, the way I see it? It could have been different...
This could easily have been avoided, and it could even have been a positive spin on things if handled correctly. No one really mind the price change because we all knew that it had to come sooner or later. The change should have been done gradually, however, with the proper communication.
First announce the change 3 months in advance. IPS need to increase prices to up the development and support efforts. Everyone wants to see more features and bugs fixed faster. Everyone wants support to be better. Not a hard selling point to make. Offer anyone that want to commit to IPS to pay for a longer period of time now before the price change. - Show that you care about the current customers and also get a big chunk of short term cash to invest. Next renewal price remains the same for all existing customers - Again show that you care and appreciate the current customers by extending the existing price 6-9 months depending on when their next billing is due. #2 above should cover any current cashflow need, and you get a ton of goodwill. New customers pay the new price, of course. Offer multiple billing cycles. - Matt tried to motivate having just yearly billing with that customers can get confused or happen to pick the wrong cycle. I don't buy that as it is a UX issue and they own the product in charge of billing. I had a web hosting service for 15 years with multiple billing tiers and no one ever got confused by that. Having multiple options would help a lot for many that have problems funding $300 one time fee, but find it easier to fund maybe $30 monthly. Yes, you can do that anyway if you like with the ability to deposit money, but it is not something that people are used to. Define your support properly and offer ticket support. - While I get the idea to move questions to an open area to reduce the number of same questions being asked over and over, that is not the answer to the problem. I am all for the community driven help with IPS staff doing the heavy lifting, but you need to have an option for ticket support as well. I think it would have helped to put classification on the support tiers to make it easier to understand:
  Tier 1 support - Paid Premium support with response time within 1 hour and a resolution time within 48 hours. You can even offer per ticket support where a customer can pay a sum for priority support either per incident or for say a month for example during a migration or critical sales period. Tier 2 Support - Ticket support in a private forum with only own tickets settings. This is used only for technical support issues, meaning that something is not working with your software. Tier 3 Support - Community driven support where you can ask any question and get help from the community as well as IPS staff. The key point here is to communicate, in advance, present the negative changes with a positive that motivates the negative. A price change should lead to improvements for the users, like better support and faster feature cycles or investments. This way you motivate the change and you give time to absorb it. This is important because the human mind is very sensitive to change and rapid change has a tendency to cause frustration or even anger.
IPS did the complete opposite by letting their customers discover the changes on their own and then selling the change with no upside for the customers at all. Instead the customers now pay more for less as prices went up and support was removed. That is a double negative, which is extremely hard to sell to your customers.
This was a part of the email that was sent out hours after the release of the new website and the new price model.

The wording and the way this is presented is directed inwards. It tries to motivate price changes with an historical reluctance to increase prices, which is pretty much what every landlord in the world do when they want to make more money and care nothing about their tenants. It has never been received well and it was not in this case either.
Claiming that the services and products hold great value is a moot point to make towards their customers. We know this, that is why we pay in the first place. What we want to know is why should I pay 50%-60% more tomorrow compared to today? What has changed and how do I get better value for paying more? Making claims that major features have been adding and referencing gamification (which is not a complete system btw), anonymous posting and Zapier integration does not really motivate why you want me to pay you more. I already have those features!
Switching to annual renewal billing because it is a simpler way and in line with industry standard show a distinct lack of connection with the customers and it is again directed inwards. It is not easier and more wanted for the customers, but many would have loved to have that as an option. I am of course talking about companies, but they are not the only customers IPS have.
The fact that this came out hours after the release of new prices and changes to support models enforces the feeling that this was an afterthought and that IPS care so little for their customers that they only informed them after they started screaming. I know that is not how IPS see their clients, but the perception is still there due to this mistake.
IPS failed in communication and people are leaving
Due to this very simple mistake to not communicate and not making sure the customers understand the reason behind the price change this has now caused many customers to cancel their subscriptions. This will have a ripple effect on the mod creators either leaving or increasing their prices substantially. Less mods means less customers and less customers means less community support, which leads to a feeling of abandonment and ultimately a reduction in sales.
Worse though is that IPS loose their customers TRUST. Again.
IPS is on a very dangerous path, and has been for a while, due to the fact that they seem to lack a communications officer that have experience with communication strategy and financial strategy. While Jordan is doing an amazing job trying to communicate with the customers on the forum and social media that is not enough to save them from blunders like these. Not even Matt trying to do damage control will do anything in this situation.
The damage is done.
The ony question is how will IPS handle this now that they have screwed up. They can either continue to ignore the vocal customers that do not approve of these changes, or they can roll back and make a new plan to roll out later this year.
If they ignore the customers I think they are going to have a really bad 2022, especially as people get back to life again and spend less time online again. Many struggle with finance now and it is not hard to motivate a move to less capable competitor with such a huge increase in pricing. Customers will drop like flies, not just because of the changes to price and support, but because they no longer trust IPS as a company.
If they roll back and make a proper plan in communication with their customers, then they have a chance to salvage some customers at least. Many will still leave due to the lack of TRUST, but the chance for redemption could salvage that to some degree. With the proper communication they can even turn this into a win, but that would require a communication plan that is very different than what we have seen so far from IPS.
 
Communication is not a nice-to-have!
If you run a company then you sould know that communication is not nice-to-have. It is an essential part of your business and if you fail in communication you not only can, but you will, damage your brand and business.
Anytime you deal with change for your customers, make sure your communication is aimed towards them. Make sure you present the benefit for them, not for you. Change is never accepted up front, so you must always sell it to prevent backlash. It is very difficult to fully recover from a communication mistake, but you can mitigate and in some cases even improve your relation with your customers.
So don't ignore the importance of good communication and if you are not a communications expert yourself, hire one. It will save you a ton of money from stupid mistakes like Atlassian and IPS have stepped into and it can increase your revenue a lot.
Good luck!
 

Written by: Jimi Wikman
Category: Professional
September 16, 2021
2 comments
617 views
• 

Rituals and Processes - How to make them work, for real
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!

Written by: Jimi Wikman
Category: Professional
July 30, 2021
0 comments
561 views
• 

5 interviewer tips - for landing a senior employee
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.

Written by: Jimi Wikman
Category: Professional
May 23, 2021
0 comments
460 views
• 

Linkedin adds pronouns and video - is it really what we need?
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?

Written by: Jimi Wikman
Category: Professional
April 2, 2021
0 comments
440 views
•