Roger Swannell

Tag: agile (page 1 of 3)

Why businesses need greater agility

Agile businesses respond to change quickly

Drawn on the back of a napkin at breakfast

How it used to be

The rate of change customers experienced was constant so businesses could go through a period of change to catch up with their customers and plateau for a while before going into the next period of change.

How it is now

The rate of change that customers experience grows exponentially, but businesses still implement change in the old way which means they get further behind the needs of their customers.

How it should be

Businesses change at an exponential rate to keep up with their customers and better serve their needs.

5 digital trends charities should definitely not avoid in 2019

This JustGiving blog post includes five “trends” (it’s questionable whether these five things are actually trends; a trend is the direction a thing moves or changes not the thing itself, but moving on…) that charities should avoid in 2019. I’m not sure blanket statements about what charities should avoid is very helpful so I wanted to reconsider them.

I agree that charities probably do need more focus, but given that the charity industry is going through massive changes and challenges, not least of which is concerned with how to be more innovative, perhaps the ‘head in the sand’ approach of avoiding things just because they haven’t necessarily reached the plateau of productivity on the hype curve may be counterproductive. There are models for considering new things (such as McKinsey’s three horizons) that can foster discussion rather than shutting down the conversation and prepare charities with a healthy pipeline of innovative ways to achieve their objectives.

Viral campaigns

A bit like buying a lottery ticket instead of learning how to earn money from an actual job every day

That senior management in charities prioritise short term fundraising initiatives in the hope of making a quick buck suggests a misunderstanding either on the part of management or marketers, but I struggle to accept that all the very smart people that I know who run and market charities fall into such an obvious trap.

Virality has a scientific definition. It is an achievable thing with sufficient planning and resources. The ability to understand and utilise vitality in trends should be one of the tools in a fundraisers bag, not at the expense of longer term planning, but as a means of leveraging current events and temporary things that pop up in the consciousness of people.

#Firstfiver was a great example of a viral campaign that could of benefited far more charities than it did if more of them had already considered how to solve the logistical challenges of getting paper five pound notes in people’s pockets into a physical donation tins. A charity that has prepared ahead of time to respond to raising trends, not just by sending a few tweets with a hashtag, but by offering solutions for members of the public to support a charity they might not usually consider could leverage a trend into a significant financial contribution.

So if 99.99% of charities choose not to consider the potential for viral trends in their marketing and fundraising planning for 2019, then that leaves more space for the .01% who do decide to commit to building the capacity to responding quickly to events in a fast changing world in a way that amplifies the trend and achieves their objectives, be they awareness raising, income generation, or mass action.

Digital transformation

Transformation’ implies magical, overnight change

If digital transformation is being communicated as an overnight solution to all a charity’s ills then it is the communication that is at fault, not digital transformation. Just as the industrial revolution took hundreds of years to play out, so will the digital transformation of our society. It already and will continue to touch every part of our lives, from our health care records to traffic management to paying for a coffee. Digital transformation involves transforming technologies, cultures, mindsets, behaviours and thinking. It cannot be thought of as a quick fix.

Charities that don’t adopt the mindset and adapt to this changing world will find themselves irrelevent in the eyes of their staff, volunteers and supporters. Can anyone imagine engaging with a charity only through face-to-face contact because they don’t have a website or use email? No, of course not, because every charity has a website and uses email, so their digital transformation has already begun. To ignore ongoing transformation in 2019 and not embed digital into their strategy, not improve the reach, efficiency, and cost-reduction benefits of online fundraising, not support their staff and volunteers to improve their digital skills, will leave a charity even further behind. Charities should be accelerating their digital transformation in 2019 and beyond.

Bitcoin

There are just three problems with Bitcoin

There are just three solutions with Bitcoin (and other cryptocurrencies of which bitcoin is one of many).

Mining bitcoins does take a lot of energy. Generating renewable energy from wind power had the same inefficiency issue when it was introduced. It cost more to produce the power than it was worth, but pioneers and early adopters used and developed the technology into a viable alternative and soon it will be more cost-efficient to use renewable energy sources than mine for fossil fuels. The more organisations looking at opportunities to leverage the benefits of cryptocurrencies, the more funding will be driven into development, and the more efficient and viable they will become.

Bitcoins are a currency used on the dark web, but far more criminals use cash. Does this mean charities shouldn’t accept cash? Of course not. Criminals using something does not mean a charity shouldn’t use it. There is no logical argument here for charities to not spend time understanding how cryptocurrencies might affect them or be utilised by them.

Third – and this is a big one – people who donate to charities just don’t use it… yet. No one used contactless cards to donate to charities.. until they did. But charities exploring options around cryptocurrencies should involve more than just taking donations, they should be looking at how cryptocurrencies will change their investment portfolio, how it may change banking practice and consequently their finance governance.

