Making your own Way of Working — Part 1
This is part 1, you can read part 2 over here.
I’ve always been a firm believer that frameworks like SCRUM are just hints or guides on a way to defining how your team might be able to work.
Ultimately the true power of being Agile comes from it’s values and the willingness to adapt, change and learn based on what you discover as a team, eventual taking off the training wheels of whatever framework you started with.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
- The Agile Values which I use as a litmus test for decisions we make
This is the first part of the journey we went on at the SWM — WAN Digital team to come up with a way of working which aligned as closely to the Agile values as we could.
Borrowing from Design Thinking
Before you get started to need an approach. If we were using a “off the shelf” framework this would be easier. “We’re doing SCRUM, here’s the guide, let’s do this thing”.
But as coming up with your own way of working carries a lot of uncertainty I can’t think of a better mindset then that of a Designer.
This translated into the following rough plan;
- Define the Problem we are trying to solve
- Define our Current State
- Define an Ideal Future State
- Create a set of team Values and an even more kick-ass culture
- Experiment, iterate, and improve from there
The last step is important. When it comes to your culture and way of working you’re never “Done”. Nothing is etched in stone. People change and the people in your team will change. You need to be prepared to try new things out and admit when something isn’t working out. More on that later.
How Might We…
You step out the door and you aren’t quite sure where you’re going, you just need to head “Northish”. That’s what the problem statement does, it tells you roughly where North should be and is set in the form of a question ‘How Might We…?’.
To create this I held interviews with the management team and then a Retrospective aimed at digging up the current issues and concerns in the team (for specifics we ran a team SWOT followed by one of my favourite retro formats the ‘Sailboat’ activity).
Once these initial conversations had wrapped up I created a ‘How Might We…’ statement to guide all of our thinking and process changes from here on in.
This is what we settled on:
How Might We engage, support and enable the team in a new way of working which delivers value to the business through more responsive, metric driven processes
This statement, and every step of this process was co-designed, validated and endorsed by the team. This is really important! It might feel slow, and it might be frustrating waiting weeks or months to take that next step.
Leaping ahead without everyone on board will cause so much more pain and heartache then waiting until everyone is ready to take one step.
How do we currently work?
Once we had a defined problem we wanted to solve the next step was to “pop the hood” and have a look at how our current processes were working.
For context WAN Digital services a largely internal customer group of stakeholders from various different departments. We have a million or so unique daily users and a very complex technology stack, powered by a very mature DevOps practise to keep it all flowing.
We work in the Publishing industry. To say things can get a bit chaotic in this setting is probably underselling it. As such our current state and any future state needed to be tailored to this.
How you create your own current state might be different but you want the same outcome: How do we currently turn problems into value for our customers/stakeholders?
For our team this involved a ‘Stakeholder Mapping’ session to define our core customer types. Following this we did a ‘Work Journey Map’. This is basically the same as the ‘Customer Journey Map’ except from the point of view of a piece of work flowing through the team.
The power of mapping out your current work is you can highlight the various ‘Pain’ and ‘Gain’ points for a new piece of work from the point of view of both your stakeholders and from the team.
It’s also quite cathartic as you get to air the friction and pain points while validating any strong feelings about the process within the team.
Next the Future
That’s it for now. Next I’ll be exploring the ways we define our ‘Future State’ and then how we walked the walk and embedded Inspect and Adapt into our way of working.
