Bob's Blog
Bob is a prolific blogger who simply enjoys sharing his experiences with colleagues in the Agile Community. Topics revolve around Scrum, XP, Kanban, Project Management, Business Analysis, Testing, Leadership and General Musings.
Check back often as we've always got something to say...
Viewing entries in
References
This description is intended to help guide the implementations of Scrum of Scrums at Program / Train level.
It all started with this picture that Mike Cohn published over 10 years ago. In the explanation he briefly mentioned a hierarchical structure where multiple Scrum teams get together when they are working on related projects.
Often I explain it as: team-based Scrum behaviors, just up a level.
I remember my first reading of the DAD – Disciplined Agile Framework by Scott Ambler that one of the areas he emphasized was governance.
When I first read it I had two immediate reactions:
So to say that I was less than impressed by DAD initially was an understatement. But over time, I’ve kept up with Scott’s writings and explanations of his intentions with DAD. And to be honest, I like what I’m hearing of late.
Alan Cyment gave a wonderful Pecha Kucha talk at the recent Scrum Gathering in Phoenix.
In it, he challenged the use of the Shu-Ha-Ri model or metaphor on a couple of levels –
Alan’s metaphor was much simpler, yet I believe richer.
I think it was George Dinwiddie that first coined the term “3 Amigos” in agile development around 2009. The analogy was akin to the movie from the mid 90’s by the same name. The Amigos in the agile sense are functional roles:
It could literally mean more than three as well. The point was, balanced collaboration in agile teams across these roles. George was alluding to these roles from an Acceptance Test Driven Development (ATDD) perspective. He wanted these three constituencies to be heavily collaborative (conversations) around the Acceptance Tests or Acceptance Criteria for each user story.
I often cite Salesforce in my classes as a company that has:
I always lament the fact that too few companies that are adopting agile approaches actually share their lessons publicly. Oh sure, some small bit leak out, but most unfortunately decide to keep their practices to themselves.
I was talking to an experienced Scrum Master and Agile Coach the other day about agile in general and the topic of stand-ups came up. It seems he’d had an “experience” at one of our local agile group meetings where Daily Standup dynamics were being discussed.
Here’s a link to the session. It’s a meeting from our local Raleigh, NC AgileRTP group. The topic was entitled: Do You Stand Up? I missed the meeting, but he recounted the general discussion and flow for me.
The group consensus was that: 'Chickens' (interested bystanders, stakeholders, leadership folks, etc.) should not talk during the Daily Scrum. The rational mostly surrounded that at it would interrupt the teams conversations and flow.
The Scrum Master disagreed with this view and he (jokingly) said that—when he brought up his perspective, the crowd summarily dismissed him as being wrong.
If you've attended any of my Product Owner workshops or many of my conference sessions, you know that I often talk about release planning as a necessary extension to any of the agile methods.
From my perspective, it almost doesn't matter if you're leveraging Extreme Programming, Scrum, Kanban or some variation. If you're working in a context where you need to communicate release plans and make some sort of commitment to your stakeholders, then I think you should be doing release planning.
Now clearly it's not a silver bullet and you sure can't guarantee fixed scope & date commitments. But it certainly helps your teams align what's feasible within your release train tempo.
Here's a link to an article / 3-part post series I've written on the topic. I hope you find some value in it.
Stay agile my friends,
Bob.
I can’t recall when I first came upon the Pareto Principle. I think it might have been when I was studying for my Six Sigma Green Belt. But I’m unsure. I know I was operating as a QA Director at the time, because most of my example uses for it surrounded testing and defects. Nonetheless, it’s probably been over 15 years.
That being said, I don’t think I hear people “considering” Pareto enough in their day-to-day activity, so I thought I’d bring it up and remind everyone of the Pareto Principle or 80:20 Rule and it’s implications for software engineering in general and agile teams in particular.
This blog post, which will actually become a “series” as I keep adding references to it, was inspired by Bhavani Rao. Bhavani is a Product Manager who lives in my neighborhood. He’s trying to make the transition to Agile Product Management (Ownership) and is finding it difficult to gain entry without real world experience. So a catch-22 if you will.
The focus of this blog is to provide a lean (but robust) set of references for “would be” Scrum Product Owners and “newbie” Product Owners to help them in their journey. But don’t expect it to be easy or to only read a few blog posts. The role of Product Owner is deep, broad, challenging and downright intimidating. That is – if you want to be GREAT.
I hope you do and I hope this helps…
Bhavani – this one’s for you ;-)
