Scrum Training

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:

Scrum book burndown

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.

More scrum versus whatever it is that we do

You iterate, we evolve.
You work in fixed time boxes, we let each thing grow at it’s own rate.
You have a definition of done, we try never to finish anything.
You burn down work you’ve done, we stack up things we’ve achieved.

Continuous improvement throughout the whole process

Washing up has five stages:

1. Eating on clean plates
2. Stacking dirty plates next to the sink
3. Washing the plates
4. Stacking clean plates on the draining board for drying
5. Putting away the clean plates

At stage 5, putting away the clean plates effectively depends on how the plates are stacked for drying. If all of the same types of items are placed together then it’s easier to put them away without having to go through an in-between stage of sorting them. These in-between stages activities that creep in appear to be adding to the efficiency but don’t actually tackle the underlying issues that are causing the inefficiency.

At stage 4, stacking the clean plates on the draining board in the right way depends on how you wash them. Efficiency can be improved within the stage to ensure the items dry quickly, such as stacking saucepans upside down with larger ones on top of smaller ones to save space, but just gaining efficiency within the stage could lead to less efficiency across the entire process so its important to take feedback from outside the stage.

At stage 3, washing the plates in the most efficient way depends on how they were stacked before washing. If all the plates will be washed together then they should be stacked together. And groups of items should be washed in a particular order, with cleaner items washed before dirtier items to maximise the cleanliness of the water.

And at stage 2, stacking dirty plates next to the sink and making them ready for washing depends on knowing how they are going to be washed at stage 3. So, sharp knives are kept separate for safety, plates are cleared and rinsed, and types of items are stacked together.

Processes can only be efficient as a whole if each part of the process is efficient. If one part doesn’t receive feedback from the other parts it can be organised efficiently for itself but reduce efficiency across the whole system.

Don’t assume the experts know everything they need to know

Bring in the expert

I’ve been involved in a few projects where an expert in a particular field was tasked with working on an aspect of the project. It was assumed that as they were experts that they should be able to figure what is required and come up with the best solution. Invariably they don’t. Being experts doesn’t make them mind readers.

Tabla Rasa doesn’t work.

There is no such thing as a blank slate. Briefing is important. Providing background and contextual information helps the expert to see where their contributions fit in, working in isolation with the barest of facts may seem like it helps the expert focus but it makes the work harder and means the results won’t be what was expected.

Self-organising shouldn’t mean isolated

With Agile adoption came the idea of self-organising teams that could be given a piece of a project and then left to figure out the best way to deliver that piece. The downside of taking this approach too far is that the teams of experts aren’t involved enough with the other aspects of the project, they work in isolation, and produce out-of-context and sometimes unusable results.

The removal of digital

I read Robert Green’s blog post about digital getting out of the way for fundraising and not using the term ‘digital’ in team names.

It reminded me something an old manager of mine said, “One day, having a social media team will be thought of in the same way as having a telephone team”. He meant that everyone has a telephone on their desk and knows how to use it, and that social media and using it to talk to customers would be something everyone in a business does, it wouldn’t be owned exclusively by a single team.

Whilst I’m not sure social media teams would agree as arguably social media platforms have gotten more complex since then, the point is easily transferable to ‘digital’.

Digital is a mindset and a skillset that everyone who works in a twenty first century business should possess. Organisations may take the same approach as CRUK and choose not to have a separate digital team, such as Halfords which split it’s digital team and joined them with the IT and Marketing departments. Or organisations may use a hub and spoke model with a core digital team doing customer-facing digital activities such as website development and performance marketing, but with the intention to push out digital skills into other parts of the organisation. Or an organisation could choose to have a single central digital team who manage all the digital activities for the organisation.

And perhaps, as Robert suggests, you can measure an organisations digital maturity by the model it uses. A really digitally mature organisation just does ‘digital’ without even thinking about it as separate from doing ‘reporting’ or doing ‘writing’ or doing ‘customer service’. I remember a few years ago, CRUK’s head of digital as he was then, saying that he wanted the people at CRUK to be as digital at work as they are at home. No one sits and home, switches off the TV, and thinks, “I’m now going to be ‘digital'”, as they put Netflix on, they just do it. Maybe removing ‘digital’ from team and role names is big part of being as digital at work as at home.

Bug fixes in everyday life

Things go wrong all the time. As part of my thinking around dealing with failure in a constructive and restorative way I’ve been thinking about ways of monitoring the performance of a system and how if something goes wrong, the failure is recorded and prioritised by the impact it has on normal functioning.

Some definitions

When I say system, I don’t mean software, I mean whatever complex social, intellectual, technical, political, emotional system we exist as individuals and as teams. I’m talking about business a bit, but mostly I’m talking about life.

When I talk about failures I’m talking about bugs as something that occurs that prevents the system from proceeding as expected. There are three parts to that; ‘occurs’ means the bug has to be something new that happens, not an existing on-going problem. ‘Prevent from proceeding’ means the bug causes a change of direction from the course that life/the system was following. And ‘as expected’ means that the course doesn’t need to have been a documented plan, there just needs to be an expectation about how things should be.

A personal experiment

So, to see what I can learn about failure I’m going to write a bug report for everything that goes wrong for me in a week. I’ll include:

  • What went wrong.
  • What impact did it have.
  • What did I do to deal with the failure.
  • What could I do to prevent it occurring again.

After a week of consciously considering how these everyday bugs occur and what impact they have, I will hopefully learn something useful about dealing with failure.