Jump to content
View in the app

A better way to browse. Learn more.
JimiWikman.se

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

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.

How to make realistic estimates when working with software development

Estimations for software development seem to be the bane of almost every company, but why is that really? Why is it so difficult to approximate the time and effort required when we do this all the time? There are a few reasons and in this article I will go over how I do my estimations and give you some of my experience on how you can maintain a 90% accuracy in any project.
For a good estimate you need to start with one very important thing: define if you estimate based on time to complete or  time to deliver. These are very different because the time to deliver will be substantially higher and much more prone to variations. This is because in the daily work you will be dragged into meetings, have people distracting you and so on. For good estimations we always estimate on time to complete as our basis.
Stop doing happy estimates
The worst thing you can do is making happy estimates. These are estimates based on the utopia that everything will work smoothly and you will be left in total isolation to focus. It never happens and Murphy is always present. Happy estimates may seem good because the product owner love low estimates, but they hate when you fail to deliver.
Happy estimates usually happen when an architect is stressed and throw out a guesstimate on the fly. It will almost always bite you in the butt because not only will everything seem easy to the architect, so they will underestimate it, they also never consider Murphy.
You do not estimate to be nice, you estimate to give a realistic view on when something can be available in production. If you have a hard time to stop making happy estimates, then implement this very simple rule:
"Any time that is needed beyond the time you have estimated you will do in your own time without payment"
Take your time doing estimates
An estimate is not a guesstimate that you throw out on a high level requirement. An estimate is your promise on when you can deliver and as such you should take your time and think that through. Don't sit around doing arbitrary guess work in a planning poker or play with t-shirt sizes unless you want to avoid doing any estimates at all. That type of guesstimating is for high level requirements, so make sure they stay there.
Break down the requirement and use your experience to guide you to a first number in your estimation. This estimate is how long it will actually take to sit down and build based on the requirement. Make sure that you ask questions to clarify where needed so have the information you need. This is also a good time to start working on a solution design to make sure you have considered things that may not always be apparent. For example validation of data in integrations or extending a JavaScript validation for a new form.
When we have done this, the number is still wrong, but we need it as a starting point.
Add the things you forgot
Now that you have done your estimate, many think they are done. That is rarely the case, so let us add the things that is not included yet. The most obvious problem that I see a lot is that the estimates is usually done by the most experience person, which also usually is the one that work fastest of everyone in the team. So what we do is to look at the estimate and the team, then we adjust based on what the slowest person in the team think is appropriate. This way we know that the base estimate is reasonable for everyone on the team.
The second thing we do is to consider Murphy. Things always happen and based on the complexity we increase the estimate with 20-100%. Not having room for mistakes is in itself a very big mistake. It will almost always happen and if it does not happen for this particular task we will either be able to resolve things faster than expected, or we have more time for other tasks. Either way that is a positive thing.
The third thing to look at are testing. All code should have unit tests and it is often forgotten in the estimate. You also have non-functional requirements such as loading times and browser support that you must consider. As a developer you are also responsible for testing the code and this should be added as a second estimate. For many estimates this alone will add 20-200% or even more to the estimate. This is especially true for frontend development where you often have 18+ variations just for devices and browsers.
These three very simple things easily multiply the original estimate two to three times.
Now let us consider your efficiency!
A factor that is very often overlooked is efficiency. No person in any team will ever have 100% efficiency in the sprint. I do not mean your focus level during the day, even if that also is a factor, I am talking about those pesky things that break your concentration. Things like meetings, stand-ups, code reviews and all those "I just want to ask a quick question", cost a lot of your time during the day. In my experience most teams will have an efficiency of around 40-60% depending on how often they are disturbed.
Depending on if your product owner understand estimation or not you can choose if you add the efficiency in the estimate, or if you have that as an external factor in the sprint itself. If you are new to this part of the estimation I suggest that you start with 50% efficiency and then adjust over time as you get better at estimating your efficiency.
With this step we now add a second two time multiplier and you are now close to a realistic estimate.
This may seem like a lot
This may sound like the estimates always will be very high compared to how you are working today, and you are right. This is why you always feel stressed and why you fail to deliver on promise in every sprint. It is why we invent things like story points to mitigate our inability to take responsibility for things we can't estimate properly. Realistic estimates are just that and if your estimates are far lower than what you get doing estimates this way, then remember this very simple rule:
It is always better to overestimate and over deliver than to underestimate and under deliver.
 
