The mayonnaise measuring epiphany – better software with discovery and framing

More than likely, your initial ideas for your apps will be wrong. You’re probably not even solving the most important problems. Pivotal Lab’s “Discovery and Framing” process is built around making sure you’re working on the right apps and features to meet your original goals. In today’s episode, I cover the discovery and framing idea as, er, framed up by Matt Parker in his book Radically Collaborative Patterns for Software Makers. Also, I go over a case study of this from the food services industry.

Mentioned

CTA

Three things for more Tanzu

6 ways that pair programming makes development better

Pair programming might seem ridiculous at first, but it’s a proven, better way to program and do related work. In this episode, I go over six ways it makes things all better: quality, learning, team resilience, happiness, productivity, scaling change.

Mentioned

Chapters

00:00 – I’m eating.
00:27 – Pairing
23:43 – Podcast recommendation.
21:03 – Bye, bye!

CTA

Three things for more Tanzu

Colophon

It’s not about breaking the rules, it’s about almost breaking the rules

When you want to change, you need to find out what the new rules are, or start following the ones you’ve been neglecting. Also, stop trying to find who’s in charge: it’s probably you!

Topics

  1. It’s not about breaking the rules, it’s about almost breaking them. Remember: you wanted to change, not stay the same.
  2. “We’re the only ones” – Matt Wolken, Nnamdi, and Shafer.

Chapters

0:00 – Agenda.
00:20 – Everyone is good at saying “no.”
01:58 – Don’t break the rules, almost break the rules.
07:20 – It’s you! There’s no one else to ask.
12:31 – Your CTA.
16:42 – Bye, bye!

CTA

Three things for more Tanzu

Colophon

Less leadership, more technocracy

Getting good at leadership is always good, but make sure to mind the technocracy as well – someone’s actually gotta do the work! Also: plan for needing gadgets for your gadgets.

Topics

  1. Less leadership, more technocracy.
    • Go beyond high-level “why,” seeking out the “why of how.”:
      • >“I think some of my best conversations came through finding ways to respectfully ask those whys and trying to learn more about the process and why we were doing certain things, and really just diving into some of those uncomfortable situations,” said Liberty Mutual’s LeBlanc about her Pivotal Labs engagement. “But respectfully pushing back and sharing my perspectives, as well, ended up helping us learn so much more because we weren’t just taking it all in. We were really trying to understand the whole process.”
    • E.g., Seek out “patterns.”
    • Tanzu whitepapers, e.g., on ROBO, chargebacks, and TEI for business case modeling.
    • Haven’t read this one yet: Radically Collaborative Patterns for Software Makers.
    • And, of course: my two books on transformation!
  2. Now you have two problems
    • I don’t dislike my dog, I dislike the work and responsiblty that comes with her. I often confuse this.
    • Pets for your pets, work for your hobbies.
    • When the process becomes the product.
    • Be aware of this distinction in your thinking.

Mentioned

Chapters

00:00 – The agenda.
02:14 – Less leadership, more technocracy.
20:38 – kube.academy.
21:54 – tanzu.vmware.com/developer
23:01 – Pets for your pets.
28:34 – Geting started with your transformation strategy.
30:35 – Bye, bye!

CTA

Three things for more Tanzu

Colophon

The drunk under a lamppost app modernization anti-pattern

If you’re starting your app modernization plans with the biggest, most critical app you can find, you’re probably stumbling through the drunk under the lamppost app modernization anti-pattern. Chances are, you’ll also encounter a lot of resistance and excuses to avoid changing. Also, I discuss saying “no” more as a way to think about prioritization. Bonus topic: deep-fried bread in The Netherlands.

Chapters

00:00 – Agenda.
01:49 – The drunk under the lamppost anti-pattern.
15:09 – Start planning your app modernization journey.
18:07 – Saying “no.”
25:12 – “Too many salads.”
30:23 – Learn kubernetes, free!
32:07 – Gartner on IT strategy “turns.”
35:51 – Free developer education & bye, bye!

Topics

