Roger Swannell

Tag: agile (page 1 of 3)

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.

Handling risk in an Agile way

I’ve been thinking a lot about how an organisation with such a strong tendency towards risk-aversion could become more Agile in how it deals with risks associated with projects and programmes.

For a charity, risks come in all shapes and sizes, from risks associated with spending supporters money to risks of fines from the ICO. Risks to reputation that affect public opinion and supporter’s trust are important, so the objective here isn’t to ignore the risks and be reckless, the objective is to find better ways of reducing risks where possible and handling where necessary.

 

Risk-averse decision-making

In a risk-averse culture, risks are mitigated in two ways; 1) attempt to make the risk as known as possible by getting as much information up front as possible, and 2) involve as many people as possible to use their knowledge and experience, and to spread the blame if something goes wrong.

 

Making risks known

The first step to making decision in a risk-averse culture is about getting as much information about the risks up front in an attempt to make decisions about which direction a project should go. It seems to make sense that the more information we have the better decisions we’d make, but research suggests that experienced decision makers don’t make significantly better decisions with significantly more information provided they already have good domain knowledge.

So perhaps the lessons here is that you don’t need all the information in order to make a decision, and that the experts should be the ones making the decisions.

 

Involving lots of people

In a risk-averse organisation the number of people involved in making a decision is often in double figures. But if everyone knows and everyone agrees, then no one gets the blame if something goes wrong.

But this way of spreading the risk only really fits if the risk is considered as one big risk. If the risks were considered as lots of small risks, then they could be tackled in a different way, with the right people taking responsibility for the right risks rather than everybody taking responsibility for the whole risk.

So maybe the lesson here is that risks can be dealt with better by breaking up into many smaller risks.

 

Agile controls risk by accepting uncertainty

Managing risk in an Agile way means accepting that all the information isn’t known up front, and that more information can be brought to light throughout the project by performing small tests along the way to find out what happens when the idea meets reality. This is instead of the more traditional risk management approach of identify all the risks up front, make decisions about the future direction of the project, and only find out if the idea survives contact with reality when the project goes live.

Modern Agile says to ‘Experiment and learn rapidly’. This fits. We can de-risk projects by testing small and testing early, and using the learning to make any course corrections.

Agile or not: dealing with uncertainty

After going to a ‘Scrum of scrums’ meeting this morning, and then watching how we tried to deal with an uncertain situation by trying to find certainty this afternoon, I was thinking about what it means to be ‘doing Agile’.

And in one of those synchronous moments (with the help of Twitter) I stumbled across a blog post called ‘Agile is dead‘. It wasn’t the post, it was the name of the blog that gave me a little light bulb moment; Extreme Uncertainty. It made me remember what Agile is really about. Agile is about dealing with uncertainty.

If you work in two week sprints but your way of working doesn’t help your team or organisation dealing with uncertainty, you aren’t Agile, whether you like it or not. If you do things that help your team or organisation deal effectively with uncertainty, then you’re Agile.

Olderposts

Copyright © 2018 Roger Swannell

Up ↑