Roger Swannell

Tag: agile (page 2 of 3)

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.

Modern Agile vs. traditional and rigid

Modern Agile

Make people awesome vs. make people fight to be successful

When people often have to fight the organisation in order to let it do the job it hired them to do, how do we create an atmosphere where people feel able to offer their skills and experience to other teams, are empowered to choose the highest impact work, and focus on work that adds real value for customers?

Make safety a prerequisite vs. a culture of risk-aversion

When in a traditional organisation, in a traditional industry, where reputational damage and avoiding any risk of losing customer trust is the greatest concern, how do we help people develop a sense of emotional and professional safety where it’s ok to challenge others, to make mistakes, and try things that help us learn?

Deliver value continuously vs. launch it & leave it

When there’s always something new to be moving onto, another new project or product to launch, how do we build things in a way that means we can develop and improve them to better meet customers changing needs and increase the value we provide?

Experiment and learn rapidly vs. write a business case and get approval

When the process for any new venture is to write a business case, gain support, and get approval from all the right people, how do we move to quickly setting-up experiments so we can learn what customers want and what might work before we put considerable time and effort into building something?

What if driving followed Modern Agile principles?

How might driving on UK roads look if everyone was applying Modern Agile principles to their driving?

Modern Agile Driving

Make people awesome

Everyone wants to get where they’re going. If driving was Agile, and all drivers were trying to make each other awesome, there would be more cooperative driving where everyone has as their aim helping everyone get where they’re going, rather than focusing on where they want to go ahead of all the other drivers. Everyone would arrive where they wanted to go feeling less stressed and more awesome from helping others get where they wanted to go.

Make safety a prerequisite

Everyone wants to be stay alive. If everyone made safety a prerequisite of driving, everyone would always wear a seat belt, not use mobile phones, or drink and drive, and keep sufficient stopping distance between them and the car in front. Everyone, drivers, cyclists, and pedestrians, would be treated with more respect, feel more respect, and be much safer.

Experiment and learn rapidly

Everyone wants the best experience. If everyone experimented with what routes they take, what time they travel, what music they listen to, what they wear whilst driving, etc., etc. they could improve their experience of driving. Everyone would drive less on habit and learn different ways to improve their experience of driving.

Deliver value continuously

Everyone gets more out of driving than just getting somewhere. If everyone who valued fuel economy knew how to drive efficiently they would receive continuous value in reduced fuel costs, and there would be environmental value too. If everyone who valued nice scenery over shorter journeys took more scenic routes, they would receive their value in seeing different landscapes and add value to the drivers who want shorter journey times by avoiding more direct routes. Different values can be delivered continuously and concurrently.

This quick thought experiment taught me two things; Modern Agile principles could be applied to almost any set of circumstances where human beings are doing some kind of shared activity, and, in order to actually work, all those people need to be able to communicate and agree to use all the principles.

Exploring modern agile principles: Make people awesome 

As my interest in Modern Agile grows I’ve been looking for situations at work from which I can learn about how to apply the principles and how to work in a way that makes people awesome.

Modern Agile

There is a project team (who aren’t Agile) who seem to have a culture of focusing only on what they need. They don’t seem to be able to hear the needs of anyone else from any of the other teams they work with. I can see how this culture can develop in a team that is so completely focused on hitting deadlines and not having any part of the project slip beyond its allotted schedule, and I can see how this culture is the opposite of the Modern Agile principle of making people awesome. In this situation, the people that work with that project team don’t feel awesome because they aren’t listened to, and are given the message that the project team are able to command their time and effort without being able to feedback on whether they are focusing on the right things at the right time. And I doubt that the project team feel awesome as they probably feel like getting anything done is a struggle against the people who are supposed to be supporting them on the project (of course, they don’t recognise that those people have other work to do outside of the project because they are so focused on their project).

I’m not going to try to suggest a solution to this problem as I don’t think the situation/culture will change, but I definitely want to learn from it. So, I’m going to try to:

– Communicate more clearly,
– ask questions to encourage discussion,
– remember that other people have their own priorities,
– actively listen for implied meaning and ask follow-up questions,
– ask what they need to be successful,
– allow open honest conversations,
– and encourage everyone to be able to positively challenge what anyone says.

I hope that if these practices become part of the projects I’m involved with then we can all help to make each other awesome.

Agile Digital and Ecommerce teams at the BHF

The BHF Digital Teams, like many digital teams, take Agile approaches in their work.

The Digital team uses Scrum with Product Managers writing user stories from other parts of the organisation and taking them to the Development team for prioritisation and planning. The Dev team consists of front end and back end developers, business analysts, and testers. They estimate the size of the tasks and work in two week sprints to complete the tasks. Using Scrum means that once the tasks are prioritised for that sprint they don’t change it. This works well for software development as it’s repeatable work that benefits from a timeboxed approach to deliver value.

The Ecommerce team uses Kanban. We aren’t specialists like the Dev team and our work often involves a broad range of work, including customer service, logistics, developing merchandise, marketing campaigns and products, as well as website development. We accept that with priorities changing rapidly and with what work we can undertake being dependent on others, attempting to plan with any degree of certainty or timebox our work isn’t going to be an effective. We maintain a high-level roadmap that shows what we expect to be working on over the next few months, and we have a very low-level tasks list that we refer to and update daily. This works well for ecommerce projects as the priorities change quickly and often.

Digital Team using Scrum
Ecommerce Team using Kanban
Cross-functional team of specialists, including Product Managers, Developers, Testers, Business Analysts, UX.
Single functional team of generalist who cover Platform Development, Customer Services, Logistics, Marketing.
Daily stand-up meetings to estimate, prioritise and assign work.
Weekly planning meetings to prioritise projects for the next few days.
Works in fortnightly sprints to complete predefined tasks.
Works in continuous flow with priorities changing daily.
Uses a ‘push’ system with work forecasted weeks ahead by the Product Managers and Developers.
Uses a ‘pull’ system with demand from the business and/or customers deciding what work is focused on this week.
Kanban isn’t better than Scrum, or Scrum better than Kanban, each works for the team that applies it in the right way for them.
Olderposts Newerposts

Copyright © 2019 Roger Swannell

Up ↑