I was kind of afraid Gene Kim, the man behind the DevOps movement and a very in-demand speaker and consultant, would be offended when I asked him about the idea of BizDevOps, aka DevOps 2.0. But to my very great surprise (and honestly, relief), he agreed with the notion completely during a recent conversation.
“My first response is that I think the premise is right on,” he said, of BizDevOps. “It’s difficult to argue that the tech function needs to be even more integrated with where the business activity is happening.”
But he was also quick to add it’s very, very early days when it comes to DevOps adoption. “I kind of resist personally what’s next in my mind because we’ve barely just begun at DevOps. If we look at the actual adoption it’s just 1 or 2 percent if it’s even that high. A part of me wonders why we’d talk about what’s next when we have not finished this yet.”
Then he quoted David J. Anderson (a well-known Agile author and speaker):”It’s time to stop starting and start finishing.”
But, at least in theory, he would like to see business and tech people working a lot more closely together than they do right now. “In my terminology (I can see) whole value streams working together to solve business problems versus “the feature factory” which is the opposite. That’s consistent with where DevOps is going. But it’s not around the corner.”
Then I asked him the other burning question I’ve had since I attended Agile 2016 in July: What does DevOps mean for Agile? “One of the main reasons DevOps is succeeding is the 11 years of prep Agile has done,” he said. “If it were not for Agile DevOps would have been laughed out of the room.” He stressed that while Agile isn’t an absolute prerequisite for DevOps, it helps loads. And he doesn’t see Agile disappearing any time soon either. “Agile is such a vibrant place of innovation I don’t see them as being in competition with each other,” he said. Instead, he pointed to the fact that DevOps speakers are showing up everywhere — QCon, Agile 2016 — as a sign that the lines are blurring. And that, in his mind, is a very good thing.
Dave West, CEO of Scrum.org, is the perfect person to talk with when you feel the sky is falling.
We chatted a few weeks back, when it seemed that everything — in technology and in the world — was upside down. For starters, a just released survey from Harvey Nash showed technology was starting to “eat itself” and that large numbers of testers and even developers feared they might be automated out of a job in the next ten years.
Ok, that’s scary. But West’s take that this is more of a natural evolution than a disaster made sense to me. Skills are evolving and must continue to evolve but he couldn’t see a world without a testing function — even if it’s different than it is today — and his argument made sense. And as far as developers being automated out of work — about 47% of those surveyed by Harvey Nash said they were very worried about that — West pointed out that getting rid of the mundane developer tasks might improve productivity and creativity, something everyone should be happy about.
West remained upbeat, even when asked the “Is DevOps eating Agile/Scrum’s lunch?” question. Look in the original Agile manifesto and it will be clear that the whole idea of DevOps is already in there, and has been in there, West said. So really, no matter what you call DevOps, it’s, from his perspective, continuing the work already done by the Agile believers over the last ten years or so. And don’t count Scrum out, by any means, as it’s created the cultural and process foundation to speed up the entire software development process.
In other words, while things may feel a bit topsy turvy, Scrum, Agile, testers and developers aren’t really going away, at least in Dave West’s view of the world. I’m relaxing a little…what about you?
At a time when it seems containers and microservices are practically all everyone is talking about, it’s easy to think they’re a no-brainer solution to so many development problems.
But it’s not that straightforward. I spoke recently with Scott McCarty, an evangelist and “container thought leader” at Red Hat. Why wouldn’t someone user containers? It turns out there are several compelling reasons. First, not every application is container friendly.”Will my app fit in the container and will it be able to run in a relatively sane way?” McCarty asked. Containers require the operating system to be broken in to two pieces so an application needs to be able to handle that, McCarty explained. “Some apps just weren’t meant to be divided in to two.” And then there are what McCarty calls the “edge cases” which are apps so large and so dependent on, say, an Oracle database, that it’s just not feasible to port them in to containers in any kind of reasonable time frame.
Security is another significant concern, according to McCarty. If you can break the app down in a way that makes it work in a container, you’ll get a good bit of built-in security, he said. But if the application can’t be divided correctly, “you don’t get those security codes for free and the value proposition is really limited.”
Can we do this?
But there’s a third, surprising, reason companies are not choosing to containerize and that’s because they’re afraid they don’t have the internal talent to pull it off, McCarty said. “Do I have the talent to do this? Are we we even prepared to do this? Will I be able to hire the talent to do this?” And apparently this is a real concern, not just because of the worldwide shortage of software developers but because an explosion of tools and choices has meant each developer has the opportunity to do it his or her own way. But will they do it correctly, with so many choices? “That’s really the issue,” McCarty said. “Will they choose the right tools and will they be experienced enough to make it happen?”
What’s holding you back from moving to containers?
Is the role of enterprise architect changing? It is, and it isn’t. I know that’s helpful.
I recently spoke with Todd Loeppke, CTO Architect for Sungard Availability Services, a company that is focused on IT production and recovery. He has a broad view of the changing EA role, thanks to his many client contacts.
From his vantage point, the EA job itself really hasn’t changed but the pieces and responsibilities are changing and in some cases, quite dramatically. “If the IT architect’s job is to architect IT solutions that solve business problems under a big umbrella then the role hasn’t changed,” Loeppke said. “But the parts, the experience, well there’s pretty much everything under the umbrella that’s changed.”
Loeppke thinks the tricky part is that the tools an EA is using have changed completely and, of course, there are more tools. Take automation. The idea that so much should be automated in this DevOps world we live in is a huge change and something today’s EA is now forced to deal with. “Automated testing is taking over, and it has to,” he said. An EA today “is going to have a greater sense of automation than ever before. This was not a sexy practice in the past but it is key to success in the future.”
But it doesn’t stop there. Loeppke says an EA today has to have a broad view of open source tools — and if you’ll pardon the pun, be open to using them. It’s ok to reach out to GitHub and see how other people have solved a problem.
And while the nature of an enterprise architect job is to be a generalist, don’t plan on being too general, or you’ll run the risk of missing something, whether it’s security or cloud or networking related.
Sounds a bit like same job title but a different playbook. How do you think the EA role is changing? Let me know.
Andreas Grabner, a “performance enthusiast” who works at Dynatrace, understands that metrics are the holy grail of a DevOps team, but he also knows that the information can be hard to come by on the Devs side of things.
Speaking recently at DevOps Days Boston, he was clear about what developers need: “Metrics should be put in your face.”
In fact, he recommends installing ceiling devices that can go from green to red so that devs can know instantly if a build isn’t working. Spinning red overhead lights can go a long way to drawing attention to a problem, right?
And it’s really not about automation, he said, because automating bad code does nothing for anyone. The key is to find a way to bring data to the developers right where they are.
“A developer is 100 percent responsible for the code,” Grabner said. “The code runs on the framework and if you don’t use the analytics tools you have you won’t know what’s going on. With a metrics-driven pipeline you get better code from the beginning.”
You don’t have tools, you say?
Ah, but there are so many out there, many available free of charge for personal use.
Want to tell us what your favorite go-to analytics option is?
“To some extent Agile isn’t a solved problem.”
“Agile needs to freaking grow up.”
“We need to stop calling it Agile.”
“We need to stop saying Agile makes it easy to go faster.”
“Agile got us going, but DevOps is going to take us where we need to go.”
In the conference rooms of Agile 2016 in Atlanta this week, there was a lot of talk about where Agile is today. At 15 years old, Agile, in one sense, is maturing and going strong. But, even among those who preach it – and make a living from it – there is just a hint of unease when it comes to talking about the future.
Nowhere was this more obvious than during the session “2020: The State of Agile.” Moderated by Jann Thomas, a former developer, with three Agile coaches as panelists, this session was standing room only. But, as the session progressed, more and more people started to leave. The issue, it seemed to me, and in discussion with other attendees later, is that people were looking for a practical road map for Agile’s next few years. They wanted to hear, head on, how to tackle the challenges. What about new technology, what about DevOps, what about the fact that this can be so very difficult to get right?
The panelists were clearly frustrated with Agile’s “reputation” but their solutions were cosmetic in nature. One suggested renaming Agile (“it’s tainted” by folks who couldn’t do it correctly), and then offered up a slew of catch phrases including “bring your femininity to the job,” allow “openness and compassion,” “speak from your heart” and “bring your vulnerability.” At this point, a lot of people were leaving and one man raised his hand and suggested his CEO simply wouldn’t want to hear those things. There was nervous laughter at that.
And when the group did try to get a bit more nitty gritty, they suggested de-coupling Agile from speed of delivery. Don’t focus on faster delivery, focus on “sooner.” Is there really a difference here? They insisted there was but I am still not so certain.
This session left me – and many others I spoke with – feeling deflated. Change is coming, whether it’s via the Internet of Things, the cloud, or DevOps. Change doesn’t have to mean the end of Agile – after all, it’s quite diluted already given the thousands of different ways companies “do” Agile. But in order to roll with change, and grow from it, you need to acknowledge it. Agile needs practical and unfortunately for much of this week what we heard were platitudes.
It is, indeed, time for Agile to grow up and take the next steps.
Developers, slow applications are really not your fault. And I’ve got two examples to prove it.
And in the category of other things you have no control over, it’s time to bring Brexit in to the mix. While obviously the UK leaving the EU isn’t going to slow down your app, it may slow down your app development, particularly if your developers are in the UK. The European Union allows free and easy travel between member nations, something that’s translated in to a lot of software devs from other countries working in London. That’s helped ease the shortage and boost productivity, but things are changing, according to Robert Grimsey, director at UK-based recruitment firm Harvey Nash. “Brexit has created uncertainty,” he said. “We’ve seen it in the lead up to the Referendum, during which demand for recruitment across all roles – including software development – was down. Now that Brexit has been confirmed, our expectation is that demand for permanent software development roles will continue to stay suppressed until there is a greater visibility.”
What could that mean? More contract jobs, for starters, as companies may not want to hire permanent workers. And it could mean a hiccup — or ten — when it comes to development projects.
The bottom line: lots of things are out of your control, like third party apps and political upheaval. At a time when many are tired of hearing how the dev process is at fault, perhaps today we can all take a little (admittedly cold) comfort in the fact that we can actually identify a few of the culprits. It won’t last forever, but for right now we can try to enjoy it.
Yes, you read that title right. Too bad I can’t take credit for the pairing.
Way back when I worked for a daily newspaper, the most exciting times of all were of course the election cycles. The late nights, the meet and greets, the feeling of change in the air…good times.
It’s another election cycle — by all accounts a one of a kind cycle at that — and of course change *is* in the air still. And not just when it comes to politics.
I interviewed Will Evans, chief design officer at Praxis Flow, a couple of weeks ago. He’s a lean development expert, sure, but he’s also a fun and lively interview. I would guess his seminar at QCon was probably a lot of fun.
But Evans will always have a special place in my heart because in this election cycle he brought together two wildly different “things” and actually made it work: DevOps and Bernie Sanders.
“Imagine Bernie Sanders is the DevOps of politics — fresh ideas but fundamentally not changing the entire system,” Evans said. “People are idealists in DevOps. If Bernie can change the platform and shift the Democratic party to the left 5% that is progress but not perfection and DevOps is the same.”
Evans thinks the biggest problem in the software development arena is that people aren’t engaged and are at risk of spending their time doing things that don’t matter. DevOps, he believes, can be that change, but like Sanders, you have to see it as a process and and not an end result. “The promise of DevOps is to move things, to make things 1% better next year. That is meaningful. This is a long haul with a lot of hard work and we’re not going to have change overnight.”
Can we afford to be patient? I hope so.
Tell me how you think software development and the election cycle are linked.
Ask any application-development decision maker or programmer: Emerging technologies force enterprise IT shops to rethink not just which new products and services to adopt, but even more importantly, the very nature of how they do their jobs. For this reason, TechTarget’s expanding its coverage of IT operations with the launch of SearchITOperations.com.
Our long-standing attention to core application development technologies and buying trends — such as development ALM and app containers — will not change on the TechTarget coding and software websites you already read. Rather, through the new SearchITOperations, we recognize the cultural and technological transformation underway as IT operations and application development more closely collaborate to heighten their enterprise’s ability to respond to market changes.
Reaching into 2020
Looking out over the next three to five years, strategic IT shops will need to move beyond cost savings or avoidance, marked by silos and limited collaboration, to thrive. All aim for stable, flexible operations that are custom fitted to the internal landscape, corporate goals and business outcomes of that enterprise.
For many IT shops, the desire to facilitate shorter application release cycles without outages and mistakes means reordering staff, acquiring new skills and choosing from a plethora of new tools to automate tasks.
The new site is dedicated to the news, features, how-to tips and other expert content that enables IT operations pros to manage new application architectures and faster release cycles, along with the feedback loop concept promoted by DevOps. From our view, these tie-ins with AppDev teams are clear and important.
As always, our readers can expect unbiased technical information as they evaluate new tools, learn additional skills and plan tomorrow’s IT operations.
We hope you’ll check out the new resources on SearchITOperations, and we thank you for your continued loyalty to, and readership of, SearchSoftwareQuality.
My recent story on the surprise skills gap — writing, public speaking, communication and most decidedly NOT tech skills — has me wondering what it means to be the ideal employee. The term “well-rounded” is tossed around a lot, but what does that actually mean when it comes to testers and developers?
I went to a liberal arts college and, all right, I’ll admit I was an ENGLISH major. And not just any old English major — my degree was in 19th C. British Lit. Yes, my father was certain I would never get a job with a degree like that. He was a CPA and his view was that college was supposed to give you a marketable skill or, even better, skills. I obviously didn’t get “skills” but I did get an education.
That was a million years ago, and the world has changed a lot. Just this week I had a reader mention that he literally keeps his developers “locked in a back room” because they are completely unable to communicate — orally, or by email — with his customers in any way that resembles “standard” English. I did not get the sense that his developers were non-native English speakers; instead, it seems they just don’t have good communication skills, which of course brings me back to that skills gap.
So, to be an ideal developer or tester today you need: tech skills, of course, but you need to be able to write, speak and interact comfortably with customers and business people, and then you may need that “extra” something that involves, say, industry experience. That’s what Matt Sigelman, CEO of research firm Burning Glass, refers to as “hybrid skills.”
In other words, I think the bar is getting set at a higher and higher level as time goes on. There are straightforward solutions if you have an employee with insufficient tech skills; but Dale Carnegie and The Toastmasters aren’t exactly household names any more (click on the links if you actually don’t know who/what they are!) and as far as hybrid skills go, a hybrid developer creates him/herself by choice. The employer doesn’t have much to say about that.
So how do we solve that skills gap? Does your company have a strategy that’s worked? Or do you think the problem is overblown? I’d like to hear what you think.