DEV Community: Michael

What to learn next?

Michael — Mon, 25 Apr 2022 19:55:14 +0000

John Locke said it well:

Reading furnishes the mind only with materials of knowledge; it is thinking that makes what we read ours.

A good point and well said, even today.

I would add, as part of learning technical topics, that putting what you read into practice makes it ours. I often think about something that I can put into practice with work and take a little piece of that, and mix in something that interests me. For either one though, its going to be something I will use and do, I have spent a lot of time in classes or learning something cool and neat at the time. And never used it again.

If you can't make a project with something, or maybe a blog post about it, then what you learn may never be truly yours. It'll be like watching that cool TV show about the environment, medical advances, or something else you watch, think is cool, then forget about a week later. To paraphrase Harley Quinn from Suicide Squad, "you have to own this". Learn it, do it, make it yours.

I tend to find that the "new and improved" or "all the cool kids are doing" subjects often don't align with what I do. Maybe its just me, and since I am typically bad about making my own personal projects I can't always jump in with everyone else and learn the new and cool stuff. Still, that's ok, its not what I do and I am comfortable with my space, so the bigger thing is I don't stress over what I can't learn. No one needs to know everything.

Tech is HUGE! There is a lot out there, and to try and learn it all would only leave one disappointed. Find the corner of your world, and own that, make it yours. From that be happy with what you do.

Rubber Duck Debugging

Michael — Thu, 24 Feb 2022 15:44:44 +0000

Talk through the problem

Have you ever been stuck on something?

As you are talking about it or telling someone about it, suddenly the solution arrives or you get that eureka moment where you stop and realize you have the answer. Even when writing out the issue you are working on to someone, then the answer comes as you are writing it out. This happens to me a lot. Sometimes just looking for something at work, or I am writing an email and send it, then I realize I needed to try some step. BOOM! The solution presents itself.

Talking it out

I used to just call it talking things out and leave it at that, then I find out that there is a name for this.

Rubber Duck Debugging!

I've never spent my time talking to inanimate objects, maybe myself but while I may be an object I am not inanimate, so while talking to myself or others I do get in this situation. At times its kind of embarrassing to send an email or message, then immediately follow it up with a never mind..

That sort of makes me feel like the old SNL character Roseanne Roseannadanna.

Never get stuck alone thinking

To me the whole point of it is to not get stuck on a problem and just sit there thinking and thinking and thinking on it. Getting stuck on something small that distracts me from moving onto the solution.

Talk it out, step away, or speak to a duck if you have one. You never know, the answer may just suddenly appear.

Anyone else have this happen to them?

Regex to the Reading History Rescue

Michael — Wed, 16 Feb 2022 22:13:13 +0000

Continuing to review my reading history

As I am getting back into doing more python I spent a little bit of time to look more specifically at the number of books I have read. While pulling out the authors, and titles, so that I can see how many books I have read and which ones. I read a lot and sometimes I forget which books of a series I read until I start a book then realize, "oh I read this already!"

My local library allows me to download my checkout history and that encompasses EVERYTHING I have checked out. DVD's and books. So I need a way to break those out from the massive text dump that the library gives me.

As the format is rather standard (as can be seen by my previous post on this: Using Python to slice up my Reading Habits) I decided at this stage I can look up solely by TITLE as its a unique field in each record. As a bonus the Author is included with the record is of a Book, a DVD does not have that on the line.

DVD:
TITLE        Ponyo / Walt Disney Pictures ; Studio Ghibli, Nippon Television 

Book:
TITLE        The boy who would live forever / Frederik Pohl.

Getting back to my Perl roots I made a Regular Expression to simply match on Title.

bookRecord = re.compile(r"(^TITLE.*)", re.MULTILINE)

Simple and easy, to match on every line that starts with TITLE. The Multiline option is there in case titles are long, and I was hoping at some point to create the right regular expression to capture the entire Record. Though its not as important at this stage.

Then after opening the text dump I search through it to match the regular expression and save those lines.

with records as r:
    for match in bookRecord.finditer(history):
        title = match.group()
        bookList.append(title)
        r.write(title)
r.close()

At the end I print out the matching lines, and then check out how many items I have taken home from my local library over the past 6+ years.

for i in bookList:
    print(i)
print("You have checked out " + str(len(bookList)) + " books or videos.")

I'll be playing around with this more to get my Python skills back and start adding more features to make it easy and fun.

Oh, I checked out 717 items.

Using Python to slice up my Reading Habits