The Quick Summary
Make estimations in actual time to complete, not arbitrary measurements. Take your time to understand the task at hand and stop guesstimating. Adjust the estimate to fit the slowest person on your team. Add task for testing and make estimation separate for that. Remember that things always go wrong, so make room for that. Make sure that your efficiency is considered and calculated into the time to deliver.
Making good estimates is based on experience and knowledge. This means that like other skills you can get better at it. If you constantly work with arbitrary measurements like story points and you constantly fail with no change to your estimation process, then you should stop doing that. Not only will you fail at a crucial part of your work, your inability to provide accurate estimates actually cause harm in the form of stress and frustration. It is up to you if you want to spend your time in constant failure or constantly provide estimates that are realistic and dependable.
Learning to make good estimates is not rocket science, just common sense and experience.
So start doing it today.
By 💫 Jimi Wikman in Ways of working ·

The Failed Product Owner - do you even provide feedback?

Product owners often get blamed for not understanding Agile and for not providing clear requirements. Is this their fault though, or are you not providing the correct feedback to help them improve? Agile teams often work with the product owner absent, especially in the retrospectives. If that is true for your team, who is actually at fault then?
I hear this all the time. "The product owner" is absent or "the product owner can't give a straight answer on what I should do, it changes by the minute". This is especially prominent in project based organizations where Agile means that you just remove the requirements phase in your waterfall process to make things fall down to the development team faster. Agile becomes ad-hoc and chaotic and it is all the product owners fault. Right?
This is a problematic attitude and one that to me clearly means that the team is not really Agile, but still work as a receiver instead of the engine it should be. Although in most organizations there are two processes and the development team always is the receiver of strategic goals, they should not be a passive one.
Not being passive means that you put demands on what you receive.
How you receive a new business need, what information you need and how you work together with the product owner is not something that you passively sit around and complain about. It is the core of what the retrospectives are for! I would bet that in most teams where you have issues with the product owner you do not include that person in your retrospectives? Do you even provide feedback or set up activities to help the product owner improve together with you?
If the product owner is not included, then could the issue be with you and not the product owner?
The product owner is a part of your team. This means that you are responsible to speak up and ensure that everyone in the team is working in the way that best benefit the team. This means that you should provide feedback if the product owner is absent or if you do not get the information you need. This should be done in retrospective, just like you do it with every other feedback concerning your work process and collaboration in the team.
 
Easy to say, but our Product Owner does not care.
I know, this happens all the time. The product owner is tied up in meetings all day and just ignore your feedback. This is where you need to play hardball and provide empiric evidence that the issues you have is not your fault and that you have done your job to try to improve this. The First step is to go above the product owner and point out the issue to the people above. Sometimes that works, but it may not always be an option.
In the sprint planning you should be very clear on what information need to be present for you to accept a user story. Remember that once you put the user story in the sprint, you have accepted the user story and you are responsible for the consequence for poor requirements. Never accept a user story that is not clear enough for you to work on. It is the responsibility of the product owner to ensure the user story can be accepted by the development team.
If you use Jira then your next step will be to push back everything that is unclear to the product owner. This is done by assigning the product owner to the issue, put the issue in blocked status, or flag the issue if you do not have a blocked status and then comment saying that you wait for the product owner to respond. Once done, leave the issue and move to another issue. This will effectively remove the priority for the first issue as it will now be done after whatever issue you pickup next.
This will allow you to move responsibility to the product owner and point out the issues you are having. It also allows you to get statistics on waiting times the team have due to the product owner not doing their job.
 
Failure is on the team, not the product owner alone
Just as the entire team is at fault if the scrum master or a team member is dragging the team down, the same goes for product owners. You manage it through the retrospective and constructive feedback. Help the product owner to be the team member you need hem to be. If that fail, then you as a team will fail as well.
Make demands, just as you would for any other team member. Make sure their calendar have all stand ups booked, all retrospectives should be holy times and if they run around for meetings all the time, have them block time in their calendar for the team. You would not accept a developer to not do their job, so don't accept if the product owner is not doing theirs either.
At the end of the day, remember that no product owner want to be a bad one. They often get dragged into activities where their role is poorly defined, so they need help to define what you as a team demand of them. This will make it more clear to them how to prioritize their time, or find a replacement to make sure you get the team member you deserve and need.
Never sit silent with a clenched fist in your pocket.
Speak up and offer constructive solutions and you will be surprised how willing many are to solve the situation with you. Teams work together and since we still have not developed telepathy we need to verbally communicate and express our need to work better together.
Product owners are not outsiders, they are valued team members.
...or at least they should be.
By 💫 Jimi Wikman in Ways of working ·

