Activity - Methods - Outcomes

Back in yesteryear, I recall the first time I had a management job big enough that my team was too large for line-of-sight from my desk and location.

Momentary panic: "What are they doing? How will I know if they are doing anything? What if I get asked what are they doing? How will I answer any of these questions?"

Epiphany: What I thought were important metrics now become less important; outcomes rise to the top

• Activity becomes not too important. Where and when they worked could be delegated locally
• Methods are still somewhat important because Quality (in the large sense) is buried in Methods. So, can't let methods be delegated willy nilly
• Outcomes now become the biggie: are we getting results according to expectations?

There's that word: "Expectations"

In any enterprise large enough to not have line-of-sight to everyone, there are going to be lots of 'distant' managers, executives, investors, and customers who have 'expectations'. And, they have the money! So, you don't get a free ride on making up your own expectations (if you ever did)

At the End of the Day

• I had 800 on my team
• 400 of them were in overseas locations
• 400 of them were in multiple US locations
• I had multiple offices
• It all worked out: we made money!

---

Buy them at any online book retailer!

Agile and the Enterprise

---

Applying agile methodology in your software project? Good!

Working for an organization large enough to be called an 'enterprise'? Probably that's good.

Why so?

• Access to resources is the main reason. You may have heard that agile is all about small self-directing teams -- yes, that's part of the doctrine.
   
• But how many teams are needed for your project? Dozens? Hundreds even? Where do those people, tools, training, facilities, communications, etc come from? And who pays for all that?
  
  
• Answer: the Enterprise.
  

Ah, yes, the Enterprise!

And where does that money come from? If you're not the Federal Reserve Bank, you can't print your own money; if you're not a bit coin miner, you can't create coins.

So, the money comes from customers (profit), or taxpayers (if you're a government enterprise), or donors (if you're a charity, church, etc), or owners (if privately held), or investors (if you're a publicly traded company)

Enterprise expectations

So, here's the thing: if you're doing Agile methods in an enterprise setting, the enterprise will impose expectations .... starting with: value return on resources invested.

It's the ageless problem: Other people's money! OPM comes with strings, to wit: a value return is required.

And here's another thing: the enterprise expects that you can estimate/forecast/predict what the resource requirements are that will get to something valuable (to the enterprise). In other words, it's rare indeed that there's a pot of gold you can dip into at your leisure and convenience. Enterprises don't work that way.

There are rules

What makes an enterprise an enterprise is size and scale. And there is the rub: Sad to say, but size and scale is always more than a handful of people can carry around in their head. So, many others have to lend a hand and participate in making and supporting both size and scale. Such then brings rules, procedures, accountability, etc. into the frame.

Invariably, one of the rules is going to be you have to have a viable narrative to get resources committed to your project. The standard three elements of the narrative you've heard before:

1. Scope: what is it you are going to do
2. Schedule: when can you likely produce results (no single point estimates, of course. It takes a range!)
3. Resources: how much, and when (cash flow, and resource allocations)

I can't do this!

You can't handle the narrative?

You're not enterprise-ready!

I almost forgot:

I wrote the book: "Project Management the Agile Way: Making it work in the Enterprise" 2nd Edition

---

Buy them at any online book retailer!