Roger Swannell

Tag: Modernagile (page 1 of 2)

Quantity quantity discussions rather than iron triangles

Waterfall says Resource and Scope should be fixed and Time is the variable for delivering projects. Agile (or maybe Scrum) says Resource and Time is fixed and Scope is variable.

Nothing is fixed

Fixing resource is kind of nonsense when by ‘resource’ we mean people. People take days off, have good days and bad days, get more done on some days than others, so resource is constantly moving in both quantity and quality. In reality nothing is fixed.

Scope = quality

When we talk about Scope we’re really talking about the quality of the solution delivered. Sometimes, if the quality of solution required is too great for the fixed length of time then the quality (scope) is reduced to fit the fixed length of time.

Time = quantity

When we talk about fixing Time, such as in a two week sprint, we are really talking about the quantity of output, the amount of work that gets done.

Quality / quantity

This is why the Scope / Time discussion is really a quality / quantity discussion. If you reduce the Time available to work on a solution you have to reduce the Scope of what will be delivered. You can have it in one day and the solution will be good, or you can have it in one week and the solution will be better, or you can have it in a month and the solution will be the best. Sometimes ‘good’ is good enough, and sometimes ‘good’ is all you have time for, but by fixing Time (and so fixing quantity) you limit the ability to deliver the best solutions.

Perhaps allowing the team to decide what quality of solution needs to be delivered, and how long that solution will take to build sets them up to do great work rather than doing just what they can fit into an arbitrary length of time.

Transparency because…

…stuff gets lost in hand over.
…sharing work creates faster feedback.
…communicating openly builds trust.
…responsibility and accountability are everyone’s responsibility.
…planning is easier when done in context.
…opportunities for convergence are essential.
…generalists learn together.
…course corrections happen faster.
…team culture should be nailed to the wall.
…decision making involves everyone.
…knowledge is power, and everyone should have the power.

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.

From working with an agency to working with a freelancer

Another example of figuring out how to work in a more Agile way in a risk-averse culture.

When you’re risk-averse, finding the right agency takes months. You follow the Procurement Policy, go out to tender to get five responses, do Dun & Bradstreet assessment, negotiate the contract, and then eventually you get to work.

When you embrace the uncertainty, finding a freelance developer takes days. You message a few on LinkedIn, have an informal phone interview, pick which one can do what you need and get them started.

There’s risk in moving from building a website with a reliable agency who you can have faith will be there tomorrow and next week and next month when you need them, to using freelance developers who can move on and take their knowledge with them at any time. So, how can you manage this risk?

Embracing the uncertainty, you make decisions quickly with what information you have, you break the work into small chunks, do a few pieces of work and then decide what’s next rather than creating a plan at the beginning of the project.

Will it work? We’ll find out over the next few months.

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.

Using Scrum vs. ‘Whatever it is that we do’

I’m not sure what you’d call our way of managing work, but this is what we do: We spend two minutes every week moving cards on our Trello board to show what we’ll be working on that week, and then we trust each other to get on with prioritising our own workload and working on with the things that have the most impact.

The Digital Team use Scrum. The Product Owner raises tickets in Jira, writes user stories, and prioritises the work they want done. The Dev team estimate the work, add it to the backlog and decide which sprint to fit it in. Once the dev work is complete the Test team test it and if the work passes it is deployed to the live environment. The Delivery Lead manages it all.

I don’t know what you call whatever it is that we do, but I like it.

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.

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.

Olderposts

Copyright © 2018 Roger Swannell

Up ↑