Charities might not be committing significant resources to building the systems and skills to take bitcoin donations in 2019, but cryptocurrencies should definitely be in their horizon three initiatives with people in Digital, Technology and Finance thinking about how to handle bitcoin and cryptocurrency in the near future.

Blockchain

Treat blockchain like I’m a Celebrity – Get Me Out of Here! By all means, watch it and follow it, but don’t spend precious work time on it

In the early 70’s when the relational data model was invented lots of people thought it was useless. Why would you want to establish a relationship between two pieces of data? Nowadays relational databases power every charity’s CRM system.

Blockchains are decentralized, distributed, sometimes-public digital ledgers that are used to record transactions across many computers, which although not the answer to every data storage problem, do have some specific uses which can apply to and benefit charities. Where a charity is working with multiple organisations who all contribute data, and all parties want unshakeable assurance that the data is reliable, and those partnerships require that no single organisation is the owner and controller of the transactional record, then blockchain might be a solution.

Blockchain will increase in prevalence over the coming years and become the de facto solution where data needs to be decentralised and distributed across a network to ensure trust in the recorded transactions. So if charities aren’t giving serious thought to use cases for blockchain and would rather continue in the mindset of centralising data under their control and watch reality TV shows instead, then they will find themselves investing in the wrong solutions in the very near future.

Agile

But don’t spend precious time importing agile wholesale when it’s a square peg for a round hole.

Referring to the original manifesto for agile software development as the only source of thinking about Agile is very limited, as is only referring to Scrum when speaking about Agile. Being agile means (among other things depending on whose thinking you’re referencing) getting closer to customers, working in small batches, having short feedback loops, and responding to change. Navy SEAL teams use Scrum to improve ownership among team members. Marketers apply agile thinking when they involve customers by testing ideas ahead of launching a campaign. There are lots of examples of how Agile can be applied to more than just software development.

Charities should most definitely not be avoiding working towards achieving greater agility, “moving with quickness, ease and grace“, as Joshua Kerievsky puts it. Agility is a key competitive advantage that has been realised in almost every other industry. If charities don’t become far more agile than they currently are they run the very real risk of being left behind, not only as an organisation but as an industry. They will quickly be overtaken as more agile startups and businesses move into their markets. There is nothing that charities do that could not be usurped by a business, leaving the charity behind and irrelevant in the eyes of its supporters. Having agility is essential for charities to keep pace with the changing modern world and people’s changing expectations.

 

 

There are lots of other innovative developments in thinking and technology in addition to these five that I also think charities should also be considering in 2019, things like machine learning, 3D printing, co-creation, autonomous teams, digital twins, the quantified and augmented self, AR & VR, voice & virtual assistants., etc., etc. A charity that has all of its focus on the mainstream technologies and thinking of the past is being left further and further behind. Charities need to be exploring all the new ideas they can using a robust innovation model that allows them to extract value at the right point in time.

A roadmap to where

There has been quite a bit of interesting discussion on Twitter about Roadmaps; what they should include, how they should be structured, how to make them useful for agile teams.

A roadmap shows the direction and the destination. If we think about actual roadmaps, where the metaphorical roadmaps we refer to come from, they show all the possible destinations (towns, cities, etc.) and all the possible routes to get there (roads). Typically, if you wanted to get to a particular destination (achieve an outcome) you would start heading in that direction, but if an obstacle was in your way you’d change route but still be heading in the same overall direction towards the destination. Some routes are faster, some routes are more interesting.

So, a good roadmap (back to our metaphorical roadmaps now) should show the outcome that we want to achieve (destination) and provide some direction of travel as a guide to keep teams moving towards the destination. The direction of travel acts as strategic bumpers to help explain the ‘where to play’ decisions but gives the team enough room to decide on the route for themselves.

Roadmaps that explain the destination and the direction of travel become ‘who & why’ roadmaps rather ‘what & when’ roadmaps. ‘What & when’ roadmaps are misleading and often obscuring because they try to define what the team should build before they’ve started the journey and when they’ll be able to do it. ‘What & when’ roadmaps show uncertainty as a pretend certainty.

So, we should accept that ‘Roadmap’ is an incomplete phrase. We should be clear about it not meaning ‘A roadmap of what to build when’. We should be clear about ‘roadmap’ actually meaning ‘A roadmap of why we’re building and who we’re building it for’. Then roadmaps become about achieving an outcome (getting to the destination) rather than the stops along the way. Then our phrasing can become more specific; ‘A roadmap for achieving x for y’. That could be ‘…achieving product/market fit for our idea’ or ‘…achieving 30% time saving for regular subscribers’.

Different teams move at different paces

I drive a sports car. You drive a bus. I can get myself there quickly. You can get lots of people there slowly. You can’t make a bus handle like a sports car but you can tell people to get off the bus and find other means of transportation.