“With in-house development and acquisitions, FedEx would bolt on technologies resulting in an ‘accidental architecture,'”” Carter said. Through its renewal program, FedEx began to “build out the core services and microservices that represent the less complex, more flexible, faster-to-market capabilities that we have today.” From “How FedEx’s CIO led a decade of modernization.”

  1. Don’t get obsessed with the lamppost of pain: focusing on the difficult, critical things and concluding you can’t transform. Use a type of Disruption: work on lesser, cheaper things to creep up to the critical. Mobile apps, store finder, etc.
  2. Saying “no” as prioritization. All these execs saying no to things to focus on other customer and prospect engagement.
  3. Follow-up on strategy: check out Gartner’s “Winning in the Turns: A CIO Action Guide,” July, 2019. Good list of types of “turns” and advice on how to change the way you do strategy. In particular, as TD Ameritrade went over at s1p 2020, change “ROI” to “payoff.”

Mentioned

CTA

Three things for more Tanzu

Colophon

Shift right to improve corporate strategy

Corporate strategy could be improved by shifting right, moving closer to the week-to-week software cycle to get more familiar with customers and changes in the market. See more on corporate strategy in The Business Bottleneck.

Plus, I discuss bottleneck removal and thinking about policy and governance as human system, not static “laws.”

Mentioned

Chapters

0:00 – The agenda.

02:51 – kube.academy.

4:00 – Remove bottlenecks to get better at software, always.

22:06 – Amsterdam art nouveau.

24:06 – Shift right to improve corporate strategy.

35:45 – Discovery workshops.

38:07 – Policy is made by humans.

43:33 – Bye, bye!

CTA

Three things for more Tanzu

Colophon

Doing something works better than doing nothing

Summary

Doing something works better than doing nothing

When you put a new process, like agile, in place, you often realize there was very little process in the first place. Also, kubernetes at the edge, T-Mobile, and as architecture.

Mentioned:

Also

Programming notes

Chapters

00:00 – Staycation.
01:32 – Doing something works better than doing nothing
04:36 – BMC case study
09:03 – ending zombie process
11:21 – lack of management tools
13:59 – example of a management tool
15:09 – three small things on kubernetes
28:31 – Your CTA!

CTA

Three things for more Tanzu

Colophon

BT SpringOne Talk: developer first and a willingness to learn and change as needed – Notebook

BT SpringOne Talk: developer first and a willingness to learn and change as needed

A keynote given by Rajesh Premchandran, BT

BT wants to get better at how their do business, through software. Their strategies are, of course, operational excellence, but also getting software that improves the customer’s experience. This means they need to simplify how business is done, which they did by transforming the way they do software: IT underpins this corporate transformation, Rajesh says.

His approach to telling this story is to talk about how BT questioned some initial assumptions. On some of their initial plans, they pivoted (adapted) when they discovered new needs and realitis. On others, they persisted when they really needed the change. For example, at first, they thought that having a PaaS would be good enough for all development and app needs.

A pivot example: they discovered that more fine grained control was needed for some apps (esp. legacy ones), so they added in kuberntes. Here. PCF/TAS and TKG.

A persist example: security had to move from security by static IP. Because they were moving to AWS and microservices, things needed to be more dynamic. There was no way to achieve their tech-stack transformation otherwise. So, they persisted.

The third area he describes is their approach to removing ops toil from application developer’s agenda. As ever, they want apps developers to focus on…apps! And have time to explore and innovate making the apps better to deliver on customer service goals. (You see several example from Comcast on this with their new TV apps and improving customer service with ChatBots, and even in-home wifi coverage calibration, etc.) He also comments on a discovery, or validation of a predictable state, in my rewording: developers aren’t good at production ops and don’t really realize all the new tasks they’ll need to do – responisbilities they have! – in a DevOps model. So, they had pivot to training them and putting in place tech stuff to make it work better for them.

He has some fantastic framing: "instead of letting [developers] grapple with operating model choices, we adopted a more human-centric approach to educating teams."

He touches briefly on some portfolio modernization strategy. The benefits of doing, I think, were that they spent their time wisely, modernizing apps that were feasible and valuable to modernize instead of all of them. I could use more detail here, but I think the point is made – I mean it’s a five or six minute talk, so it’s fine. For a lot more, check out the ever excellent Rohit explaining this kind of portfolio app modernization analysis.

There’s another, long BT talk that I haven’t fully dissected yet.

