At the end of 2016, Josh and I had published 106 posts on our Meta-Cast agile podcast that we started in January of 2010. So, we've been LIVE for 7 years now.
In that time, we've published on virtually any agile topic you can think of. I thought I'd share our Top 3 podcasts from 2016.
In this segment, we actually review one of our early podcasts that focused on agile testing and then shared some of our updated thoughts and reactions to the topic. It turns out that much remained the same, but there were difference (shifts) in our thinking.
In this segment, we explored the "movement" that is implying that agile is DEAD. We look at the forces behind it, the why if you will. But we also weigh-in on our own thoughts. And if it's not dead, where IS agile now and where is it GOING.
What's interesting in this segment is that Josh shares his direct experience at The Dude implementing agile methods. His focus has been on Scrum, Spotify, and a bit of SAFe. He characterizes it as The Agile Donut. Listen in.
The Meta-Cast is into it's 8'th year. We hope you continue to follow us and that we continue to provide value to the community.
Stay agile our friends!
If you know me at all, you know that I speak at approximately 15-20 events per year. Sometimes, at small local conferences. Other times, at larger national conferences. And still at other times, I'm lucky enough to be invited to international events.
The reason I do it is much less about marketing or exposure, and much more about sharing my ideas in what I view as the "agile community". Even though I'm a strong introvert, I enjoy getting out there and meeting people. Getting the opportunity to share, debate, network, argue, and simply chat about all things agile (and occasionally other topics ;-)
In my agile coaching and training journey, I spend a lot of time discussing a wide variety of topics. But there are themes that form a “Top 10” of topics that everyone seems to be interested in.
One of those items is how to handle bugs. Questions like:
- Do you estimate bugs (planning poker - points)?
- Are bugs equivalent to stories?
- When do you “file a bug” while sprinting?
- Do you count bugs as part of your velocity?
- Can you deliver a story in a sprint with bugs still open?
come to the surface in my classes and at conferences with amazing frequency. I often smile inside in amazement at the level of interest focused towards “bugs”. But that being said, it is an important subject for agile teams and I thought I’d discuss my views towards handling bugs in the above contexts.
In my previous post I shared about experience I’ve had in “connecting” UX activity into Scrum development teams. I tried to explain a pattern of collaborative partnering over either embedded UX in the teams or independent UX outside of the teams.
I thought I’d share another story that illustrates an aspect of these ideas.
Not that long ago I was working with a client helping them understand and practice release-level planning across their Scrum teams. Some of the challenges they were having revolved around incorporating UX design work and cross-team dependencies in their projects.
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…
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...