Saturday, August 27, 2022

Working for an enterprise with Agile

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 has money!
And where does that money come from? Not you, most likely. Other people! So Other People's Money (OPM) is what is funding you.

Who are these people? If an enterprise, then there are going to be a wide variety: 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 imposes expectations
So, here's the thing: even if you're doing Agile methods in an enterprise setting, the enterprise will impose expectations up front .... starting with: expected value return on resources invested.

It's natural that Agile people resist too much "up front" definition; we're about evolution and iteration. But there has to be a compromise.
It's the ageless problem: Other people's money! OPM comes with strings, to wit: a value return is more than expected; it's required.

Enterprise expects estimates (gasp!)
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, unless you're just a researcher working on your own small project.

Enterprise brings scale
What makes an enterprise an enterprise is size and scale. 
And what makes a project "enterprise" in it's scope is size and scale.
And there is the rub: Size and scale is always more than what 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. 

Scale is not just a lot of one thing, like a large code base. Scale brings breadth, meaning a lot of different things involved and integrated, and scale brings then brings rules, procedures, accountability, etc. into the frame because a lot of people have to work somewhat anonymously ... according to rules and procedures ... to bring it together, repeatedly, within predictable limits.

The question: "Can it be done what your doing 'at scale'?" Hand-crafted, job shop, one-off are not descriptions of scale.  

Enterprise brings rules
There will be a lot of rules. 
There will be a lot of rules because there will be a lot of people involved, many you will never meet, doing jobs for the enterprise you may not even be aware of, but these jobs will nevertheless touch your project or product.

Enterprise requires a narrative
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 elements of the narrative you've heard before:
  1. Vision: What is envisioned as the benefit to the enterprise? Who are envisioned as the beneficiaries?
  2. Scope: What is it you're going to do (and what are the ancillary or consequential impacts elsewhere in the enterprise that you don't consider part of your scope?)
  3. Schedule: when can you likely produce results (no single point estimates, of course. It takes a range!)
  4. Resources: how much, and when (cash flow, and resource allocations)
I can't do this!
Narrative, estimates, rules, value commitments?
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

Like this blog? You'll like my books also! Buy them at any online book retailer!