Salesforce acquire Slack in a staggering $27.7 billion deal

Salesforce announced on January 1st that they have entered into a definitive agreement to acquire the very popular communication and collaboration platform Slack. The price tag for this acquisition is a staggering 27.7 billion us dollars. This is the biggest software acquisition of 2020 and it will have a big impact on the communications market for 2021.
This is no small acquisition by any means and with Slack becoming and integrated part of the Salesforce Customer 360 suite it will make ripples across the communications and collaboration ecosystem for sure. Slack have been loosing ground to Microsoft's Teams in the last years and it will be interesting to see what the future holds for Slack with this acquisition.
For Salesforce, I think this is a great acquisition as it will add a very popular and useful communication service into their products. They also get a huge customer database with millions of Slack users that they can try to convert into Salesforce customers. Hopefully this will also make their Salesforce Customer 360 suite more attractive because they will need to bring in quite a few customers to cover that price tag.
For existing Slack users I don't think there will be much that will change in the short term. I assume Slack will still be available as a standalone product, just like for example Trello was when Atlassian purchased them. Speaking of Atlassian it will be interesting to see what this means as Atlassian have been closely collaborating with Slack since Atlassian cancelled their own chat based collaboration  tools Hipchat and Stride that was sold to Slack in February 2019.
This acquisition surprised me a bit to be honest, but from a business perspective it makes sense from both lack and Salesforce perspective I think. It will be interesting to see what this means and if we might finally see a proper enterprise version of Slack or if Slack will slowly phase into Salesforce products and vanish...
 
 
 
By 💫 Jimi Wikman in Interesting ·

Vaam.io - the screen recording tool that streamlines communication

Vaam.io is a Swedish “video as a message” service that was started by Josef Fallesen, Hampus Persson and Gohar Avagyan that I worked with on the H&M project. Vaam is a very easy to use service that has a lot to offer, even though it is still very new and under rapid development.
I first noticed Vaam.io on LinkedIn and since Gohar is an amazing designer I looked into it. What I found was a service that is incredibly simple to use, yet very powerful. It has a lot of potential and I will make use of it here on the site as soon as I figure out the best way to use it. I have some ideas on how to implement it, but there are some technical issues I need to figure out first. This is on my end though, not with Vaam.
So, what does Vaam do? Simply put it allow you to record yourself while interacting with whatever you have on your screen. So it can be used as a presentation or as a quick message as you can link directly from your Vaam library.
Once you have recorded a message, then you have several options already, and more are on the way. You can download the video of course as well as sharing the recording in multiple ways. One interesting feature is to link as a Gif for emails and things like that.
In order to use Vaam today you need to install an app that is currently only available for Chrome. Once installed you simply click a button and start recording. Once done your recording is automatically added to your library and you can share it or delete it if you did not like it.
As with all startups the team behind Vaam are very active, and they have invited people to a Vaam slack where the so called Vaambassadors provide feedback and discuss features with the team.
I think Vaam have a bright future ahead and Vaam.io and the team have secured plenty of funds already.
By 💫 Jimi Wikman in Interesting ·

Invision Community - building a blog from scratch

This is a guide series that will go through everything you need to know to set up and customize your own blog using Invision Community from Invision Power Services. This guide will be updated with new articles or new information when new releases are made that affect the guides.
This guide contains the following articles:
Introduction (this page) Databases & Custom fields Adding Databases to Pages Adding CSS and JS to Pages Article View Template design Article Listing Template Design Article Category Listing Template Design Article Form Design Article Block Design Database Relationships This guide should give you all the information you need to get a good start with creating your own designs with Invision Community and its Pages application. If you want a quick start however and get a great looking design up and running in 10 minutes, then you can purchase a license for Invision Community and buy the plugin Pages SuperGrid by opentype.
For this guide you will need a license for Pages, which is the application that allow you to work with Pages and Databases. I will make references to the Forum application as well, but you do not need that if you do not want to. The information in the articles will not go deep into how to make your blog compatible by using standard classes as that is a pretty big topic and I usually just build for myself, so I do not have to worry too much about that.
If you have any questions or see a topic not yet added here, please drop by the forum and let me know.
By 💫 Jimi Wikman in Interesting ·