Raw(er) notes

  • BT business – Fixed line, mobile TV, and networking.
  • Goals:
    • Lead in converged activity by simplifying business.
    • Build scalable platforms for growth.
    • Creating leaner business models.
    • IT underpins this corporate transformation.
  • "The challenges arise from our ways of working, process, account policies, security postures, and even we inventory software assests."
  • Three challenges and how they worked with them:
    1. Strategy.
      • A PaaS, PCF/TAS with Spring – time to deploy from 2 months to 2 minutes. Also, microservices.
      • But, people wanted kubernetes for finer grain control, and needs for non/fuzzy cloud-native apps. Used TKG for this.
      • Listening to devteam
    2. Security.
      • Moved from static IP to static IP, public IP addresses.
      • AWS networking needs, i.e., elastic IPs and REST endpoints.
    3. People.
      • "They also were not fully aware of the [new] shared responsibilities of managing infrastructure as code, or how their roles changed when adopting the cloud."
      • E.g., with a more DevOps approach, "their responsibilities did not end with a cf push."
      • Enterprise architects looked through portfolio to bucket apps into legacy, strategic, SaaS, PaaS, and IaaS to plan out the way of working, priorities, app modernization tasks.
      • Drives concensous on "application treatment" and how to educate teams on their roles and new skills.
      • Also, this eliminates scope overlap in our budgets and app modernization plans, allowing the PaaS team to focus on executation, [instead of work that wasn’t applicable to the various apps strategies and bucketing].

InfoWorld interview

Also, an excellent InfoWorld interview with Rajesh where he talks about several of these points, even more stridently.

Some highlights:

  • Rajesh: "What really happens is you’ve got to tease out what is containerizable"
  • "To overcome this challenge, BT has established a platform team, dedicated to helping application teams identify these containerizable elements and find the best environment in which to host them, be it in the public cloud or on a platform-as-a-service (PaaS)."
  • Rajesh: "You have to handhold them, otherwise they will take the biggest unit they can handle, put that into a Docker container and then lo and behold you’ve got the same monster on better infrastructure — that doesn’t solve your business problem."
  • "This is a constant tussle," he admits, "where people want Kubernetes by default, but I think you’ve got to be a bit more prescriptive in the beginning to developers and then as you see them maturing, have them make those independent choices."
  • "the next task is to scale it out via documentation and word of mouth buzz, both for in-house engineers and with external partners."
  • Rajesh: "If you look at how standards are democratized, you’ve got enterprise architecture that looks at the overall architecture standards and policies, then you have solution architects, who are a level down and are specific to a product, and finally we have distinguished engineers — we call them expert engineers — who are also key influencers for other developers, who look up to them."

Questions for a panel about managing managers

A moderated a panel about managing managers during digital transformation stuff (organizations getting better at software, doing the DevOps, etc.). Here’s my vision for the panel and the questions we churned over. We didn’t directly answer all of them, of course. The panel was great! The recording should be up soon (it says September 10th 2020).

The idea/point/premise of the panel

In larger organizations, there are layers of managers, in a good way: teams aggregate to a manager, that layer of manager aggregates to another, then somewhere there’s executives, and, I don’t know, the mythical shareholder. Everyone has a boss. I want to discuss what it’s like to be the boss of all those managers and help them transform into all the existing, new fangled agile and digital transformation stuff. Most of the discussion I encounter is about individual staff and the product teams (those working on software or running it), but I don’t hear much about the management structures above those teams. Also, it’d be interesting to talk a little about what exactly things like “servant leadership” mean and how one manages their career (gets promotions, more compensation, etc.) when they’ve moved from being The Boss to a servant (to be tongue in cheek about it).

Questions

  1. We’ve heard the notion of servant leadership, which sounds, you know, helpful. Can you give me an example of what that looks like though, like an actual one that happened?
  2. I was watching a webinar that Jana did recently on her white paper. In the Q&A, they asked attendees something along the lines of “do you ever think of your organization’s vision and strategy, does it ever determine what you work on and how?” As I recall, almost zero percent of people responded yes. This seems like a critical tool for managers to use if they’re setting up autonomous teams that need to make decisions on their own – they need to know the principals, the goals. How should managers be moving beyond facile vision and strategy?
  3. For years, I’ve heard about “the frozen middle,” managers who don’t want to change despite the urging and permission of executives (“above” them) and enthusem of staff (“below”). Is this cliche real? If so, what causes that frozen-ness?
  4. (Following on from that), when you’re managing managers, what are you doing in this new, agile, world? Are you a servant to the servants?
  5. There are occasionally “accidental managers” who sort of ended up there. But most of them have been pursing a career of going “up” the meatware stack. They want to grow their career, which usually means responsibilities, the glory and power that goes with it, and the rewards. So, if you’re a servant to people below you, how do you end up managing your career?
  6. As you push responsibility down to teams, what are safety nets you put in place as they figure it out?
  7. What are some the first things you delegate?