Michael — Fri, 28 Jan 2022 10:25:13 +0000

I love my local library. As much as my wife loves to read things on her phone (I give her a pass since she can get more Chinese books online than in our library) I need to have that solid feel of words in my hands.

It's also a great way for me to step away from electronic things and just immerse myself in something or somewhere else.

Since I read a lot I tend to forget now and again on if I have read a specific book, or as I like to read a series, did I read number 3? 7? Where did I leave off as I waited for the next one to come out?

Luckily my library can give me a list of books I have read.

Sadly, that list is a bunch of metadata that I only need 2 lines out of 20+ so taking time to go through it manually is taxing.

Since I wanted to get into Python again I decided to use that to look through a record and get just the Author and Title I need.

Starting with:
Record 717 of 717 LOCATIONS TOWN & CITY AUTHOR Younger, Heather R., author. TITLE The art of caring leadership : how leading with heart uplifts teams and organizations / Heather R. Younger. EDITION First edition. PUB INFO Oakland, CA : Berrett-Koehler Publishers, Inc., [2021] DESCRIPT xvii, 193 pages : illustrations ; 23 cm. DESCRIPT text txt rdacontent.

I only needed:
AUTHOR Younger, Heather R., author. TITLE The art of caring leadership : how leading with heart uplifts teams and organizations / Heather R. Younger.

So at first I just wanted to get through the whole text dump and see what I have.

f = open("export.txt", "r")
print(f.read())
f.close()

But, yikes! I get some weird UTF error! Nothing new here, happens a lot of times when you get text from sources you can't control. So a little modification...

f = open("export.txt", encoding="utf8")
print(f.read())
f.close()

I want to save it, so I can look through just what I want, and maybe do a text search in the result for just what I want. That means ensuring the encoding when writing, as well as adding a regex to get just those two lines. Where I end up with:

import io
import re

with io.open("readingList.txt", "a", encoding="utf8") as f:
    # Get only the two fields we care about
    for line in open("export.txt", encoding="utf8").readlines():
        if re.search("^AUTHOR", line) is not None:
            author = line.replace(", author.", "")
            f.write(author)
        elif re.search("^TITLE", line) is not None:
            title = line
            f.write(title)
f.close()

There you have it, now all I have to do is work on a way to save it so I can automate the searches....or maybe have an input for just the authors I want. It was also a good way to jump back into a language I haven't used in years.

Assuming Risk

Michael — Tue, 18 Jan 2022 00:06:56 +0000

Doing just about anything, not just software, has an assumption of risk associated with it. What matters is how that risk is managed. Sometimes the risk is low and can be accepted, such as putting a plate on the edge of the counter, or it can be high, such as whether or not that barking dog pulling at its chain will bite you if you get too close.

Dealing with it requires not just an Assumption of Risk, where you accept the consequences that occur, but Risk Mitigation where you can adjust the level of Risk before accepting it. You can carry this over to pretty much anything in life, as my previous examples note, but let's look at this solely in the realm of software to keep examples on point.

Assess the Level

Before assuming ANYTHING always review first what the consequences are. Will updating that one rarely used library cause much in the way of build failures? Probably not. Will updating one of the main libraries, and not any dependencies, cause build errors? More than likely.

Take a look at not just what the consequences of the actions are, but what it will take to fix them. In worst case also have a rollback plan. When I was doing more in the way of application releases to web sites if the rollback in case of a failure was longer than the deploy that to me was a key point that something could easily go wrong and be wrong for awhile. This meant we needed to reassess the steps or the deployment. If the deployment is simple and just requires running a simple script to install, or reinstall the last version, then it's going to be easier to rollback in case there are issues.

Think to on what dependencies there are. Are there dependent services? What is the up and down flow for what is being updated, the more and longer either way is the more risk you will have versus something that is touched rarely or by one minor service that is barely used. Knowing what the cascade of changes is helps in determining the level of risk when a failure happens. The more changes the more risk there may be, take a look at the changes and then what other changes those cause. Over time this gets easier.

Manage the Level - Mitigation

I like to think of Risk as a malleable factor, it is rarely a fixed and unchangeable item. If you come across a risk like that back away very slowly, you may have encountered a Grue and it may be pretty dark where you are going.

