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?

The Agile Project Manager—No Upfront Estimates!

The diagram represents the Cone of Uncertainty—coined by Steve McConnell of Construx. I’m sure he’s not the first or only one to reference the cone, but he famously has connected it with software development. The cone indicates the futility of estimating & committing to software projects at project initiation—not matter how well conceived the estimates are. There’s typically too much uncertainty to be accurate. Instead, an iterative or incremental approach will glean more information to improve the estimates over time. This is particularly true for projects that include new technologies, new teams, or trying to create novel or innovative products.

I’ve been managing software projects for much of my career. Early on, I spent most of my time trying to estimate projects more and more effectively. I pulled together models for how to estimate. I kept track of historical estimate vs. actual data, so that I could evaluate the quality of my estimates. I even tried some modeling or arithmetic techniques to fine tune my estimates. Some of these are quite well know techniques like Function Points or Cocomo or the Personal Software Process.

All of this was focused towards estimate quality…not software product quality. I was worrying about how to represent the time to build the software to stakeholders and accountants so that we could reasonably know how much it would cost. Then we could make better decisions around whether to start it or not.

The odd thing, at least in my experience was that no matter neither how hard we tried nor how much effort we expended on estimation and planning, over 60% of our projects went awry. They failed. They were Death Marches. They were incredibly painful. And in many cases, they resulted in people losing their jobs.

I guess my point is—accurate software project estimation is incredibly hard.

The Agile Project Manager—Engaging Your Customer!

The agile methods come at software development by challenging many of our status quo practices. The first one is the engagement level of the ‘customer’.

It’s my experience that most waterfall or traditional projects allow the customer to disengage after they start the project and provide an initial version of the requirements. After some time…later…they appear at the end of the project to receive their prize. Usually they’re disappointed in the end result—finding the functionality not living up to their original vision & expectations.

This sort of “end-points” behavior leads to many project failures due to a lack of clear communications, misunderstanding, and missed expectations.