Microsoft Planner vs. Trello

I love Trello. I’ve been using it for years and have written about how we use it to manage projects. I like how easy it easy to create cards with an email and how well IFTTT works with Trello. I like Butler Bot and all the automation I can use to accomplish system housekeeping. Trello isn’t perfect, and falls down a bit in reporting, but this has never been a big problem, so in many ways it’s as close to perfect as a system could get for my way of working.

I work for an organisation that considers itself a ‘Microsoft house’, which means all of our core infrastructure and software is Microsoft, and that we are encouraged to use the approved software provided by our It department. My digital mindset says use the best tool for the job, but I also understand that using a single enterprise-level ecosystem provides better security (which is essential) and that using whatever third party software you feel like can have legal implications if that company’s terms and conditions don’t allow the software to be used for business purposes for free.

So you see my problem. Using a system that works for me versus using a system that works for the organisation. So, I started playing with Planner, Microsoft’s Trello-like product to see if it could give us the same level of flexibility in managing projects that Trello has but is compliant with organisational policy. Can I turn that ‘versus’ into an ‘and’?

After an hour of playing with Planner, this is what I think:

  • Both are accessible in a browser and both have an android app. This is important to me as I use four different devices and need to be able to use whichever system whenever and however I want.
  • Cards can’t be created in Planner by sending an email like with Trello, but there is a workaround by using Microsoft Flow (Microsoft’s IFTTT) so I have a flow set up that creates a card in Planner for every card created in Trello, which means I can use the good bits from Trello such as creating a card by email and butler bot automation in Planner.
  • Planner has a status for each card of Not started, In progress and Completed. At first I didn’t get why it would have this as there is also a start and due date for each card, but the status drives some of reporting and the Progress view.
  • Both can show cards on a calendar view but do it differently. Trello treats each card as only being able to be on a single day. The card can be moved to tomorrow if you didn’t finish it today but then it won’t still be on what is now yesterday. This means you can’t see how long a card has been worked on for. Planner has a start date and due date for each card which means that when you look at the calendar view the card is shown over the length of time between the start and due date. Both have a week and more view but neither have a year or selectable dates view.
  • Planner has a number of ways of displaying lists of cards whereas Trello only has one way. Trello lists can be titled by the name of the project, with cards being tasks within the project and having due dates, or the lists can be titled To do, Doing, Done with cards being tasks on the lists but with Labels used to group cards on the same project. Planner can switch between views which means lists can be set up for each project (called buckets in Planner) and providing those cards have been given a status of either Not started, In progress or Completed, switching views shows the cards in those three status lists.
  • Both allow a user and multiple users to be assigned to the card, both can have attachments and comments on a card, and both allow cards to be dragged and dropped between lists.
  • Trello doesn’t do any kind of reporting. Planners reporting is limited but it shows how many cards each person has in each state, how many cards are in each state for each bucket, and how many cards over the whole board are in each state.

It’s a close run thing. I’m not aware of anyone else in the organisation using Planner although I’m sure it would be really useful for them, especially as most of them don’t require the same level of flexibility as I do. If Planner had automation and adding cards by email it would win outright. Planners approach to switching between views of lists is really good (even if there is an overhead if selecting the right status, start and end date for each card). I think that Planner is good enough for us to consider moving to using it rather than Trello. And I never thought I’d say that.

What to do with your website when you’re on TV

‘Big cats about the house’ is a TV show about The Big Cat Sanctuary in Kent and tells the story of their head zoo keeper who takes young big cats into his home to look after them before introducing them into the sanctuary as ambassadors to help raise funds to support big cat conservation in the wild.

You probably want to ensure your website can handle the extra traffic that comes from such exposure, but just in case you should also have a backup.

Set up Cloudflare to display a holding page:

What to do with your website when you're on TV

Give people an offline means of getting in touch:

What to do with your website when you're on TV

Leverage people’s interest to drive donations:

What to do with your website when you're on TV

Give people a mobile-friendly donation platform:

What to do with your website when you're on TV

Using Freshdesk – what I’ve learned so far

Principles rather problems

It’s more important to be trying to adhere to principles rather than solving a particular problem (as the problem probably isn’t understood well enough, and will change).
We agreed on three principles.

  • Shared: We all work together to give the customer the best experience of the BHF. Customer experience is everyone’s responsibility.
  • Speed: We want to provide the fastest route to resolution for the customer.
  • Satisfaction: We want the customer to feel satisfied with the resolution, keep the relationship intact and maintaining the reputation of the BHF.

People drive processes

Any new system/product/business area needs someone to act as guide for others and make decisions and develop best practice. Without that people apply their previous ways of working to the new system, and then they don’t gain any of the benefits, and using a new system in an old way just creates drag on a process we’re trying to streamline.

Shifting mindsets

Emails are either replied-to or not replied-to, they have a binary state that doesn’t reflect the complexities of customer service.
Tickets in Freshdesk for Ecommerce Customer Services can exist in any of 224 different states, and some other teams have even more states. This means that each ticket can have a state within Freshdesk that more closely reflects the state of the customer’s enquiry in real life.
To use Freshdesk at it’s best we stop thinking about individual tickets, and instead think in states. So, it’s about asking “for the state of ‘Urgent and waiting on third party’, what’s going on in that state and is there anything I can do to make that state smaller and the ‘Resolved’ state larger?”

Empowering people