Want you want is the smallest risk imaginable, and you do that by resolving the issues that can be generated by the most exposed service or largest dependency. Resolve each in some manner, either getting a fix made, or minimize it in some manner so that if there is an issue a service won't go down or an application doesn't return a blank page or suddenly crash. I know I am mixing a few different things here, but remember risk is everywhere (getting in your car and driving, flying, or in 2020-2021 just going outside with Covid) and you WANT to minimize your exposure to those risks. Sometimes it requires being creative, or asking "How can we fix this?"

Something like "Why is it like this?" can be useful, but you have to be careful in asking Why questions with risk as they can come across as accusatory and you don't want that. Accusatory questions can make people made, "why would you do that?!?" is different than "why is it implemented in this manner?" and the former can make you enemies; you want friends, people who will help you with solutions. Asking implementation questions can often reveal why something is like that, and why the risk was accepted, which doesn't mean that a risk acceptable a year ago is the same today. Things change. So does risk.

When you have done enough to minimize the risk you face it's time to put that in place, and we get to the next step...

Resolve the Risk

Deployments are a fact of life. They have to be, code needs to get out in the wild for the company to grow. For Customers to see that amazing new widget or that wonderful feature that will make their lives easier. To get it out there though, requires a deployment.

For a deployment, and they are all different, you need to know what you are working with. If you've gotten this far then you have already followed along with the complexity, looked at it, and understand it. Now you need to fix it to get it to deploy. What helps with a lot of automated pipelines these days is that the deployment has been happening each step along the way. From when the PR checked the code with its linters and code scans, to Dev and QA Environments where the code was installed in those environments.

So we already know what the risks are, and have mitigated the worst of them. At times hot fixes come up and they tend to skip around a bit, but in the end there is a way to either manually install something, or there is a pipeline to do this. By the time you have come to Production you know what the code is, or in a Deployment Review know each step and what is happening within each. Is there a dependency on something new in Production? Has that been done elsewhere? Do we understand the rollback and have a way to verify each step worked?

When I worked on big software releases, or site moves, I made a long checklist of steps, and to be extra detailed (yeah I can go that way) I would at times add in how long a step would take. That way we knew how long the entire process would take, and if a step took longer we knew to watch that one later, or at the time be aware something may be up. Not every release needs that kind of detail, but you DO need to have that much of a handle on every step.

Last thing you want in Production and during a deployment is a surprise. A code mismatch, a version just out of date for someone's pet service, or the password for the one server that is updated once a year by that guy who works in another department. You need to know your environment, the dependencies, and a way around them. Otherwise its rollback time, and if you don't have a plan for that and know how to get back to the original state it's going to be a long night of trying things out under pressure to bring everything up.

No one wants that kind of stress.

KNOW your environment. Understand its dependencies, and ensure your QA, or if you are lucky to have a Staging, Environments are up to date. Plus that you practice with the same steps in those environments to ensure everything is covered.

Risk is not for everyone

Some people don't like risk and they avoid it. Some don't like ice climbing, parachuting, driving on icy roads, skiing. Whatever it is, that introduces stress and a fear of failure in people. At times the idea that YOU TOUCH PRODUCTION can give a slight twinge of anxiety. Plan for it, plan for failure and recovery, and plan for planning it all.

In the world over the past two years we've ALL lived with a lot of risk. Go outside. Shop? Touch things on the shelf and see if its what you want. There is a lot of things that carry risk, and things you can do to minimize it. Risk is everywhere, and it can be managed if you just take a careful look at it and determine the best path forward.

Moving to the Advanced Class

Michael — Mon, 20 Dec 2021 02:27:25 +0000

Once you have mastered the basics, it becomes time to move to a more advanced class. This is not just the next level of learning but when you want to prove and show to your colleagues that you have "arrived". The best way to do this is through certifications.

Admittedly I was one of the worst about certifications early in my career, other than a college degree there were not that many places that offered certificates. At least ones with a reputation that you could depend on or be assured that they would be accepted by a wide range of companies and interviewers. I had encountered more than my share of people who listed certificates that seemed sketchy, or came from places that offered a cost for a class, and at the end "helped" you pass to get the certificate.

Over time my thinking has changed on that and I have become a proponent of letting my Team go out and get those certificates. With O'Reilly becoming more well known, and having structured class I did a couple of them. AWS, Python, and other places do well with having well structured classes that not only allow one to learn a lot, but really push you to pass the tests. Making the exams not only challenging, but to ensure that you have the right critical thinking skills to apply the knowledge from the classes to make it useful.

