The Agile Project Manager - You Can't Handle the Truth

Comment

The Agile Project Manager - You Can't Handle the Truth

One of my favorite movies of all time is A Few Good Men with Jack Nicholson and Tom Cruise. I can picture that highly charged confrontation at the end clearly in my mind. You know the one.

Tom Cruise says—I want the Truth…
And Jack Nicholson leans forward, with that classic look, and says—
You Can’t Handle the Truth!

What a climax to the film. I get chills every time I watch that scene.

I’ve been thinking more and more in my coaching about why leaders and managers often wait too long to ask for agile coaching help. I think it’s a general phenomenon in agile (and non-Agile) teams and organizations, but for the purposes of this article, I want to focus upward—on “them”.

 

Comment

What does a Scrum Master DO?

I've been getting this question more often lately. Usually the driver is:

We want to "go Scrum" but we don't want to pay for the "cost of admission". So for example, can one of our developers also be the Product Owner AND the Scrum Master? Those jobs can't be that difficult that one person can't do them all. Right?

Another part of the equation is smaller teams or organizations. They ask this question from a pure 'mass' point of view, in that they don't have that many folks on the team.

While there are no perfect answers, I think the key thing is to have a Scrum Master who has the time perform well in the role. To support all aspects of it as they serve their team. To honor the role of the Scrum Master as significant and important for the teams' success.

Instead of my harping on what a Scrum Master does, here are a few bloggers who've done it for me.

# of Teams

Another frequent question is - how many teams can a Scrum Master support?The 'book's seems to imply one, but that can't be right. By gosh, what do they do?

While I was at iContact, we overloaded our Scrum Masters with two teams each. A big part of that was economics, in that we struggled to hire suffecient Scrum Masters to support our teams growth. However, we always engaged the Scrum Masters in the team assignments and asked them if they could take on the additional responsibility without impacting their current team.

It was a balancing act that we partnered with them to achieve. And it became our stanard "ratio" if you will. But the ultimate deciding factor was effectiveness within the role in support of the team.

So, what does a Scrum Master do? A lot. It's a full-time and crucial job. Staff it appropriately with skilled Scrum Masters and you'll see the difference!

Thanks for listening,

Bob.

Distributed Agile Teams: The ART of the START

I’ve been sharing about agile methods for over ten years at conferences and workshops. One of the top three questions I always receive from attendees is:

Does agile work with distributed teams?

And sometimes the question is phrased another way:

That notion of co-located teams is nice in theory Bob, but in the real life, we have team members all over the world. We need to cobble together teams based on our business needs from wherever they are. Does “agile” support that level of highly distributed teams?

I often smile at the repetitiveness of the question. It indicates clearly that enterprise level software development is often distributed. It also indicates that outsourcing is still alive and well.  I’ll try to provide some answers to these questions by sharing two stories of distributed teams I have experienced.

The 4 Quadrants of Product Ownership

The 4 Quadrants of Product Ownership

If you've been listening to our Meta-casts lately, Josh and I have been talking about the role of the Product Owner quite a bit.

We've been discussing questions like:

  • Do you need one?
  • If you do, what is the 'profile' of an excellent Product Owner?
  • What do they do all day?
  • Etc.

We've then been talking about a view I have about the role and the four key areas that you need to cover in order to do the role justice. I talked about them in my Scrum Product Owner book:

  1. the role is part Product Management
  2. part Project Management
  3. part Leadership
  4. and finally, part Business Analyst

I wish I would have come up with the "quadrants" notion when I was working on the 2'nd edition of the book...but, I didn't. But now I AM talking about the nuances of the role from a quadrants perspective.

Scaled Agile Framework - Is it SAFe?

I attended an Agile Leadership Network (ALN-Raleigh/Durham) meeting a few weeks ago where Dean Leffingwell presented the Scaled Agile Framework. It was a solid meeting and quite thought provoking.

As with any "good" meeting, I went away thinking about what I heard, the contrasts against my own experience, and tried to sort through my reactions - both good & bad.

