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.
What can we do about Workshop Remorse?
A workshop is arranged with the goal of solving a particular problem. Let’s say the problem is that the pages in a section of a website have become messy and need to be reorganised to improve the usability for visitors. The workshop uses a card sorting exercise to rearrange the existing pages and create a new structure. Everyone in the workshop accepts it and agrees the next steps.
Then… a few days after the workshop, some worries start to creep in. Things like, what if the changes affect our page search rankings, what if the changes make it harder for my customers to do what I want them to do, what if my manager doesn’t like the changes I agreed to.
That’s workshop remorse.
So then the emails start, emails that communicate those doubts and create little speed bumps. Shared among the group those worries multiply, and quickly people start to think of reasons why not to do what was they agreed at the workshop. The speed bumps grow into road blocks and everyone agrees that it would be better to wait some for seemingly connected thing to happen before we go back to solving this problem.
That’s the impact of workshop remorse.
How can we tackle it?
Every workshop should be about creating a space that has psychological safety for those involved. They should feel safe to say things they wouldn’t normally allow themselves to.
Maybe a part of a workshop should be spent talking about fears, concerns, barriers, internal agendas and organisational politics to bring this remorse to the forefront before it happens. Talk about it and tackle it.
Let’s see if by making the organisational politics visible we can challenge it. There’s no blame, we are all victims of our organisational culture and all implicit in creating it, so let’s be open about it.
Let’s see if by admitting our fears and worries we can overcome them and take control of them rather than allowing them to impact the work we want to do. It’s fine to have fears, we’re all human.
Let’s see if by talking about internal agendas we can reach some shared objectives that help everyone achieve. It’s not a zero sum game. One person doesn’t have to lose in order for another to win. We can all win if we work together.
What could we do?
We could hold a ‘Confessions time’ as part of the workshop. Maybe people would feel like it’s ok to open up.
Someone who has been workshops like this before might say: “I’m concerned that we’ll do this exercise but it’ll take so long for us to make any positive changes that we’ll all lose our enthusiasm and it’ll feel like wasted effort.”
The person running the workshop might say: “My worry is that you all won’t trust in the process and will want to feel in control of what we produce rather than allowing what users want to guide us.”
One of the less confident people in the group might say: “I’m worried that my part of business will be under-represented and I won’t achieve what I’m supposed to.”
And so everyone starts to understand how everyone else is feeling.
Then we can get on with the card sorting, because actually the workshop isn’t really about organising pages on a website, it’s really about having a safe and inspiring place to work, it’s about how we can improve the organisation one step at a time, its’ about people working together to create something awesome.
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.
Quality 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 continuously.
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.