Matt Kortering of Universal Mind, wrote a blog post about How UX Fits Within a SAFe Environment. Lately I’ve been thinking about and writing about the scaling models, so a part of this fits well with current themes.
But I don’t want you to get stuck on the SAFe bits here. I truly want this to be a generic blog post about handling UX concerns and x-team integration within any agile method or approach.
Here’s what Matt had to say towards the end of his post:
In order to successfully engage UX within SAFe, there are a few other things to remember…
There is an old, old movie called the Marathon Man with Dustin Hoffman. In it, there is a compelling scene where the evil doer continues to ask Hoffman – “Is it safe?” while giving him a free dental checkup.
You can watch the scene here, if you’re up to it: https://www.youtube.com/watch?v=kzw1_2b-I7A
There seems to be several things that are incredibly difficult for many folks to do.
You see it in general, but it’s particularly interesting in agile contexts. Agile Teams seem to rarely want to:
- Ask for help
- Or say, I don’t know
I’m wondering why?
In my classes I often liken an aspect of the ScrumMaster role to that of a sheepdog. That an important part of their role is protecting the team. Often the direction of this protection is assumed to be outward, for example, insulating the team from external interruptions.
In a recent newsletter (sent on September 22), Mike Cohn discussed this part of the role in more detail. He spoke to two areas of protection:
- From Management Dysfunction (external), and
- From Team Complacency (internal)
The thing that struck me in Mike’s post is the internal protection perspective, ie., protecting the team from “themselves”. It made me think about areas where a ScrumMaster can really help their teams in this area.
Let’s explore some specifics…
A few years ago I quantified the 4 Quadrants of the Product Owner role as a means of communicating the depth and breadth of the role.
My intention at the time was to provide guidance to agile teams about the level of difficulty in performing within the role. I also had the intent to provide enough nuance so that Product Owners would realize that they typically would need help. That even though Scrum emphasizes a singular Product Owner per team (backlog), that more than one person might be needed to help fill all of the requisite skills and daily chores.
As part of the 4 Quadrants, I bundled the activities of a Business Analyst under the Product Owner role. It doesn’t mean that the Product Owner needs to be a Business Analyst. It just means that they have to either (1) have these skills themselves, or (2) have access to these skills within their team in order to effectively perform their job.
If there were one topic that seems to dominate all others in agile software development, I’d say its estimation.
Every team seems to struggle with it and I’m always being asked for “silver bullet” solutions that might make it easier. And of course, there are none.
I do think there is some guidance I can provide that might help you to improve your estimation understanding, confidence, and results. Or at least that’s my intent. So let’s try…
2-Phased Estimation
The first thing I’d like to make clear is the nature of most agile estimation & planning approaches. I like to think of them as a 2-phased approach versus the 1-phase, plan everything down to the single molecule in advance approaches typically used in waterfall projects.
To be fair, I’ve been fairly critical of some aspects of the Scaled Agile Framework. And even though I’m a SPC, I still don’t blindly install SAFe in many of my clients. That being said, there are a majority of my clients who are using (or planning on using) SAFe, so I get exposed to it quite often.
While I personally struggle with the agileness of much of SAFe, in the spirit of fairness, I do think there are concepts in the framework that are healthy and useful. So let me share a few of those...
I was inspired for this article by the same titled blog post from Simon Nadav Cohen that you can find here: https://labs.spotify.com/2016/05/13/to-coach-or-not-to-coach/
In the article, Simon speaks to his experience of overusing the “coaching stance” in his agile coaching interactions and showing that more nuance is often required. I wanted to explore it even more from an additional context – that of leadership coaching. But let me start out here…
The 5 Why’s
Are you aware of the 5 Why’s tool? It’s a lean technique for getting to the root cause of a problem or challenge. You keep asking why, five times in fact, in order to “peel the onion” of a problem and get to the root.
I was reading an online HBR article the other day about leadership communication. Here’s the HBR article –
https://hbr.org/2016/03/two-thirds-of-managers-are-uncomfortable-communicating-with-employees
I thought this might be a nice way to RE-explore leadership communication challenges. And a new twist might be some ideas on HOW to improve it.
I submitted a talk to the North America Scrum Gathering this year that made me a bit nervous. It was entitled – Why the World Needs More Prescriptive Agile Coaches. And I was intentional with the title.
I’ve felt for quite a long time that agile coaching can be too soft, at least in the beginning with Shu-level (beginning) agile teams. Coaches are taught to never TELL teams what to do or be forceful in any way. At best, they might “hint” at a tactic or solution, but the real learning and evolution is “up to the team”.
Consider this the default coaching stance for the majority of agile coaches.
And while I understand it, I wanted to get the audience thinking differently in this session. And yes, see what the outcome might be. Does it resonate well OR do I get some tomatoes thrown at me was the question.
I came upon a wonderful post entitled The Illusion of Managing People at Nucleus Insights. You can find it here: http://nucleusinsights.com/blog/?p=224
The focus of the article was away from “managing” and more towards “leading, inspiring, and focusing”.
There were three key points made:
- Nurture the culture, can the controls;
- Paint the big picture, skip the little instructions;
- Always ask, never tell.
They wrapped up the article with the following quote:
