Roger Swannell

Author: roger (page 2 of 109)

Charities have to choose unsolvable problems

The biggest risk to a charity is solving the problem they set out to solve. If they solved it there would no longer be any reason to exist. So the aim for a charity is not to solve its chosen problem but just to make progress towards a solution. This is why charities have to choose unsolvable problems.

Certainty and uncertainty in value and duration

John Cutler tweeted about how he approaches forecasting with a team, and shared a Google Doc explaining the method.

One the second page was this:

This is important. It made me realise that initiatives can / should be considered / assesses / prioritised / forecasted on how certain or uncertain the value they will deliver is, and how certain or uncertain the duration is. Initiatives of unknown duration and unknown value are high risk compared to those of known value and known duration.

So, we need to have a reliable method for forecasting cycle time (not estimating effort time) to arrive at a known duration, and for establishing value (including cost of delay) as a known quantity.

Making these method of prioritisation explicit, reliable and robust is vital for across the organisation (not just within the digital department or within the scrum team) in order to be part of the mind shift towards delivering value continously.

Prioritising parking spaces

In an office with more people than parking spaces, we needed a fair way of choosing who should get one.

There are various ways we could have done but the best solution was priority based on length of service, so the longer you’ve worked at the office the higher up the list you go.

There are two reasons this is such a good solution:

  1. Length of service is a fact, and choosing who gets a parking space based on fact rather than opinion has clarity and transparency, and is easy to understand. And it turns parking into a benefit of long service.
  2. It means the older team members who are more in need of a parking space get one without getting into uncomfortable discussions about health, medical conditions, or who is most in need.

Even everyday things like allocating parking spaces require a method of prioritisation.

Finding the right way to prioritise is vital. Using facts is great. Making it clear and easy to understand for the people involved is important. Gaining additional benefits as a result of the method is a good thing to achieve too.

How do you eat an elephant?

One bite at a time, is the old answer.

But what if it’s an elephant today and a buffalo tomorrow? What if it looks like an elephant to one person and a dog to another? What if the elephant doesn’t want to be eaten? What if one person wants to eat the elephant and another doesn’t?

Then, you have to all agree it’s an elephant, and that everyone wants to eat it, and who’s going to eat which bit, and when to eat it, and how long it’s going to take to chew eat bite.

Suddenly, eating an elephant doesn’t seem so simple.

Building skills for building chatbots

Our events team wanted to build a Chatbot as part of the fundraising raising events acquisition journey.

They used the bot society simulator to design the flows and had intended to pay an agency to build the bot. Instead, I spent a couple of hours with one of the team to teach her the basics of building a Chatbot. She picked it up really quickly and built most of the bot in the first day.

Things I learned:
Digital transformation requires giving people the opportunities and space to develop new digital skills. This is more productive and efficient in the long run as it reduces reliance on external (and often costly) resources.

About using bot simulators specifically, beware of falling into the trap of thinking of the Chatbot as a visual interface like a webpage. Chatbots are conversational interfaces and need to be designed more as a two-way interaction then the kind of one-way passive interactions we usually have with screens.

Building something like a Chatbot yourself means you have a greater understanding of how it works, which will be a big help in iterating and improving the bot, puts the organisation in greater control of this and future Chatbots, and gives the team member another skill to go on their CV.

Scrum Training

I spent the day doing Scrum training with some of the teams who work on the BHF website. Everyone had different levels of experience of using Scrum and those who are currently working in Scrum approached the training in a very different way to those who aren’t. It was clear they were seeking answers to specific challenges they are facing.

For me, the interesting thing was talking about ‘Definition of Ready’, which is something I’ve not previously given much thought to. It’s obvious that a piece of work has to be ready to be worked on; clear requirements, stakeholder agreement, etc., but the idea that the more certain a thing becomes the closer it is to being ready connected with my thoughts about uncertainty and risk.

Using Scrum to read a book about Scrum

I’m reading Dr. Jeff Sutherlands book ‘Scrum: A revolutionary approach to building teams, beating deadlines and boosting productivity’.

Scrum: A revolutionary approach to building teams, beating deadlines and boosting productivity

It seems like a good opportunity to put into practice some of the techniques of Scrum to help me read the book productively.