I've written some of them down in this article. I hope it comes off even handed, while still clearly communicating my concerns.

I guess the point is: Is SAFe...safe? I'm not quite sure yet ;-)

Thanks for listening,

Bob.

The Agile PM: WIPping Things Into Shape

The Agile PM: WIPping Things Into Shape

I once was leading / coaching a team that struggled mightily to work together as a team. I was the Director of R&D at an eCommerce SaaS product company. We had been leveraging Scrum for a number of years with reasonably good success and had approximately 10 Scrum teams focusing on the various aspects of our online product.

But there were a couple of teams that were really struggling, which often seems to be the nature of things. Out of ten teams, we had about three that were high performing, three that were moderately performing, and three that struggled along. Don’t get me wrong, the team members were solid people and good employees. It was just that this whole “agile collaboration thing” was hard for some of them to grasp and embrace.

The Agile PM: Agile Basic Training—What is an Acceptable Level?

The Agile PM: Agile Basic Training—What is an Acceptable Level?

The agile methods are deceptively simple and common sense oriented. In many ways, that’s one of their great strengths, but its also one of their fundamental weaknesses. I see so many teams convinced that they can “go Agile” just by reading a book or an article and then diving in and “sprinting” towards successful software delivery. The logic goes that agile is simple common sense practices, self-directed, and intuitive—so of course it will be simple to pick up and execute.

I typically categorize these teams as “bad agile” teams in that they adopt a small, superficial, and somewhat trivial set of the core agile practices and then think they’re agile. In almost every case they don’t understand the agile mindset nor how the core principles and practices complement one another to foster improvement. They’re “doing Agile”, but they’re not “being Agile”.

The Agile PM—Please Sir, May I have some help?

3 Comments

The Agile PM—Please Sir, May I have some help?

A Sad Story

A seasoned Director of Software Development was championing agile adoption at their company. It was a moderately scaled initiative, including perhaps 100 developers, testers, project managers, BA’s and the functional management surrounding them. They received some initial agile training, seemed to be energized and aligned with the methods, and were “good to go” as they started sprinting.  

Six months later things were a shambles. Managers were micro-managing the sprints and adjusting team estimates and plans. The teams were distrustful, opaque and misleading their management. There was virtually no honest and open collaboration—nor trust. They’d (re)established a very dysfunctional dance.

Funny thing is…

3 Comments

The Agile Project Manager--How do you want your Software, Good or Fast?

Picture this…

You are in a software diner one evening after a long day at work. A tired and disheveled waitress walks up to you to take your order—gum smacking as she goes over the daily specials. Nothing really sounds good to you, but you are extremely hungry and short on time. She summarizes the possibilities for you to help with your decision-making.

Honey she says—

You can get mediocre to terrible food fast or slow food that tastes good. But you can’t have both—good & fast food. 

It seems as if we’re always given certain choices in our software delivery challenges similar to what our waitress has given us. We have all heard of the “iron triangle” of Project Management—defining Scope, Cost, and Time as the three critical dimensions for a project. Usually Quality is placed within the triangle as a fourth variable—totally at the mercy of the other three.

The Agile Project Manager—The ‘Essence’ of Agile Metrics

I’ve been struggling for quite some time figuring out the “essence of” agile metrics. What are good ones versus bad ones? Are there related sets that are relevant and how many are needed? And how much change do we need to make from our traditional metrics thinking towards agile metrics?

One thing I have discovered is that metrics need to be “different” in an agile organization or culture. Traditional measures don’t seem to work within agile teams—as I’ve often seen them to cause dysfunction (more on that later).

Another thought I’ve had is whether they should represent a trailing indicator or a leading indicator? Meaning should we measure the processes (at the beginning or leading edge) or should we more so focus on the results & learning (at the end or from the trailing edge)? I’ll explore this more next.

Leading vs. Trailing Indicators

I think of measuring estimate accuracy (estimate + actual) as a leading indicator. Why is that since you measure actuals at the end of your work?