Skip to main content

Posts

Deleting duplicate emails in outlook

Recently I started using Microsoft 365 for my email, instead of the gmail account I've had since the start of gmail. My mailbox is also a part of my life's archive, so I migrated the mail from gmail to Exchange Online, just like almost 2 decades ago I migrated all my emails to my brand new gmail account. Anyway, during the recent migration to Exchange Online something got messed up, or most likely I messed up, but somehow a lot of messages were duplicated. Some even had 4 duplicates, resulting in a mailbox containing 144000 messages. I connected Outlook to the mailbox, let it download all mail, and was hoping I could remove the duplicates using the "Clean up Folder" functionality that you see when right-clicking on a folder. It did remove some duplicates, but most duplicates remained.  So, I started looking online for a free tool that could remove duplicate messages from Outlook, and there appear to be a lot of tools, but non of them free. Well, some are free but they
Recent posts

Agile and Scrum in a nutshell

It was a lot of fun to create the following video: -- Kenneth van Grinsven

Agile: planning part 1. Hours versus story points

After I prepared a post about agile planning, I found out the post was becoming huge, so I divided it into three posts: Estimating Short term planning Long term planning This first part is about estimating user stories, adding to the debate of hours versus story points. A lot of project managers who are involved in agile projects see a story point as a measure of time, often using the equation “1 story point = 1 hour”, while on the other hand an agile method like scrum teaches us story points are a measure of effort or complexity, and are at most loosely coupled with time. So should we estimate using hours or estimate using story points? Let’s first build the case for using story points: It is very hard to estimate how long something should take, but it is less hard to estimate whether something will take more time or less time compared to something you know well. To aid the estimating process scrum introduced story points. Story points aren’t a measure of time, but are a

Agile: So who's the team manager?

People often call agile teams “self-steering” teams or “self-managing” teams. But surely someone must steer the team towards a long term goal? And how about activities that are typically performed by a department head, such as daily operations, coaching, coordination of vacation days, and employee performance management? The answer to those questions is, as with many things, “it depends”. It depends on the management activity and how far along the organization is in adopting an ABOK (Agile Body of Knowledge) way of working. Let’s first zoom out before we zoom in. Traditionally organizations are divided into silos. The division can for example be based on market segment, or geography, but is usually based on the activities people perform. So usually, IT people are pooled in the IT silo. If we look at such a traditional IT department, then within that silo there is usually more compartmentalization; such as a software development team, a network and system administrations team, a

Agile: not "just another way of doing the same"

Despite being decades old agile is hot and is being introduced and implemented in many organizations which is great. With this post I'll very briefly try to explain that agile however is not some plug-in replacement of current ways of working. You can of course take an existing team and start scrumming with them, and it may lead to improvements, but you will not reap all the benefits. In order to be agile, you have to understand the agile concepts. Those concepts may be obvious, but in the daily madness people tend to focus on the wrong things. Think about this analogy; I use the train for my daily commute, and if you ask the employees of the Dutch Railways in what kind of business they are, the majority will tell you that they are in the railway business, while in fact they are in the people transportation business. This illustrates one of the driving forces behind agile: with everything you do, you should ask yourself who you’re doing it for, and whether there are ways to serve