No deadlines

Scrum works for cross-functional teams of specialists that only work on one thing at a time and have everything they need within the team to complete the work.

Scrum has the #NoEstimates movement that says slicing work small enough enables teams to incrementally deliver value without requiring any kind of estimation.

But Scrum doesn’t work for multi-functional teams of generalists that work on lots of different things at the same time and have to work with other parts of the business to accomplish their goals.

I’d like to propose #NoDeadlines for modern agile teams not using Scrum and working in ways that mean the work they are doing requires collaboration with other people and teams who also have other work and different priorities, and which is often out of the teams control.

#NoDeadlines recognises that it’s impossible to accurately predict when work will be completed if it is dependent on people that aren’t part of the core team doing the work. The more people and teams involved, and the more things those teams are working on, the more impossible it becomes to accurately predict when any piece of work will be completed.

Commitment to deadlines should only be made if everything that is required to meet that deadline is within the control of the person making the commitment. If any element of the work requires input from someone who isn’t part of the team doing the work, isn’t asked to commit to the same deadline, has other priorities, works to a different schedule, or suffers no consequences from not meeting the deadline, then deadlines should not be set.

Deadlines set in these kinds of situations are at best completely arbitrary and at worst pure fantasy. Communicating fantasy deadlines to other parts of the business undermine the team when those deadlines aren’t achieved because the team needed input from other people who weren’t committed to the work in the same way.

Not setting deadlines takes the pressure off of teams from chasing unrealistic fantasy deadlines that they don’t have control over and provides psychological safety to experiment rapidly and focus on delivering value to the customers when that value is ready.

Buying and merchandising teams have always been Agile

For a Buying and Merchandising Team performing quite a traditional function for a business that is moving towards a more Agile approach, the uncertainty around impending changes could be a cause for concern. But they shouldn’t be. I think Buying and Merchandising Teams are already working in quite agile ways.

Accepting change

Merchandisers will start a year with a target for how much they think a product will sell, which they use to buy the right quantity of stock. They’ll create a plan based on last year’s sales information to suggest how much will sell, when and where (which shops), but

Merchandisers inspect the sales and adapt the replenishment of stock to shops to maximise the sales potential.

Small batches

A merchandiser could send all the stock they have out to shops at the beginning of the season, but instead, through analysis of sales patterns they break the stock down into small batches and distribute it to shops for when they need it.

Merchandisers slice the available stock into small batches.

Fast feedback

New products are introduced in a disciplined way. They are bought in smaller initial quantities, trialled in a small number of shops, and watched carefully to see how they perform. These initial reactions are then used to plan further roll-out of the product to more shops, or discontinue the product.

Merchandisers get fast feedback from customers and use it to inform how to distribute stock to shops.

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.

Moving to Scrum roles

As we figure out how to go about bringing the management of our ecommerce platform in-house and fit it into our existing product management approach, some questions about the roles people play have come up.

In the old way of doing things, as the ecommerce subject matter expert, person with the most Magento knowledge, and owner of the relationship with the agency, the role of Product Manager would have fallen to me. But that doesn’t fit with the new way of doing things.

In the new way of doing things, I’m the customer (which seems a little non-sensical to me as I’m not the end user who will be extracting value), and we’ll have a Product Manager who will collect my requirements and write user stories for the Developer, and a Delivery Lead who will manage development.

It’ll be a challenge for me to give up control to others but I know it has the potential to be better in the future, and I think it’ll be a challenge for the Product Manager and Delivery Lead who are already at full capacity

User stories or business requirements

Why write User Stories?

User stories help us to understand what a customer needs to happen in order for them to achieve their objective.

User stories are one of the outputs in the journey of helping customers achieve their outcomes, but they are only an effective toll for this if the other steps of the journey have lead us this way. If we’ve never spoken to a customer to understand their needs, then we cannot write an authentic user story to express those needs.

Often, rather than having user stories that express the value outcome a customer is going to achieve, we have business requirements that describe the functionality the business expects to be delivered.

 

Writing business requirements instead

Business requirements are different to user stories. They are taken from parts of the business that haven’t spoken to any customers and express what is expected to be delivered in return for the investment of time and/or money.

Writing business requirements isn’t bad. It isn’t any less agile than writing user stories, but it is what it is, and shouldn’t be falsely wrapped up to look like user stories and pretend that they originated from the customer or to convince us that by delivering against those requirements we’ll achieve something for the customer.

 

Both are about delivering value

Both user stories and business requirements have their place. They both express a value exchange. One is between the customer and the business, and the other is between two parts of the business. If we want to deliver value continuously (which we most definitely should) then we need to be clear who we’re delivering value to.

Olderposts

Copyright © 2019 Roger Swannell

Up ↑