Jira Service Management merges several products into one

Today Atlassian announced the new package for their ITSM solution. The new package is called Jira Service Management and it is a bundle of Jira Service Desk, Opsgenie. This is a pretty sweet package and it is quite powerful for anyone who want to combine Agile and ITIL4 as a power combo for the future.
This is quite the change for Atlassian and it is probably to compete with ServiceNow that has had a stronger ITSM solution as their main selling point. This new service package, and especially the new name for it, will probably pave way for more companies to look at Atlassian even for their ITSM solutions.
This new package, combined with Jira Software, Confluence and Bitbucket now means that you get a complete package for ITSM and Agile methodologies. There will be improved integrations with Insight, the asset management solution Atlassian purchased from Mindville earlier this year. This will greatly improve the usefulness of the Atlassian ITSM package.
This comes at a pretty good time as I am building this for several clients, and they will be very happy about these new changes.
 
By 💫 Jimi Wikman in Atlassian ·

Color Psychology - not as easy as it may look

Color psychology is a topic often brought up when discussing conversion rate optimization. It often comes up as a sort of law of what colors to use, which is based on an article online or some generic description in a book. Color psychology however is far more complex than that and a recent article by Talia Wolf at GetUplift is the best introduction to that complexity I think.
The fact that colors can affect us should come as no surprise to anyone. There are a lot of studies that show that this is true. How they affect us however is still a bit vague and seem less important to a lot of people working with it. This is a big mistake because just like music has an impact on our minds, colors also affect us based on association and everyone has different associations.
Just as Talia brings up the different association differences in her excellent article, like the fact that white is both purity and death, there is also associations based on age and even personal preferences. You also have a whole science behind the different versions and shades of the colors where for example one shade of green can be seen as healthy and full of life and another will associate with pestilence and death.
Talia also briefly touch on the fact that color psychology should not be used alone. It should be considered together with other association factors like typography, iconography and overall tonality. In conversion rate optimization it should also be accompanied by other CRO tools like direction of movement, familiarity and the gestalt laws to direct and highlight the actions we want the users to take.
If you want to know more, then head over to GetUplift and read the full article "Color psychology: The complete step-by-step guide" by Talia Wolf.
You will not regret it.
 
By 💫 Jimi Wikman in Interesting ·

Knowit acquire Creuna - becomes the largest digital agency in the Nordics

The Swedish consultant agency Knowit acquire Creuna, a nordic digital agency and form the largest digital agency in the nordics. The combined work forces will be gathered under Knowit Experience. The acquisition is conditional on approval from the Norwegian Competition Authority, which is expected to be received during the fourth quarter of 2020.
How this will affect the market is still too early to predict. It will depend on how well Knowit matches Creunas way of working and what support will be provided in the merger. I suspect there will be some Creuna profiles moving on shortly, but in the end I think this should be a good match for Knowit. Just like Fjord was a good match for Accenture when I still worked for Accenture.
Read the full press release (in Swedish):
https://www.knowit.se/pressmeddelanden/knowit-forvarvar-creuna-och-blir-nordens-storsta-digitalbyra/
 
By 💫 Jimi Wikman in Interesting ·

Episerver acquire Optimizely - claim to have industry’s most advanced DE platform

Episerver invest for the future as they complete their Acquisition of my favorite A/B testing tool Optimizely. With this acquisition Episerver strengthen their platform offer, and they now claim that they have the industry's most advanced Digital Experience Platform.
Episerver have long been one of the big names in content management and digital experience and Optimizely have been fighting for the title of the king of A/B testing  against VWO for many years. This combination of forces makes sense as it will add value to both companies as they combine their customer bases.
Will this take Episerver closer to Adobe who sit comfortably at the top of the digital experience market, if for nothing else than revenue alone. I doubt it very much, but it should bring them closer if nothing else. Hopefully though we will see more people start experimenting as Optimizely becomes more accessible and integrated.
 