The stagnation of continuous integration and continuous delivery

I like to track CI/CD* surveys as an indication of far along organizations are doing at getting better at software: “digital transformation” where the main focus is using software to improve how you do business.

If you’re not doing CI, you’ll have a hard time getting better at doing software, or, really, doing good software at all. I

f you’re not doing CD, you won’t be able to deliver weekly so that you can get the feedback cycle in place to do hypothesis-driven development. You’ll be doing waterfall, etc.

Anyhow, here’s one chart I put together based on the State of Agile surveys:

Source: State of Agile Surveys, 3rd through 14th, VersionOne/CollabNet/digital.ai. CI/CD not tracked in 5th/2009. Over the years, definitions change, “delivery” and “deployment” are added; but, these numbers are close enough to other surveys to be useful. See more CI/CD surveys: Forrester survey (2019), DZone CD reports (2014, 2015, 2016, 2017, 2019).

The data isn’t perfect, scientific, or whatever. But it’s a good rhetorical device. Also, it matches up with other surveys on this topic (from the likes of Gartner and Forrester).

The general take is: CI has plateaued, but it’s high; CD has been slow to catch on and still has only minor growth in adoption year over year.

So, if you think you’re doing agile, there’s a good chance you’re not. Go do a walk-about and see what’s actually happening and make putting CI/CD in place a priority if you’re not doing it. Otherwise, all your other efforts to get better at software will fail and be a waste.

(* Delivery vs. deployment – I don’t know man – I don’t care…? ¯\_(ツ)_/¯ )

(Also, as noted by Jon, if you don’t have testing in place, then start there. Also: version control. Yes, it’s worth mentioning that. You’d be shit-your-pants surprised.)

Developers often know what’s slowing them down better than executives. So, like, if you’re a manager, don’t let that happen. Go check on what’s actually going on in the organization instead of just what’s going on in your status meetings. Get the more details and free books mentioned at cote.pizza.

And, for more of these tiny videos, see the full playlist. They’re, you know, fun!

Using agile software to enable an agile business

The most recent version of my “big picture” talk:

This presentation explains why getting better at software is important and can help improve your business. It presents the product model of software development, in contrast to the typical project model. It then describes three common barriers to change and how some organizations overcome them. There are three case studies of real-world, large organizations used throughout as well to illustrate the major ideas.

Also available with Korean subtitles.

Notes on the 2019 DevOps Report

