In 2001 I was laid off from Lucent Corporation in Raleigh, NC. At the time, I was a software development director leading a group of developers and testers implementing optical networking devices. It was incredibly complex work and the teams were dedicated to doing great things.
This was just post the 9/11 attack and the Telecom bubble burst so to speak. So, all of the large Telecomm companies were impacted.
I was placed on the building close-out crew, so I had a long period of time “managing” the reduction. At that time, I began to write a book. I completed it in 2002 and it was finally published in December 2004. I remember at the time being incredibly impatient as the publisher, Dorset House, took its sweet time in the editorial and printing processes.
Introduction
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.
https://www.scrumalliance.org/community/articles/2007/may/advice-on-conducting-the-scrum-of-scrums-meeting
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:
- What did he mean by “governance”?
- And why care about it within agility; wasn’t that something agile intended to minimize or eliminate with transparency?
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: Another Look at Shu-Ha-Ri
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 –
- Is a martial arts metaphor really the best way to describe the growth dynamics of agile instances?
- Are there really only three phases of agile adoption?
- Often in Shu-Ha-Ri we can revert as well or regress in our learning.
- The notion is that the Coach is a Sensei…and others aren’t?
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:
- Developer(s);
- Tester(s);
- and the Business Analyst or the Product Owner.
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:
- gone “all in” from an Agile Transformation perspective;
- done it in an abrupt Top Down fashion;
- has gone from technology to IT to now Organization-wide in their adoption;
- but most importantly is a company who shares its lessons in the community.
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.
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 ;-)