Transaction Details
Episerver is a privately held portfolio company of Insight Partners, purchased in 2018 at $1.16B. Insight Partners acted as the strategic advisor and sponsor for Episerver’s acquisition of Optimizely, as well as the company’s 2019 acquisitions of B2B commerce leader Insite Software and analytics and personalization provider Idio. Now with Optimizely, Insight Partners further advances Episerver’s market-leading product. In the same manner, Goldman Sachs & Co. LLC served as exclusive financial advisor to Optimizely.
By 💫 Jimi Wikman in Interesting ·

Scrum vs Kanban - what flavor of Agile is king?

Over the years I have seen many claims to what flavor of Agile is king. In this article we will look at Scrum and Kanban to see if we can determine which of these two flavors are the best for you and your team. I have a feeling you will be surprised at the answer, but I hope you will not be.
I recently read an article called "Scrum Is Dead. All Hail Kanban, the New King" where the author Emanuel Marques praise the Kanban flavor of Agile as his experience of Scrum have been less positive compared to Kanban. One of the responses to that article was written by Maarten Dalmijn, and he made some good points in his article on how flawed the initial article was.
To anyone who work with Scrum in multiple projects and multiple companies you probably recognize Emanuel's story. It is in no way a unique experience he has that Scrum, like many other Agile flavors, are misrepresented due to adjustments by the team or the company. Here are some examples from Emanuel's article:
A common thing that happens way too often. When you are inexperienced with Scrum, estimations and you do not set sprint goals, then this happens a lot. We see that the team is not working properly in the burndown chart as well.

This is a typical Agile burndown when using story points when you either have issues that are too big or you do not close issues properly. For a team working with story point, which I think is stupid in any case, a burndown chart is completely useless.
This is again inexperience in making proper estimations and because of that you did not have room for the unexpected. In all processes, methodologies and frameworks you need to be able to make proper work assessments. Agile make that easier by letting you make arbitrary measurements that are more like "guesstimates". If you fail doing that, then you are in real trouble regardless of what process methodology or framework you choose.
Emanuel's team choose to go to Kanban because of their inability to adjust their way of working away from the production line of thinking to an Agile way of thinking. What was it about Kanban that attracted them?
So out of all the things that Kanban offer, Emanuel's team choose to focus on these. As you can see all of these are about commitment and responsibility. If you combine this with the reasons Emanuel and his team felt the need to move from Scrum to Kanban you probably can see the same thing as I can and that is that this is a team that no one has taught how to work properly.
They have been left in a work environment where things are difficult to navigate and control and as a result they feel they are unable to commit to anything. I assume this is because failure, as diffuse as that definition might be, happens frequently. They also seem to be working with a poor scrum master, possibly also inexperienced or limited in his capabilities by the work environment.
Sadly I think Emanuel and his team will soon find out that Kanban with the focus on escaping accountability and control is a bad choice. Kanban is not going to make failures go away. In fact, it will probably make things worse as the stakeholders will find the Kanban way of working, especially the bare-bones version Emanuel and his team are describing, very annoying as they have little to no control in that flow.
What does this have to do with what flavor is king?
Well this has everything to do with what flavor is king. They all are. If you use them properly. Sadly many work places implement Agile in all its forms in the wrong way. They try to make Agile work in a project based organization with an ITIL based steering structure with multiple teams on the same products.
If you add inexperience and poor coaching resources, then you are setting up all flavors of Agile to fail. With that comes frustration and stress for the teams, and they will naturally try to distance themselves from management and any form of accountability as they are destined to fail regardless off their effort.
This is referred to as a MOD project by some of us that work with process and methodology design. MOD is short for "March of doom" meaning that the project or the team are already doomed before they start due to the restrictions already placed on them. It is also in reference to how managers often refer to them MODifying the Agile way of working, which often result in a poor experience.
If you work with Scrum, Kanban, DevOps or any other flavor of Agile, that can be king for you and your team. If you use it correctly and you actually take your findings in retrospective to adjust it to fit your way of working. You can even mix them to find the optimal workflow for your team, because they all come from the same source: Agile.
You have the power to make your flavor of Agile king
This might seem strange for anyone who work in workplaces where your way of working is dictated by management, but there is hope. In all organizations you have two ways of working: The Steering and the Operational. If you can find the way to meet the steering, so they can do their job, then what happens in your team should be up to you. If you are sharing responsibilities with more teams, then you should build your way of working together with the other teams. Never work in isolation if you share responsibilities.
In order to do that you need to figure out what steering need so you can provide that. Usually this is the holy trinity of time, money and quality. Time and money comes through time reporting and proper estimations. Quality comes from requirements and testing alongside prioritization. So no matter what flavor you choose you need the following:
A handover of translated need - you need to understand what the need is so you can take ownership. A Prioritization meeting - to decide what to do next. A common practice to make estimations - learn to make proper estimations instead of "guesstimations". Log time at least once per day if you have time estimates. Break down tasks as small as possible and close as soon as they are done if using story points. That is usually all you need, regardless of flavor.
So go out and make whatever flavor you prefer KING today.
By 💫 Jimi Wikman in Ways of working ·

