All Posts in App Dev Methodologies

|In: App Dev Methodologies|Last Updated:

Good golly Miss Molly!

It was bad enough when folks thought the original version of DevOps … developers and IT operations actively collaborating … was an original idea.

Note to everyone in the IT universe: No matter what your context is, and who you’re working with, you didn’t invent collaboration. If you want credit for originality, COME UP WITH SOMETHING ORIGINAL!!!!

Whew. I feel much better now.

As for DevOps, at least it evolved into something reasonably original, or at least something reasonably radical. To save you a few minutes of googling, in its current form DevOps has contributed two important ideas. The first is that development teams should always leave software in a deployable state (the deployment part of “Continuous Integration / Continuous Deployment”).

The second, which is foundational for all things Digital, is that automation should be the default no matter what process or practice you’re dealing with.

So far so good, and even better after Dave Kaiser and I layered in the idea of BusOps – that the collaboration between IT Operations and business Operations is just as important as the various collaborations IT developers should involve themselves in. (Want a more complete account? Oh, c’mon, you can afford the book).

But then someone had to invent DevSecOps. And CloudOps. MLOps (machine learning).

And now (drumroll) … we have FinOps, as in, someone should pay attention to a company’s cloud expenditures – “Cloud financial management,” in the words of the FinOps Foundation, which suggests that somewhere along the line, “Ops” and “Cloud” became synonyms.

Rather than just fixing the name (CloudFinOps … CFO for short?) let’s start right in on critiquing the FinOps Foundation’s six guiding principles:

Principle #1: Teams need to collaborate.

KJR perspective: Well, yes, that is the definition of “team.” Not original. Not even interestingly unoriginal.

Principle #2: Business value of cloud drives decisions.

KJR perspective: The business value of something should drive business decisions? No kiddin’ Dick Tracy. Not original. Not even interestingly unoriginal.

Principle #3: Everyone takes ownership of their cloud usage.

KJR perspective: Sure, if you want to slow everything down to a crawl. Certainly, those who consume cloud resources of any kind shouldn’t treat them as free. Yes, everyone should have enough awareness of what cloud stuff costs that they don’t make stupid decisions. But implementing technology-enabled business change is hard enough without worrying about nickel-and-dime stuff every step of the way.

Principle#4: FinOps reports should be accessible and timely.

KJR perspective: Oh, now we need FinOps reports? That means we need an organization to produce them. Which means … see Principle 3, because who’s going to own the costs of staffing and provisioning this new, emerging bureaucracy?

Principle #5: A centralized team drives FinOps.

KJR perspective: Of course it does. See the KJR perspective for Principle #4. Plus, this ignores a fundamental rule of organizational dynamics, which is that while centralization drives efficiency through economies of scale, decentralization is what drives innovation, by removing organizational barriers to rapid decision-making.

Principle #6: Take advantage of the variable cost model of cloud.

KJR perspective: We covered this ground a long time ago (“A cloud spiral of death,” 11/5/2012). If your demand for computing resources varies enough that being able to add … and shed … capacity as the situation calls for it matters, the public cloud’s variable cost model is downright nifty.

But costs that are variable are only useful when demand is variable. If your demand is steady and predictable, owning your own computing infrastructure might be more economical because you don’t have to tack on enough margin to turn a profit.

Bob’s last word: No question – organizations that operate without discipline usually end up collapsing under their own bloat. That doesn’t mean discipline should be imposed by layer upon layer of outside reviewers. All that does is create a high-friction enterprise.

An effectively disciplined organization, in contrast, comes from establishing a culture of discipline.

Culture is an organization’s lane markers. Governance and controls are, or at least should be, its guard rails.

If you hit them, something is already very wrong.

Bob’s sales pitch: Want practical guidance on how to engineer your organization’s culture? You need (here’s a surprise!) a book. Namely, you need Leading IT: (Still) the Toughest Job in the World. Chapter 8 will provide you with all the techniques you need to make this happen.