Calling them ‘agents’ is an interesting turn of phrase. They are agents of the organisation, representing the BHF. But to be agents they have to have a sense of agency, to be able to assume responsibility for their actions, to feel in control, to believe in their capacity to handle a wide range of tasks or situations. Freshdesk provides this. If software is the encoding of human thought, then Freshdesk is software that embodies this sense of agency.

The four R’s of Failure

Failure is closely aligned is Risk. Failure is what happens when we aren’t able to prevent the risk from manifesting. As we develop better ways to manage risks we should also consider the means for dealing with and learning from failures.

Resilience

Resilience is about preventing failures.

It requires:

  • analysis and prediction,
  • contingency planning, and
  • monitoring.

But:

  • how does Resilience embrace uncertainty and accept that not everything can be predicted or monitored?
  • how can failure be accepted as necessary for learning and be planned to be prevented at the same time?

Response

Response is about responding to and continuing to operate whilst a failure happens.

It requires:

  • broad knowledge of situation,
  • deep knowledge of the impact over time,
  • careful consideration so as to not make the failure worse,
  • priorisation, and
  • fast detection and early steps towards recovery.

But:

  • should we protect other work over prioritising dealing with the failure?
  • should an assessment of impact be the deciding factor over likelihood of the failure, and
  • should dealing with failure be a whole team responsibility?

Recovery

Recovery is about fixing the failure after it has happened.

It requires:

  • a plan,
  • resources to put the plansinto action, and
  • testing to be embedded in process.

But:

  • how do we maintain a close feedback loop with the Response phase to get the solution right, and
  • who should fix the failure, those involved in creating it or someone else?

Review

Review is about learning from the failure.

It requires:

  • documentation of actions, and
  • commitment and processes to make improvements to Resilience, Response and Recovery.

But:

  • how does it spread the learning,
  • and is it’s aim to prevent future failures or encourage them?

How we approach Risk and Failure is essential for fostering psychological safety, to enable rapid experimentation, to make people awesome. We tend to assume that failure is a result of fault. A fault occurs which leads to a failure, and if there is a fault then there must be someone at fault, someone to blame, someone who did something wrong or different. If dealing with failures is underpinned by this assumption then failure can never be looked upon as a positive. The best we can see is that at least the failure has been uncovered and fixed. And perhaps that is enough to drive some kind of iterative process of continuous improvement.

Good customer services gets you closer to the customer

Our new customer support system has been live for a week now, and we’ve already seen benefits in customers getting better answers quicker than ever before.

Of course serving customers better is really important, as is making the teams more efficient, but the real benefits come from getting closer to our customers. We now have a means of recording, collating and analysing the that are bothering our customers most.

Agile demands that we get closer to the customer. The manifesto says we should value individuals and interactions and customer services is one place where those individuals we are serve are interacting with the organisation.

So as we take steps to become a more agile organisation we should make real efforts to seize the opportunities that our customer services teams and system offer.

Agile Risks Meetup

I went to a meetup with a group of Agile practitioners discussing Agile ways of dealing with risks. It gave me lots of interesting things to think about:

  • Get close to the customer, really understand their needs, to reduce the risk of building the wrong thing.
  • Users who are choosers give helpful feedback because they can decide not to use the solution. If not, feedback is superficial.
  • Explore possible solutions concurrently before going on to build a single solution.
  • Ignore the likelihood of the risk and focus on impact.
  • Communicate risks and issues sooner rather than waiting until they become big problems. Don’t pretend to be green if things are really amber.
  • Deal with risks as you go along rather than identifying and only intending to deal with only if they arise.
  • Risk reduction = knowledge acquisition.
  • Learning about the risky things is building business value.
  • Traditional risk management focuses on ‘known unknowns’, but misses the ‘unknown unknowns’.
  • Unknown things often get put to bottom of the list but maybe they should be dealt first.

Improving our customer services

Today we went live with our new customer services system.

It’s a very Kanban-ish with all the tickets visible, each ticket having a status and states to move through (open, waiting & resolved), each ticket having an owner which means only one person can work on it at any time, and tickets having an SLA which serves to limit the work in progress.

The new system will help the eight people across three sites involved in customer services to be more coordinated in how they help customers and achieve our principles:

  • Shared: We all work together to give the customer the best experience of the BHF. Customer experience is everyone’s responsibility.
  • Speed: We want to provide the fastest route to resolution for the customer.
  • Satisfaction: We want the customer to feel satisfied with the resolution, keep the relationship intact and maintaining the reputation of the BHF.

Objectives are good. Outcomes are better.

The objective is to vacuum the living room carpet. The outcome is to have a clean living room floor. If you focus on achieving the objective you can vacuum the living room badly and not achieve the outcome. If you focus on the outcome you are more likely to achieve having a clean living room carpet and give you scope to consider other solutions like laminate flooring or a rug.

Appreciating the women in my life

I know a woman who inspires me to be the kind of man I want to be. She teaches me that courage is a prerequisite for life every day in every way, and that whatever difficulties occur they can be faced and overcome.

I know a woman who inspires me to be true to what I believe. She teaches me the importance of holding the highest ethical standards, of drawing a line in the sand that you won’t cross, and that being fair and true to the people around you is non-negotiable.

I know a woman who inspires me to think in different ways. She challenges me to consider my assumptions and opinions, and to expand my views on people and relationships.

I know a woman who inspires me to always keep on trying to make things better. She taught me the power of just getting on with it and getting it done, that things can always be improved.

#InternationalWomensDay