Agile 2 is here - the new iteration of Agile

Agile 2 is here. It has been in the works for a while and from what I can tell there has been some sharp and experienced minds involved in that work. It is in many ways a retrospective, but also a way to look at the great failure that is Agile. A failure that originates in the division of visions and the ideal becoming absolutes. Agile 2 hope to change that and it is a great ambition that have my wholehearted support.
In the case for Agile 2 the statement is that one of the issues with the original is that it lack the inclusion of leadership. I agree with that as well as to note that the developers do not always enjoy what is referred as Agile in many organizations. The fracture of the Agile community and then the stagnation into a fixed perception almost to the point of worship also resonate with me.
This is by far the most common experience for me when meeting with organizations. A will to move towards Agile, but a methodology that is fixed in its ways and lack the component of leadership and steering. I also find the interpretation of Agile to be heavily reduced when facing the opposition of reality, leading to an ad hoc situation that is damaging and frustrating to the people involved.
At first glance Agile 2 seem to be on the right track. I look forward to seeing where this will go and how it will challenge today's Agile community. Hopefully the Agile community will adopt their own methodology and embrace this new input to evolve their way of working.
I support the work of Agile 2 and I hope you do too.
 
Agile 2 – THE NEXT ITERATION OF AGILE
AGILE2.NET THE NEXT ITERATION OF AGILE  
By 💫 Jimi Wikman in Ways of working ·

How to write work ads - 6 tips on how to attract the right people

As a consultant I see many work ads. Some are good, but a lot of them are almost to the point where I wonder if the people writing them know what they are asking for. It takes a while to write a work ad, so not only are you wasting your own time, but that of those who are looking for work as well. So here are my five best tips on how to write good work ads to get the right people for the job.
 
