In the interest of not being machine gunned with “hey you know nothing about Risk Management” – I want to be clear from the jump. My focus is on Scrum & Risk. And that is to say that risk in the context of a Scrum setting is anything that could stop the Scrum team from delivering a sprint goal. For those less savvy with Scrum, it goes like this. Scrum takes what the Product Owner wants done in a sprint and the team go after this sprint goal. Anything that impacts the team from getting to this sprint goal – for me – I see this as Risk in Scrum. I am not talking about the broad subject of risk management – i.e say the ideation stage of creating a product where you may want to identify new competitors say. I am talking specifically about risk which affects the Scrum teams ability to deliver a sprint goal.
The problem – we’re scaring people.
There was a Project Manager (PM) talking with a ScrumMaster (SM)- the PM asked…..”how does Scrum handle risk”…..the reply? “Well Scrum doesn’t handle risk, it’s actually silent on the subject”. Disappointingly I have heard similar answer from SM’s and other Scrum practitioners – and although their answer is technically correct – it does nothing but scare the crap out of PM’s. And I can understand why! “Hold on so we are doing Scrum now and you’re telling me this methodology or sorry framework doesn’t handle risk – at all, and I should just back off and trust the team?”. Is it any wonder why so many Project Managers turn up to stand ups with a pen and a pad and are watching cards move around the board like stalkers – where the hell is the reassurance to explain what Scrum has built into it, to handle risk?
Scrum is silent on risk you say?
Is it really? Scrum is silent on risk? Now it’s time to pull out the big guns and throw down one of my stupid drawings to show you that I mean business. Grrr.
“This story is bigger than a 3 dude, we’re looking at an 8 – just a lot more complexity with this one than we expected. What do you think Mr. PO?”. Risk mitigation in real time. Now the PO has the opportunity to say “ok push on with this bigger unexpected story, and I can manage expectation on how it impacts the other stories in the lower part of the sprint backlog” or “ok, let’s drop it out of the sprint, and go for some lower hanging fruit”.
“Bro you’ve been on that story a few days now, everything ok… we could pair on that just to see how we can move it forward?” Now that junior who’s been stuck on that story can tag up with a dev and push that story forward, a little cross knowledge loving and increasing the odds of getting that story through to ‘Done’. Sprint goal protected, risk mitigated.
“Guys how comes we keep pulling in stories into progress when I (QA) am on the back foot with a big old bottle neck? Can we stop pulling in new stories and all chip in to get the QA bottle neck down please?”. Boom. The team chip in and test one anothers work, issues get found out earlier, we have more time to respond and therefore increase the chances of getting more stories to done. Sprint goal protected, Risk mitigated.
“Yeah looks like those stories need a certain type of data in the test environment – Bobby from operations ain’t around to run that script to make that happen – is there anyone else in ops who can sort this?”. If we can get that data, we can test that story. Now we’re surfaced the problem, we can go after it. Again, that means we’re protecting the sprint goal. Risk getting mitigated.
If we can bring PM’s along to the stand up and show them how we handle risk through inspecting and adapting in our Scrum event – they will begin to feel more reassured that Scrum is definitely NOT silent on risk.
“So we went after 23 points but came out with 13. It looks like it’s going to impact the next sprint because now we have hang over…. mmmm, I better look at how that impacts our roadmap”. The Show & Tell event in Scrum lets us look at what the team have delivered and then feed our findings back into the plan. This is important because it allows the PO to get back to people like the Sales Director and help him manage customers expectations. “Sorry Larry, not sure we will have that MVP demo in time for March – it looks more like June”. That is mitigating risk. If we can’t deliver product in time for something, we need to communicate the situation so people are informed to ensure that they don’t lose customers by letting ’em down at the last second. The Scrum event of Show & Tell lets us inspect and adapt to mitigate/manage risk.
“How comes we’re not hitting our sprint goals, this is becoming an ongoing thing – what’s the problem guys” (PO talking). The retrospective is the event where we again inspect and adapt in the interest of looking at things which did not go so well. “Look Mr. PO we are seeing 60% unplanned issues and 40% project work, we’re getting way too many business requests (unplanned work) coming through to the Scrum team and that is hurting our sprint goal”. This is just one example of how Scrum has a dedicated event to help the team to surface dysfunction in the interest of doing things better. And because Scrum is based on 1-2 week (ideally) iterations, that means we get to find out if we’re doing things wrong pretty early on – and then do something about it. In the above example the PO can better safe guard or get tougher with what he lets into the sprint as unplanned work. This would allow him to increase the odds of the team meeting the sprint goal (if left undisturbed) and that again, is mitigating risk through protecting the sprint goal.
If you have the luxury….
If your team is all on site, then try to ensure you all sit together. The Physical set up of a Scrum team is very, very effective in making sure that things are not misunderstood – (in reality misunderstood less :)), there is more group intelligence which means better ideas to get to the bottom of the problem which can result in more efficient approaches to delivering a goal …as well as the team gelling part. A well gelled team who have good rapport look out for one another so when they see somebody stuck on a card, they don’t turn a blind eye to it. They want to help – helping is getting more done – getting more done is protecting the sprint goal. Protecting the sprint goal is mitigating risk. W
Show case how Scrum manages/mitigates risk to the PM or senior manager…
It’s up to us
Risk is constantly managed in Scrum – and WE as Scrum practitioners need to point out where & how we manage/mitigate risk so that we can build confidence with those people that we are trying to transform – away from micro management & into servant leadership. Most of the PM’s I’ve worked with who are trying to micromanage do so because they are scared. Scared that work is not going to get done, or that the team ain’t gonna pull their weight if the PM isn’t their watching like a hawk. We need to show PMs how our Scrum events protect the Spring goal and manage risk in a real time fashion. Invite them along to events, put out those words ‘Inspect & Adapt’ – we can showcase Empiricism through our actions to build trust, gain reassurance and ultimately reduce the stalking!
The Scrum framework contains Events, techniques, artefacts & an overall mindset which is there to manage risk.
it’s our responsibility as Scrum practitioners to express that.
So yeah Scrums silent on risk guys.
And Pavarotti was silent on singing.
Warstories of a London ScrumMaster 