To be able to choose the right classes and certificates to do that can be useful, and also illuminate the best parts of ones career takes some thought. Going out and getting an AWS Developer Certificate is a great thing! Never using it in your work is not as good. Make the classes and choices meaningful, get the use out of the class and certificate just earned to not only highlight it on a resume but make use of it and get the money's worth out of it.

Advancing ones career is not just about checking off boxes, but to be able to put those boxes to use for you. Make the knowledge meaningful and useful, and put it into practice every day.

Recipes for Success

Michael — Sun, 19 Dec 2021 16:06:00 +0000

There are multiple recipes for success in technology, and like chefs, they vary from place to place and person to person.

What works for one person won't for another, without some adjustments.

In many ways the Local Sourcing movement changed the ways in which cuisine was made, gone in some places were the Special of the Day (to go on a tangent that was often a way for kitchen's to get rid of stock that was getting old) to be replaced with a full seasonal menu. Just like companies that use different technologies in different ways so the environment is different in what a Developer, Tester, or Manager needs to know in order to stay current or be ready to make the next step.

Recipes handed down in a family are based on a point in time where ingredients were local and available, some at only certain times of year so they were "in Fall we had" or "on this holiday my grandmother made...". When shipping became more immediate and being able to send produce and meats long distances with a relative amount of freshness so more ingredients became available in wider times. That removed the specialness of certain things that could only be found at certain times of the year, and how foodies looked only for certain ingredients at certain times because only THEN were they tasty.

Technology evolves but in companies with established practices there are certain things that remain in a specific way with people having to learn how to use that version of a software with another. Change comes slow, and with new versions of Java, Python, and dare I say Perl (though who even uses that anymore...) at times you need to adjust how software is built and when bringing build recipes current there are adjustments that need to be made. Some easy, some not. Some complex, some not. In the end its the result you want, and like a tasty dish, you want the build to be complete, whole, and workable.

Correlations are fun, and there is more to be done with cooking (a fave of mine) and software, but more on that later. I have a special dish I need to get ready for....

You never lose the basics...

Michael — Fri, 17 Dec 2021 15:03:53 +0000

As someone who works with multiple platforms and multiple languages I often have to fall back on some sort of commonality and hit the basics.

On Windows that often was Batch, early on, then Windows versions kept advancing until PowerShell became installed by default.

With Unix versions, and docker instances, that became Shell scripting. This has been the default for awhile now when I at times don't know, or have no control over, what a Team will use for their testing.

Since I only have control over the tool, not often how its used, there are requirements I can make for people to use what I, or my Team, produce. Though I often have to stop making demands so Teams can have flexibility for what they want to do, and still provide them something they can use. That's when I fall back on the basics.

Shell scripts work well in the environment I work on, a mix of Mac OSX, AWS Cloud instances, build systems using Ubuntu, and maybe in the future GCP. Finding something that works on all usually means finding a simpler and simpler solution, to make something that works everywhere (remember "write once, use everywhere"?) requires one to be creative and flexible.

It's still amazing how powerful, and how much use, you can get out of simple shell scripts even today. The basics NEVER go away, and are something you should never forget.

Work on the Soft Skills

Michael — Mon, 13 Dec 2021 00:12:18 +0000

Get Ahead

Getting ahead in a tech career means being focused on the technical skills, languages, and tools we use day to day. Being able to get the most out of them, learn the shortcuts and better ways to optimize a Build or an IDE for linting are all good ways to make your work easier. These are the things I like to call Hard Skills, they are your bread and butter, those abilities used every day to meet the tasks at hand.

There are others that allow you to not only get ahead but help you get the most of the results of those Hard Skills. Being seen as a great coder is nice, but what gets ahead is sometimes the person who is not only great technically but knows how to motive teams. Someone who can sell the story of what the Team is working on to an Executive in 30 seconds, or explain a complex task to another Team or the Product Team so they get it. These are the Soft Skills.

Time for something completely different

Working on the Soft Skills is harder, because they are not always in your day to day routine. Sometimes they aren't a natural fit, I have become adept at working with other Teams, and being able to describe why we can't do something without getting those above me mad because I worked at it. A lot of times you have opportunities available at work that you can take advantage of to work on those skills.

One of the best opportunities I had at work was the Toastmasters Club that was formed. A great opportunity to speak in front of those who in a non-judgmental way, will provide feedback for learning not only how to write speeches, but keep them into timeboxes so you get to the core of the matter. It's been a boon to my Team who in Product Demos learn to be flexible, but also they come in knowing they have to finish in 3 - 5 minutes. If your company doesn't have one, or can't make one, you can always look and see if there is a local Toastmasters Club. The one drawback is I continually see where I pause for my thoughts when I speak, but it is also far fewer times than when I started.

Be a mentor/mentee! A lot of companies have mentoring opportunities available, often with people in other departments. That not only broadens contact with people, but you can learn how other people communicate. Learning from others who have advanced is a way to see what you need to do, often times people seek out Management opportunities and don't get them, learn from one who did and follow their recommendations on knowledge and books and networking.

Read Management books! I tended to avoid some, but as I got older I started skimming more and more of them. A couple were recommendations from my mentor, and they have been great! Some things I have learned more on, and what I did naturally, was the vulnerable leader by putting my weaknesses and mistakes out before my Team so they could see I have done what they did. Learning how to tell a story and be able to draw people in by describing our work and how my Team affects others by providing tools and process improvements has given us more notice as I can make it personal when talking about it.

Become more well rounded

Mostly it comes down to communication, find your style and voice. Use it to your advantage. Most of all practice, like Hard Skills the Soft ones only get better the more you use them. Find opportunities to work on them with your Team, peers, and company when you can. Ask the VP or CEO if there are books they are reading, often people who are successful are willing to share what they know and finding out what they are doing to improve is a good way to increase your knowledge.

It's extra work, but like a multi-function tool it never hurts to keep the ones you have in good shape.

Accessibility Testing in Automation

Michael — Thu, 09 Dec 2021 21:53:00 +0000

One of the new items I have been adding into the Automation Frameworks that I support, is the Axe Tool. This does a check against page source to determine if the HTML structure is compatible with various assistive technologies. This is something that can be added into a browser, and allows manual testing, but why do things manually if you can automate?

Automate or die!

That's been the mantra, well not die, but it's got to be serious. After all why do things manually if you don't have it? So to start we create a UI test to Login and go to a home page like the following (forgoing most of the basic Class setup, which I am assuming you, dear reader, know how to do - if not, just read on and learn what you can!)

@Test(description = "Verify Login Accessibility")
public void testLoginPageAccessibility() {
    logger.info("This is to test the a11y functionality with the AXE library.");  
LoginPage loginPage = new LoginPage(driver);  
 try {  
loginPage.goToPage(new URL(getRunTimeConfig().getUrl()));  
User user = getUser(userId);  
logger.info("Checking page for " + user.getUsername());  
loginPage.login(user.getUsername(), password);  
logger.info("Getting the Accessibility Report for the Landing page.");  
getAxeReport(getCurrentMethodName());

The Current Method Name is the loginPage method, that is built upon the WebDriver GET so what is being sent to getAxeReport() is the current page being checked.

So let's look at how it generates the Report:

public void getAxeReport(String testMethodName) {

    logger.info("Checking for accessibility on page: " + driver.getCurrentUrl() + " for " + driver.getTitle());  
org.json.JSONObject responseJson = new AXE.Builder(driver, scriptUrl).setTimeout(180).analyze();  
org.json.JSONArray violations = responseJson.getJSONArray("violations");  
String pageName = driver.getTitle().trim().replaceAll(" +", "");  
String reportName = OUT\_DIR + testMethodName + "/" + pageName + ".json";  
String rawViolations = OUT\_DIR + testMethodName + "/" + "raw" + pageName + ".json";  
 try {
        if (new File(OUT\_DIR + testMethodName).mkdirs()) {
            try (Writer file = new OutputStreamWriter(new FileOutputStream(new File(reportName)),  
StandardCharsets.UTF\_8)) {
                file.write(cleanUpAxeJson(violations.toString()));  
logger.info("Successfully wrote Axe Report to File...");  
}
        } else {
            logger.error("failed to create directory");  
}
        if (violations.length() == 0) {
            Assert.assertTrue(true, "No violations found");  
} else {
            logger.debug("Found violations, generating raw report.");  
AXE.writeResults(rawViolations, responseJson);  
}
    } catch (FileNotFoundException e) {
        logger.debug("File Not Found exception: " + e);  
} catch (IOException e) {
        logger.debug("IO Exception: " + e);  
}

}

What's happening is the page URL is being obtained, and using the AXE JavaScript library against the source of the page, collect the results into a file. From the results most of what we care about are the violations, and as this is all JSON, we just need to parse the JSON tree and save the parts that tell us what is wrong with the page.

Results we save locally so the Report can be stylized, or saved and reviewed later by people who know what violations are really a problem.

Easy peasy.

I am a Technical Manager...

Michael — Tue, 07 Dec 2021 01:31:30 +0000

We all know what a Manager is, that person in charge, who tells those under them what to do. Someone who has done the time and earned the respect and adoration of their peers and has not just vision, but a way to communicate that to those that they lead. As a Leader the Manager inspires, directs, encourages, and helps their people grow.

At least they should, but we've all had Managers who did, and didn't, do all those things. I have seen a lot of this in my 25+ years in software.

Now though, or it seems like its more new to me, we have the Technical Manager.

All the People Skills plus the ability to still step in and help the Team out.

So how does it happen...

In the beginning you get a person on the Team who can code, and does it well. Design and architecture are easy, all the hard skills that come with the territory and the job. Some who has risen through the ranks, done their time, and put their stamp on code. Lead a project, helped mentor junior members, and provide insight on tasks the Team takes on.

At some point we all rise though to the top and there is that choice, or the one we used to get, Management or Architect. If you want to lead and grow and be in charge, and if you have the soft skills, you can move on up to Management and go through those fancy titles of Manager, Director, VP, CTO, and so on. Or you get Architect and the world is your playground.

Although in some places, and I used to think this was just me in startups 20+ years ago (I did mention I was old right?) where I was not only leading Teams but also doing deployments, writing automation, testing, coding, and so on. I didn't know it at the time but I was a Technical Manager. Someone expected not only to be able to lead a Team but someone who could be ON the Team.

So not as new as I would think, except now I see the title more often than I used to.

How did I get here?

For me, at the moment, its because I was asked to lead a Team, but was still on a Team that didn't go away. As there was still work to do, frameworks I worked on, and environmental components only I knew how to support, I kept that going. So while leading one, I worked on another, managed both, and that was my foray into it now.

It's not just keeping your technical skills up to par, I still sit in on reviews and design sessions and provide valuable input. There are also the soft skills that one needs, being diplomatic in communicating with other Teams, seeing the strengths and weaknesses in people and being able to provide them a plan to work on them. Being able to build a cohesive Team with skills that compliment not contrast or collide.

It always seems to be a progression, I tend to fall into this because I am not hesitant in providing feedback; especially when I see the Team or department doing bad things. I see holes where we have them in reporting, insights to code stability and quality, and look for ways to bring that information out. Look for new tools that can be useful for others, I tend to do a lot of tooling, and being able to find them and hand them off to my Team is a plus. I guide them to where I want to go, but listen to their input when they come up with good ideas.

Leading is hard, because at times you need to be able to hand things off, and as a Technical person that is tough. Watching someone work I at times think, I wouldn't do it that way, but its not me. Part of Leading, and one of the hardest for me, is being able to let go and let my Team do what they think is best. Often I am pleasantly surprised with what they come up with, and I can watch them grow as a bonus.

So what's next?

Often I think of that next step, but I have a lot of fun doing what I do now and that's satisfying for me at the moment. Some people want to keep climbing, and others find their place and are happy to keep going, until the next thing calls.

Agile isn't just for Teams, its for Executives too!

Michael — Tue, 29 Jun 2021 17:53:58 +0000

In my current company we use SAfE as a framework, and really push the Agile envelope with a lot of Teams doing work cooperatively and across Teams in our Trains (that have lots of Teams cooperating). The culture has been built up over time and we do well at cooperative planning and scheduling, keeping up the date on dependencies and workflows. All of it good on the Team side.

With a recent merger of the company one thing that was missing was integrating with the other Teams we interacted with at times. They loved the idea of our process and were happy to get on board, some did well as we integrated and Teams went out of the way to be accommodating. For others, not so much.

Teams can do Agile and when they put their minds to it, this works well.

Teams of Teams can also do it, as they cooperate and communicate. Being transparent on how dependencies are going there is a lot that can work well.

Even among different departments (Marketing, IT, etc) the process can work.

Though where it always needs that extra push is Upper Management.

Executives need to give more than lip service, it's easy to say "my whole Engineering Department is using Agile" but if they are waiting on equipment or resources from IT or HR (always need hires!) then things slow down. You can adjust but the culture needs to come from the top.

More than lip service Executives need to push the culture, speak the words and walk the walk. Be able to not just understand that the Teams working for them are doing cool stuff, but enable them from THE TOP so that Teams can continue doing cool things.

Companies make culture, and processes can enable that culture, but only so long as everyone is on board, otherwise its just Teams doing cool stuff.