Comments

|In: App Dev Methodologies|Last Updated:

“Oh, yes, we’re using Agile,” my client’s two CIOs told me.

Their company had engaged us to assess their IT practices and effectiveness. In addition to consolidating to one CIO (some recommendations are easier to figure out than others), we also suggested IT should adopt Agile to guide its application development efforts.

Their situation wasn’t all that unusual. The road to Agile is replete with forks. Travelers should avoid many of their tines.

My client had chosen a popular one: They were practicing, not Agile, but Haphazard.

Sadly, they ignored our 12-step App Dev recovery program, the two CIOs presided over a calamity, and eventually our former client became a division of a larger non-client.

Astonishingly, many business and IT leaders continue to misunderstand Agile, and that doesn’t include last week’s advice about applying Agile thinking to business situations beyond application development.

In some cases the misunderstanding is willful, grounded in distrust that Agile’s open-endedness can lead to useful results. If you share this distrust, a question: When you were a child, did you draw up a roadmap for your growth and development that would take you, step-by-step, through your adolescence, remaining education, personal relationships, offspring, careers, retirement, and demise?

Please say you didn’t. I recall, as a teaching assistant back in my grad school days, talking with pre-meds who discovered, in their junior or senior years, that they really didn’t want to become physicians after all, but felt trapped by the choices they’d already made.

I’ll leave the analogy there for you to explore at your leisure. Here, for your edification and amusement, are some other popular misunderstandings about Agile:

Agile isn’t Haphazard: With Haphazard development, project team members wake up each day figuring out what they should do to move the project forward. Or, nearly as bad, the project manager wakes up trying to figure this out.

No matter which Agile variant you use, the project is built around an organized list of Things the Application Should Do — the Backlog.

Agile testing isn’t haphazard, either: With Agile, testing is, if anything, more planned than with its Waterfall alternatives: Those developing a chunk of functionality — usually a module defined by a User Story — know when testing should start on their work. Even more important, every module includes, as part of its definition, a test plan.

Agile isn’t Scrum: It’s a squares and rectangles thing. All Scrum is Agile; not all Agile is Scrum.

Scrum, the most structured Agile variant, is especially popular among IT folk who, schooled in Waterfall development, need control structures and formal governance. There are, however, worthy alternatives.

Especially, look at Kanban, in which developers, when they finish work on a User Story, pull another one out of the Backlog, usually the one (1) with the highest priority, that (2) they’re qualified to develop. Alternatively the project manager assign a user story to them instead.

And, especially if you’re implementing a COTS (commercial, off-the-shelf) software solution, look at “Conference Room Pilot” (CRP) or its close relative, Acceptance Test Driven Development (ATDD). They’re good choices for packages because they’re built around business users trying to do their jobs using the package.

They try, that is, with a real-life business transaction. Wherever they can’t process it, they tell the developers locked in the conference room with them what the problem is. The developers, using the configuration tools built into the package, adjust it to make the problem go away. Rinse and repeat.

Agile disrespects architecture: Developers don’t just write code however they’d like. They develop in conformance to a well-defined application architecture — probably a microservices architecture, but what matters is that, early in the project, the team will, collaborating with the Architecture Review Board or equivalent, establish architectural standards to guide development.

Nor do developers modify the data model whenever they face a situation that calls for it. The project’s consulting data designer reviews the suggested data model change with the developer and, once the two have converged on the best approach, makes the changes happen.

An equivalent set of conversations happens with any other developer solutions that don’t fit the company’s architectural standards.

What doesn’t happen is the developer filling out a form to request a change, for review by some governance committee or other.

That would be decidedly not-agile, as a key Agile principle is that individuals and interactions are more important than processes and tools.

It would also, by the way, ignore a key KJR principle: That there is no process so glacial that it can’t be slowed even further by involving a committee.

Comments