On the surface, this statement appears as if I’ve lost my mind. For one thing, a traditional view to Product Owners is as a Product Manager or customer/business stakeholder-facing role. And the traditional Project Manager is more so a planning and execution focused role. The two are quite far apart and seem to have little synergy.
The other factor is traditional versus agile contexts.
There are no “traditional” Product Owners. Usually a Product Manager is in essentially the role but it’s very outwardly and upwardly facing. Once the requirements are “signed off”, they’re not that interested in collaborating with the team until the end of the project.
I frequently get asked about the dynamics of building agile organizations from an organization structure point of view.
The most important point is that you don’t create a high-performance agile organization by the defined structure. Managers don’t do it; neither do VP’s or Directors.
Surely we set the stage. But the teams are the ones that create the organization. We don’t have to optimize the structure for every technical hurdle or risk. Or create a structure that perfectly balances skill-sets and experience across all functional roles.
Whew! I’m glad, because I never figured out how to do that perfectly anyway.
I was watching ESPN today. It’s spring in North Carolina, early April to be specific, and the Masters golf tournament is scheduled for later this week. So there’s a build up of golf buzz related to it.
I’m not much of a golfer, but even I pay attention to the Masters. It seems to be one of those golf tournaments that have seeped into the fabric of American life. And the Augusta, GA course is incredibly beautiful as well.
But enough of that.
There was an interview today with Bubba Watson. Bubba is a 2-time champion and he won the tournament last year – 2014. Early predictions from the pundits give him a more than reasonable chance to repeat.
As I listened to the interview, I became more and more intrigued with Bubba Watson – the person. And I started to see a correlation between some of his answers and the agile principles and mindset I’ve come to know and love.
I’ve recently been reading about and discovering some agile coaching firms who have different views towards client coaching. To be honest, I’m struggling to understand and accept some of their perspectives. So as is often my practice, I thought I’d write something about it to clarify my thoughts and position on the matter.
But first, let me share a story from a close friend of mine in Southern California:
A Coaching Story
I’m one of the best, most experienced personal trainers on the planet. If you view my website, you’ll see testimonials about my:
- Helping transform the health of large groups by running health camps;
- Assisting incredibly famous actors and actresses increase their physical performance to get ready for challenging physical roles;
- Serving as a lead fitness consultant on The Greatest Loser show;
- There’s even a rumor that the President will be inviting me to serve on the Council for Physical Fitness.
I challenged a service organization leader the other day about their agile journey. The firm provides outsourced software development teams – mostly for agile-centric clients. I was asking him about his internal application of agile practices and he asked me the question:
But Bob, when are we “done” with Agile?
From his perspective, his clients were asking for agile aware and literate teams and he was providing them. But he really hadn’t wrapped his head around agility. And he struggled with the notion of adopting agile practices internally.
I wrote an article a few months ago about sprint reviewing the “hard stuff”. It was inspired by an engineer who asked me (challenged me) about demonstrating more back-end, embedded, non-UI, infrastructural work at the end of Scrum sprints.
His general take was that it was:
- Hard to figure out how to demo the “stuff” they were delivering, and
- The components didn’t lend themselves to demonstration (in simplistic terms, they didn’t have a UI)
I pushed back a bit in the article, trying to encourage him to demo “something” and not “go silent” for too long.
If you were to have asked me about five years ago about agile team and organizational assessments, you might have gotten your head bit off. You see I used to be violently opposed to formally assessing agile teams in any way.
The roots of it probably related to aggregating team velocity. If you’re wondering, that’s not such a good thing to do either. I was worried about teams comparing themselves to each other and creating unhealthy or dysfunctional behaviors. I also worried about what THEY (leadership, managers, Project Managers, HR folks, etc.) would do with the information.
Now I’ve always felt that having maturity data around, in some form, was helpful to seasoned agile coaches. It just gets hairy when you start using it for organizational and x-team metrics. And it’s the inherent “metrics dysfunction” that is always lurking in the shadows this is a real concern.
I honestly believe that having high-energy and high-impact Sprint Reviews truly differentiates high-performance agile teams and organizations. It's very much of a "Show Me the Money" moment for the team. It allows the team to be transparent and demonstrate their results. It allows the organization to provide feedback. And it serves as a progress baseline / milestone so as to measure progress towards established goals. And finally, it should be cause for "celebration".
In many ways, agile delivery is about Earned Value, and EV is demonstrated one sprint at a time.
Does anybody remember the Cool and the Gang song Celebrate?
I sure hope so.
I want to write a short post about celebrations. For some reason I've encountered quite a few teams lately who are struggling. They're completing sprints and releases without getting much in the way done or meeting expectations.
In other words, they're ending their efforts: sad, depressed, without a sense of accomplishment. In a word, they’ve got no reason to – Celebrate.
Of course there are many reasons for it and I can't possibly explore all of them here. But the examples have made me reflect back on some of my best experiences with teams delivering “the goods”, and I wanted to share an example.
By definition, agile development is a team sport. The emphasis is on teams working and delivering together. It’s not measured by how many user stories the development team produces, but by how many completed/done stories the team can produce.
Quality is not something “owned” by the testers, but the responsibility of the entire team. In fact, you don’t try to “test in” quality, but rather “build it in”.
It places collaboration and teamwork above individuals working alone. It values pairing and swarming around work. It values limiting WIP so that team members work together.