Some quick notes and callouts from this year’s 2019 DevOps Report:

  • Four key metrics: lead time, deployment frequency, mean time to restore (MTTR) and change fail percentage.
    • Med, High, and Elite all have a change fail rate of 0-15%. So, expect 15% change fail as benchmark worst case to shoot for…?
  • Demographics: 30% are devs, 26% “DevOps or SRE” – [so, lots of ICs self-evaluating]. 16% “managers,” and then it goes down from there…
  • Top industries are Technology at 38% and FinServe at 12%. Retail is 9%.
  • Mostly North American (50%)and Europe (29%)
  • Org. size: 100-499 (21%), 500-1,999 (15%), and 10,000+ (26%)
  • “A key goal in digital transformation is optimizing software delivery performance: leveraging technology to deliver value to customers and stakeholders.”
  • [I’m not sure if age of company, and, thus, an indication of governance and tech debt, is tracked. With 38% being tech companies, it’d be good know how young they are. But, most FinServ companies are large and old (unless it was mostly FinServ startups!).
  • Very prescriptive this year, a maturity model to put a strategy in place, etc.
  • A lot on paying down tech debt:
    • Bounded contexts, APIs, SOA and microservices. Using and testing out of team services without having to work with that team (sort of like mocking for runtime).
    • Also: “Teams that manage code maintainability well have systems and tools that make it easy for developers to change code maintained by other teams, find examples in the codebase, reuse other people’s code, as well as add, upgrade, and migrate to new versions of dependencies without breaking their code”
  • Very little prod chaos monkey stuff: less than 10% across the board.
  • CABs still bad: those that have them are 2.6x more likely to be low performers.
    • Instead, do peer reviews and automate governance: “peer review-based approval during the development process. In addition to peer review, automation can be leveraged to detect, prevent, and correct bad changes much earlier in the delivery lifecycle. Techniques such as continuous testing, continuous integration, and comprehensive monitoring and observability provide early and automated detection, visibility, and fast feedback. In this way, errors can be corrected sooner than would be possible if waiting for a formal review.”
    • CABs should instead focus on process and practices change: ” the CAB should focus instead on helping teams with process- improvement work to increase the performance of software delivery. This can take the form of helping teams implement the capabilities that drive performance by providing guidance and resources. CABs can also weigh in on important business decisions that require a trade-off and sign-off at higher levels of the business, such as the decision between time-to- market and business risk.”
    • [I’m pretty sure that was the original point, esp. when you look at RUP and ITIL stuff: setting the process to be used. Tooling to automate governance wasn’t really available. Policing it those prescriptive processes took over as it always does. And I’m not sure there are industry standard frameworks to use there yet either. There must be lots of hand-crafting.]
    • “Survey respondents with a clear change process were 1.8 times more likely to be in elite performers.” – [as ever, garbage in, garbage out.]
    • The people who work on governance are not the ones who can actually do the coding to automate it: “only our technical practitioners have the power to build and automate the change management solutions we design, making them fast, reliable, repeatable, and auditable…. Leaders at every level should move away from a formal approval process where external boards act as gatekeepers approving changes, and instead move to a governance and capability development role. After all, only managers have the power to influence and change certain levels of organizational policy. We have seen exponential improvements in performance— throughput, stability, and availability—in just months as a result of technical practitioners and organizational leaders working together.”
  • This is a different measure of “productivity”: “Productivity is the ability to get complex, time-consuming tasks completed with minimal distractions and interruptions.”
    • It doesn’t track amount of work done, but the environment people are working in…?
  • Tools use is all across the board: DIY stuff, COTs, open source, etc. [This sort of excludes the IaaS and other runtime layers, focusing on just CI/CD and test automation]
  • “Multi-tasking” across roles and projects might be OK: “we cannot conclude that how well teams develop and deliver software affects the number of roles and projects that respondents juggle.”
  • Being able to find things and ask questions [and, presumably, getting answers!], having search, is important.
  • From my read (slide 74), the methods of transforming orgs are all across the board with Big Bang and Training Center as the only low ranked ones. Communities of practice are high, part of the Spotify model.
  • Pg. 75 tries to derive some advice nonetheless: mostly that separate education and training groups don’t work well/widely, that grassroots is used a lot, and that communities of practice are good, as well as PoCs that get cloned.
  • [This is an instance where the high level of individual contributors in the answers might have an effect. They see the positive change in their own team, but don’t have the big picture view to see if the practices scale up to 1,000’s of people. On the other hand, they might follow the “my congressperson is perfect, all the other ones are corrupt and terrible” pattern. Also, those 5,000+ people orgs struggle.]
  • [We still don’t know how to change an engine in flight.]

5 Definitions of DevOps, or, ¯_(ツ)_/¯

https://flic.kr/p/MHemN8

I’ve tracked at least three different definitions of DevOps since the days of “agile infrastructure”:

  1. Using Puppet and Chef (and then Ansible and Chef) to replace Opsware and BladeLogic.
  2. Full stack engineers to setup EC2, load-balancers, and other Morlock shit.
  3. Full stack engineers are bad, but sort of the same thing. Also, you can’t have a DevOps “group” or title. But, you know, someone should do all that automation.
  4. Putting all the people on one team, having them focus on a product, and establishing a culture of caring and learning.
  5. SRE is not DevOps.

So…actually five. Maybe some of them just being footnotes on the evolving concept. (And, if you, dear reader, feel these are wrong, then let’s compromise and make the list six.)

All of them evolved around bringing down The Wall of Confusion, allowing “developers” to deploy their software to production more frequently, weekly, if not daily. And, of course, making sure production stays up. (You’re supposed to call that “resiliency” and instead of SLAs use SLOs and some other newly named metrics that answer the question “IS MY SHIT WORKING?” Whatever you do, just don’t say “uptime,” or you’re in for it and will be relegated to running the AS/400’s.)

I used to snide that the developers seemed to have been yanked out of DevOps, sometime around 2014 and 2015. All the talks I saw were, basically, operations talks. I haven’t really checked in on DevOps conference talks recently, but at the time, I don’t think there was much application development stuff. (I’m not sure if there ever was?)

None of this means that DevOps is not a thing. Not at all. It just means that the enterprise finds its own use for things. It also means there’s still weekly write-ups of what DevOps is – you know, those ones that are always lists of ideas, things you’re getting wrong, and how to start.

Autonomous product teams

https://flic.kr/p/bJHkSX

Nowadays, I try to stick to that forth one: you want to setup autonomous teams that have all the skills and responsibility/authority/tools needed to “own” the software being specified, designed, developed, and run. This means you have to, basically, remove-by-automating all the operations stuff it takes to stand-up environments, deploy things, and do all that “day 2” stuff.

(HEY! HEY! WANT TO BUY SOME ENTERPRISE SOFTWARE?!)

Now, I think this product-centric notion of DevOps is, well, kind of an over-extension of the term “DevOps.” But since SRE has sucked out the “ops” part (but, remember, dear reader, don’t commit the embarrassing act of saying SRE is DevOps – no, no, you’d never do that, right? SO SHAMEFUL! (SRE is totally different – no overlap or similar goals shared between them at all. I mean, they have separate groups, silos! COME ON!)), slicing “DevOps” back to just “Dev,” but with a product-not-project focus isn’t too shabby.

Anyhow. I came across a good overview of this product notion of DevOps, all the way back from 2016, while re-reading Schwartz’s evergreen excellent The Art of Business Value:

Agile approaches attempt to bring together developers and the business in an atmosphere of mutual respect and joint contribution. Until now, however, the focus has been on users of the software, product visionaries, and developers. Recent developments in the Agile world—notably DevOps—have broadened this idea of respect and inclusion to encompass Operations and Security. The DevOps model, in other words, looks to break down the silos that have resulted from technical specialization over the last few decades. But the DevOps spirit goes further, looking to eliminate the conflicting incentives of organizational silos and the inhumane behaviors that can result from those conflicting incentives.

 

Perhaps we can take this idea even further still. There is no reason why the DevOps team’s responsibility needs to stop at the border of what used to be considered IT. The team is part of a broader enterprise, whose collective knowledge, skills, and judgment need to be part of the value creation process.

Look a’ that guy! Business Value just effortlessly jets out of his pores like a peripatetic thought-monarch!

This is from an executives perspective, but it drives home the point we’re always trying to get to with software: doing whatever it takes to figure out, create, and give users features that are actually useful to them. Somewhere beyond that, if you’re lucky, it’ll help out “the business.” Also, it should implement The Unspoken User Story: user would like software to actually work.

We’re getting exactly the government IT we asked for

If there’s one complaint that I hear consistently in my studies of IT in large organizations, it’s that government IT, as traditionally practiced, is fucked. Compared to the private sector, the amount of paperwork, the role of contractors, and the seeming separation between doing a good job and working software drives all sorts of angst and failure.

Mark Schwartz’s book on figuring out “business value” in IT is turning out to be pretty amazing and refreshing, especially on the topic of government IT. He’s put together one of the better “these aren’t the Droids you’re looking for” responses to ROI for IT.

You know that answer: you just want to figure out the business case, ROI, or whatever numbers driven thing, and all the DevOps-heads are like “doo, doo, doo-doo – driving through a tunnel, can’t hear you!” and then they pelt you with Goldratt and Deming books, blended in with some O’Reilly books and The Phoenix Project. “Also, you’re argument is invalid, because reasons.”

A Zen-like calm comes over them, they close their eyes and breath in, and then start repeating a mantra like some cowl-bedecked character in a Lovecraft story: “survival is not mandatory. Survival is not mandatory. Survival is not mandatory!”

Real helpful, that lot. I kid, I jest. The point of their maniacally confusing non-answers is, accurately, that your base assumptions about most everything are wrong, so before we can even approach something as precise as ROI, we need to really re-think what you’re doing. (And also, you do a lot of dumb shit, so let’s work on that.)

But you know, no one wants to hear they’re broken in the first therapy session. So you have to throw out some beguiling, mind-altering, Lemarchand’s boxes to change the state of things and make sure they come to the next appointment.

Works as Designed

Anyhow, back to Schwartz’s book. I’ll hopefully write a longer book review over at The New Stack when I’m done with it, but this one passage is an excellent representation of what motivates the book pelters and also a good unmasking of why things are the way we they are…because we asked for them to be so:

The US government is based on a system of “checks and balances”—in other words, a system of distrust. The great freedom enjoyed by the press, especially in reporting on the actions of the government, is another indication of the public’s lack of trust in the government. As a result, you find that the government places a high value on transparency. While companies can keep secrets, government is accountable to the public and must disclose its actions and decisions. There is a business need for continued demonstrations of trustworthiness, or we might as well say a business value assigned to demonstrating trustworthiness. You find that the government is always in the public eye—the press is always reporting on government actions, and the public is quick to outrage. Government agencies, therefore, place a business value on “optics”—how something appears to the observant public. In an oversight environment that is quick to assign blame, government is highly risk averse (i.e., it places high business value on things that mitigate risk).

And then summarized as:

…the compliance requirements are not an obstacle, but rather an expression of a deeper business need that the team must still address.

Which is to say: you wanted this, and so I am giving it to you.

The Agile Bureaucracy

The word “bureaucracy” is something like the word “legacy.” You only describe something as legacy software when you don’t like the software. Otherwise, you just call it your software. Similarly, as Schwartz outlines, agile (and all software processes) are insanely bureaucratic, full of rules, norms, and other “governance.” We just happen to like all those rules, so we don’t think of them as bureaucracy. As he writes:

While disavowing rules, the Agile community is actually full of them. This is understandable, because rules are a way of bringing what is considered best practices into everyday processes. What would happen if we made exceptions to our rules—for instance, if we entertained the request: “John wants to head out for a beer now, instead of fixing the problem that he just introduced into the build?” If we applied the rules capriciously or based on our feelings, they would lose some of their effectiveness, right? That is precisely what we mean by sine ira et studio in bureaucracy. Mike Cohn, for example, tells us that “improving technical practices is not optional.”15 The phrase not optional sounds like another way of saying that the rule is to be applied “without anger or bias.” Mary Poppendieck, coauthor of the canonical works on Lean software development, uses curiously similar language in her introduction to Greg Smith and Ahmed Sidky’s book on adopting Agile practices: “The technical practices that Agile brings to the table—short iterations, test-first development, continuous integration—are not optional.” I’ve already mentioned Schwaber and Sutherland’s dictum that “the Development Team isn’t allowed to act on what anyone else [other than the product owner] says.”17 Please don’t hate me for this, Mike, Mary, Ken, and Jeff, but that is the voice of the command-and-control bureaucrat. “Not optional,” “not allowed,” – I don’t know about you, but these phrases make me think of No Parking and Curb Your Dog signs.

These are the kind of thought-trains that only ever evoke “well, of course my intention wasn’t the awful!” from the other side. It’s like with the ITIL and the NRA, gun-nut people: their goal wasn’t to put in place a thought-technology that harmed people, far from it.

Gentled nestled in his wry tone and style (which you can image I love), you can feel some hidden hair pulling about the unintended consequences of Agile confidence and decrees. I mean, the dude is the CIO of a massive government agency, so he be throwing process optimism against brick walls daily and too late into the night.

Learning bureaucracies

The cure, as ever, is to not only to be smart and introspective, but to make evolution and change part of your bureaucracy:

Rules become set in stone and can’t change with circumstances. Rigidity discourages innovation. Rules themselves come to seem arbitrary and capricious. Their original purpose gets lost and the rules become goals rather than instruments. Bureaucracies can become demoralizing for their employees.

So, you know, make sure you allow for change. It’s probably good to have some rules and governance around that too.

Moving beyond the endless debate on bi-modal IT

I get all ants-in-pants about this whole bi-modal discussion because I feel like it’s a lot of energy spent talking about the wrong things.

This came up recently when I was asked about “MVP”, in a way that basically was saying “our stuff is dangerous [oil drilling], so ‘minimal’ sounds like it’d be less safe.” I tried to focus them on the “V” and figure out what “viable” was for their situation. The goal was to re-enforce that the point of all this mode 2/small batch/DevOps/PDCA/cloud native/OODA nonsense is to keep iterating to get to the right code.

Part of the continual consternation around bi-modal IT – sad/awesome mode – is misalignment around that “viability” and scoping on “enterprise” projects. This is just one seam-line around the splits of the discussion being unhelpful

Bi-strawperson

The awesome mode people are like:

You should divide the work into small chunks that you release to production as soon as possible – DevOps, Agile, MVP, CI/CD – POW! You have no idea what or how you should implement these features so you need to iteratively do it cf. projectcartoon.com

And the sad mode folks are like:

Yes, but we have to implement all this stuff all at once and can’t do it in small slices. Plus, mainframes and ITIL.

Despite often coming off as a sad mode apologist, I don’t even know what the sad mode people are thinking. There’s this process hugger syndrome that, well on both sides really, creates strawpeople. The goal of both methods is putting out software that makes users more productive, including having it actually work, and not overpaying for the whole thing.

The Enemy is finding any activity that doesn’t support those goals and eliminated it as much as possible. In this, there was some good scrabbling from the happy mode people laughing at ITSM think early on, but at this point, the sad people have gotten the message, have been reminded of their original goal, and are now trying to adapt. In fact, I think there’s a lot the “sad mode” people could bring to the table.

To play some lexical hopscotch, I don’t think there is a “mode 1.” I think there’s just people doing a less than awesome job and hiding behind a process-curtain. Sure, it may to be their choice and, thus, not their fault. “Shitty jobs are being done,” if you prefer the blamelesss-veil of passive voice.

Fix your shit

When I hear objections to fixing this situation, I try to b nice and helpful. After all, I’m usually there as part of an elaborate process to get money from these folks in exchange for helping them. When they go all Eeyore on me, I have to reframe the room’s thinking a little bit without getting too tough love-y.

“When I put these lithium batteries in this gas car, it doesn’t seem to work. So electric cars are stupid, right?

You want to walk people to asking “how do we plan out the transition from The Old Way That Worked At Some Point to The New Way That Sucks Less?” They might object with a sort of “we don’t need to change” or the even more snaggly “change is too hard” counter-point.

I’m not sure there are systems that can just be frozen in place and resist the need to change. One day, in the future, any system (even the IRS’!) will likely need to change and if you don’t already have it setup to change easily (awesome mode), you’re going to be in a world of hurt.

The fact that we discuss how hard it is to apply awesome mode to legacy IT is evidence that that moment will come sooner than you think.

(Insert, you know, “where’s my mobile app, Nowakowski?” anecdote of flat-footedness here.)

ITIL end in tears(tm)

The royal books of process, ITIL, are another frequent strawperson that frothy mouthed agents of change like to light up. Few things are more frustrating than a library of books that cost £100 each. There’s a whole lot in there, and the argument that the vendors screw it all up is certainly appetizing. Something like ITIL, though, even poorly implemented falls under the “at least it’s an ethos” category.

https://www.flickr.com/photos/cote/248696893/in/photolist-dWZEq-dWZFm-5Ujex-nYCVt

I’m no IT Skeptic or Charles T. Betz, but I did work at BMC once: as with “bi-modal,” and I really don’t want to go re-read my ITIL books (I only have the v2 version, can someone spare a few £100’s to read v3/4?), but I’m pretty sure you could “do DevOps” in a ITIL context. You’d just have to take out the time consuming implementation of it (service desks, silo’d orgs, etc.).

Most of ITIL could probably be done with the metaphoric (or literal!) post-it notes, retrospectives, and automated audit-log stuff that you’d see in DevOps. For certain, it might be a bunch of process gold-plating, but I’m pretty sure there’s no unmovable peas under all those layers of books that would upset any slumbering DevOps princes and princesses too bad.

Indeed, my recollection of ITIL is that it merely specifies that people should talk with each other and avoid doing dumb shit, while trying to improve and make sure they know the purpose/goals of and “service” that’s deployed. They just made a lot of flow charts and check lists to go with it. (And, yeah: vendors! #AmIrightohwaitglasshouse.)

Instead of increasing the volume, help spray away the shit

That gets us back to the people. The meatware is what’s rotting. Most people know they’re sad, and in their objections to happiness, you can find the handholds to start helping:

Yes, awesome mode people, that sounds wonderful, just wonderful. But, I have 5,000 applications here at REALLYSADMODECOGLOBAL, Inc. – I have resources to fix 50 of them this year. YOUR MOVE, CREEP!

Which is to say, awesome mode is awesome: now how do we get started in applying it at large orginizations that are several fathoms under the seas of sad?

The answer can’t be “all the applications,” because then we’ll just end up with 5,000 different awesome modes (OK, maybe more like 503?) – like, do we all use Jenkins, or CircleCI, or Travis? PCF, Docker, BlueMix, OpenShift, AWS, Heroku, that thing Bob in IT wrote in his spare time, etc.

Thus far, I haven’t seen a lot of commentary on planning out and staging the application of mode 2. Gartner, of course, has advice here. But it’d be great to see more from the awesome mode folks. There’s got to be something more helpful than just “AWESOME ALL THE THINGS!”

Thanks to Bridget for helping draw all this blood out while I was talking with her about the bi-modal pice she contributed to.