Describe the problem you need solved Don't add buzz words Have a person that knows the craft write the ad Be honest about your work process Don't ask for unicorns Set tiers internally and price accordingly  
1. Describe the problem you need solved
Most ads are just a big list of qualifications required, but very few actually describe what you need. Asking for certifications and extensive experience in a very specific field is a sure way to narrow the field of applicants. It does not however ensure that you can get the help you need. A certified scrum master or project manager can still be completely useless, while an uncertified person can be a miracle worker. Describing the problem also ensures that you can follow up and see if the person you hired actually could solve the problem you specified.
To some people this is very difficult, because it implies a problem and not everyone can admit that there is a problem to be solved. The thing is though that all work ads are requests for help due to a problem. It may be that you are understaffed, or that there is a competence missing. It can also be that you need help to organize or create work processes. No matter the need, just state what it is that you need help with and you will have a much better chance of getting the right person for the job.
2. Don't add buzz words
As a consultant I can easily read between the lines and when I see an ad stuffed with buzz words I know that this is a bad position. There are certain combinations like "Agile Mindset" with "dig in where needed" that I know means you have a chaotic workplace. Other combinations like "comfortable talking to steering groups" and "team player" means that you will be thrown under the bus frequently.
Anyone claiming that they work in an Agile way in a large scale company don't really know what Agile is and throwing in DevOps, SAFe, full stack x or made up words like "Scrum Manager" does not make it better. In act I often skip ads that are keyword stuffed with nonsense or where I can clearly see an underlying hint of a bad work environment.
Make sure you know what you are talking about and be up front with the situation you are in. Most of us experienced consultants have worked in very bad condition, and we make it work. I just want to know what I am stepping into rather than wasting my time and yours.
3. Have a person that knows the craft write the ad
I have seen ads that so clearly are written by people who have no idea what that role really will do. I understand that it is often managers or HR people that write the ads, but I suggest you let the people who know the trade write it instead. Not only will the ad suffer less from #1 and #2 above, but you can also define the actual work much better.
Having the person I will replace or work alongside write the ad will ensure I get the right information. This is because that person want the very best for the job so the ad will be aimed towards that. I will get the tools, disciplines, work processes and characteristics described properly and without nonsense.
4. Be honest about your work process
Everyone has crappy work processes. It is a fact and there is no need to pretend otherwise. Just be up front about just how bad your process is and most applicants will be fine with that. If the requirement process does not work or you have constant change in your iterations because no one can actually commit to anything, that is actually fine. Most of us work that way every day of the week, and we make it work.
If I know what I am getting myself into, then there is less chance that I will feel like you lied to me and I will stay longer. If you claim you work according to Scrum and it turns out you just have an ad hoc process with stand-ups, then I will probably not be very happy. This is often very difficult for managers and HR, which is why you should use tip #3.
Simply telling that you are trying to work in a more Agile way, but that you are struggling a bit due to the fact that your organization is still project based with a long tradition in ITSM is enough. Or that you are in a transformation phase so things are a bit shaky while you figure things out will do wonders.
5. Don't ask for unicorns
This is the biggest source of amusement for me and many other experienced consultants. Mixing roles as if you were doctor Frankenstein and then asking for 20+ years of experience for minimum wage. I have actually seen ads that ask for longer experience than the technique or tool has been around, which means they failed with tip #3.
When you define roles, then stick to one discipline and don't mix things. The more things you mix in, the less focus you will get in that area. If you combine opposing types, like "Scrum Manager" or "Developing Scrum Master", then you will not get both at 100%. One will be dominating at 80% or more.
An easy way to avoid this is to use the color coding on this page. Mark the requirements you have put in with a color and then see how many colors you get. If you have two colors, then you are splitting the work into two disciplines. Three or more, then you are asking for a unicorn. Secondly you should look at the roles and see how they match up.
A Scrum Manager for example have both Scrum Master and Manager in the same category, but they are opposing in work direction and empathy. Managers work upwards with focus on finance, while scrum masters work downwards with focus on people. Developing scrum masters have conflict in focus. Scrum Masters are extrovertly focused where content switching is natural, while developers are introvertly focused and content switching will hurt their work capacity.
Work is often hard enough as it is and people burn themselves out far too often when working in just one discipline. Combining them increase that risk a lot and if you care about the people you hire you should avoid putting them in that situation.
6. Set tiers internally and price accordingly
Finally, don't ask for unicorns or highly experienced people and offer peanuts. I rarely care about the financial side of things because I value other things and I love helping people, but if you ask for someone with special abilities or long experience, then understand that you get what you pay for. Asking for a lower price makes sense, but don't ask for a senior or someone with expert capabilities and offer them half or a third of what they normally cost.  You will just end up getting a junior with basic skills rather than an experienced unicorn...
I suggest you set tiers internally for all roles you have, or need. Grade then according to experience, competence, workload and then match them towards the value they provide. Make it into a five tier grade where tier 1 is the highest and tier 5 the lowest and every time you make a new ad, define what tier you are looking for. Not all ads are aimed towards tier 1 applicants, in fact I would say most are not. So just make sure you know what you are looking for and then price it accordingly.
 
Final thoughts
Writing ads are difficult, but the cost of getting the wrong person for the job can be far worse. You also scare away a lot of good applicants if your ad is considered bloated, dishonest or if you send out danger signs because of an unfortunate combination of keywords. Even if the ad is for a temporary position you want to make sure you get the right person, so put some effort into the ad. If it is for a permanent position, then it is very important that you put your soul into it.
I know a lot of people think that you will just put something together for the ad, and then we do the real recruitment during the interviews. The downside to that is that you may already have lost the unicorns or that perfect candidate with the ad.
So make it good.
By 💫 Jimi Wikman in Professional ·

Configure browser push notifications
Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.