User stories

User Stories are written in a ‘who, what, why’ format and are used to express the customer’s motivations and what they want to achieve.

Let’s write a user story:
“As someone interested in learning about Scrum I want to read a book about Scrum so that I can learn and think about some of the principles and practices of Scrum.”

Now let’s a quick look at the user story to help us understand what its not saying. So, I’m a user with an interest in Scrum, not a practitioner who needs to retain expert knowledge. But I do want to be able to reflect on what I’m reading and learn from it, but not memorise it or take notes outside of the book. It mentions thinking about Scrum but not putting it into practice which helps to keep it small, distinct and contained. If the user story mentioned being able to put Scrum into practice we’d have to consider the outcomes differently.

Definition of Ready

In order to tackle the user story and start a sprint we need a definition of ready. It should be help us know if the user story is independent, negotiable, valuable, estimable, small, and testable.

We’ve got our user story, and thought a bit about what it isn’t, and it meets the INVEST criteria, so we’re ready to go.

Definition of Done

We need to know whether I’m achieving what I set out to, so we need a definition of done which we can then use a) know what we need to get done in each sprint, and b) compare with our user story to know if we’re delivering value to the customer.

Our Definition of Done:
“A chapter has been read, and sentences that resonate with me, seem important, might be something I want to look back on, or ideas I want to think about have been underlined.”

Reading in Sprints

As this user only gets time to read during my commute we should set our sprint length as 15 minutes. My commute is longer than 15 minutes but with distractions and ‘reading with a pen’ 15 minutes of focused reading is achievable.

Measuring velocity

Chapters are not of equal length so there aren’t a good measure to use, even though they are mentioned in our definition of done. Perhaps we should use pages as our measure as they are of fixed length. We have to take into account not just the reading but the underlining and thinking, so let’s say that to start with a velocity of a page a minute. There are 238 pages in the book (let’s round up to 240 for ease), which equals 4 hours of reading. Divided by our 15 minute sprint length means it’ll take me 16 sprints to finish the book.

I’m on page 146 right now so this is what my burndown chart looks like:

How could we increase velocity? I could underline less, or think less about what I underline, but then would I be achieving the definition of done? Reducing scope reduces value delivered. I could focus more during the sprint to reduce the time it takes to read a page and so increase the number of pages I can read during each sprint.

Of course, if I’d spent the time reading instead of writing this blog post I’d be even further forward.

Three tricks with Microsoft Planner

Search

There is no search. But you can filter by keywords to get what are effectively search results. Filtering is a better approach than searching as it also enables you to filter by when a card is due, who it’s assigned to, and which bucket it’s in.

Outlook

Planner provides an iCal feed which can be pulled into an Outlook calendar to show as Meeting items. So, if you like using Outlook to manage your time and tasks, you can use this feed to show cards based on their start and due dates. And if the items in Outlook could be coloured (perhaps by bucket or label), then the Outlook calendar would start to be a bit roadmap-y.

Checklist items into cards

Items in a checklist can be promoted to cards by clicking on the up arrow that shows when you hover over the checklist item. The card is created in the same bucket as the card with the checklist but has no associated attributes such as due date, status or assignee.  An improvement on this might be being able to choose to copy and/or set the attributes from the parent card when promoting the checklist item rather than having to go into the card after it has been created.

What skills does an Ecommerce Manager need?

I saw a blog article that said Ecommerce Managers need skills in user experience, prioritisation, brand & marketing, personnel management, and project management.

Ecommerce seems to often be thought of as just about running an ecommerce website, but I’ve never had an ecommerce role that was solely focused on the website so I’d also add:

  • Strategy.
  • Stakeholder management.
  • Supplier management.
  • Agency management.
  • Legal and compliance.
  • Contract negotiation.
  • Logistics.
  • Warehouse management.
  • Customer Services.
  • Budget management and financial planning.
  • Marketing, including email, social, advertising, content.
  • Design.
  • Conversion rate optimisation.
  • Commercial planning.
  • Analytics.
  • Data Protection.
  • Reporting.
  • Product development.
  • Buying and merchandising.
  • Order process management.
  • Technical.
Olderposts Newerposts

Copyright © 2018 Roger Swannell

Up ↑