Software Quality Insights

November 28, 2017  5:53 PM

Why a former veteran is now offering pro Scrum Master training

Valerie Silverthorne Profile: Valerie Silverthorne

Greg Gomel is an Agile consultant and a veteran of the Coast Guard Reserve. So when he and fellow Agile consultant Ravi Verma were brainstorming earlier this year about what they could do to help military veterans it wasn’t surprising their minds turned to Agile software development.

“We wanted to do something that would improve their employment opportunities,” Gomel explained. The result was Agile for Patriots, a not for profit organization based in the Dallas/Fort Worth area that gives veterans free intensive prep so they can sit for’s Professional Scrum Master training test.

Although the duo were inspired by coding boot camps, they decided to take a different tack. “The biggest obstacle in dealing with companies that need to hire a Scrum Master is they want multiple years of experience,” Gomel explained. “We really wanted to provide some shadowing opportunities to help veterans get more experience under their belt to overcome that obstacle.”

So they decided to offer two days of intensive Scrum Master training, followed by two one week practice sprints and ending with presentations in front of actual hiring managers. Gomel reached out to another Dallas area veteran’s opportunity group, Allies in Service, and had them actually “vet” the veterans for the Scrum Master training program. Honorably discharged veterans with some kind of IT experience in their background were approached and in the end around 55 sat through a one-day orientation. Sixteen veterans went through the professional Scrum Master training and 10 received their certificates and went on to the two one-week sprints and presentation time in front of actual hiring managers.“That really matched our initial expectations,” Gomel said. “We were really pleased.”

But he’s also realistic that those few weeks aren’t going to be enough, by themselves, to make a substantial career change. “The certificate is going to get you in the door but it’s not going to get you the job,” he said. Instead the emphasis was on looking for “shadowing” and volunteer opportunities to give veterans as much hands on experience as possible so they have a good story to tell when interviewing.

Agile for Patriots is planning to offer another session in February 2018, again in the Dallas area. “We’re going to continue to help them try to align themselves for the highest probability of success.”

October 25, 2017  2:44 PM

Is your software automation testing framework working?

Valerie Silverthorne Profile: Valerie Silverthorne

When it comes to software testing automation, it seems we all still have a long way to go. A look at a new survey from Logigear looks at the state of your software automation testing framework, and all that surrounds it, and it’s easy to understand why everyone struggles.

First, just 56% said their organization had all the skills to automate, and 34% said their teams only had some of the skills. In fact that same percentage (34%) said lack of skills was the number one reason preventing them from implementing a successful software automation testing framework. Other barriers include overall cost (32%), management doesn’t understand (31%), and the high price of tools (also 31%).

Interestingly, 38% of the survey respondents rolled out a software automation testing framework that failed, but they moved past that and now have an ongoing automation program. On the other hand 25% tried, failed, tried again and still did not succeed. An impressive 19% said they were able to initiate a software automation testing framework that worked the first time.

When asked to describe automated testing efforts, the most popular answer, at 19%, was that it eliminates repetitive tasks so time can be spent doing more interesting/important exploratory testing. And at least some companies are starting to appreciate how a software automation testing framework can improve things: 14% said it was a “very effective” part of the test process.

Logigear also asked companies how they measure whether testing works. A hefty 67% said it was by time saved, followed by number of functions automated (38%) and bugs found (34%).

To improve automation efforts going forward, 53% said they needed to make them more maintainable, while 38% wanted to add new functions or tests more quickly and 35% simply wanted to run automated tests more quickly.

How do these stats compare to your own software automation testing framework? Let us know.

September 14, 2017  1:05 PM

10 tech terms the business side needs to know

Valerie Silverthorne Profile: Valerie Silverthorne

Scott McCarty, head of technical product marketing for containers at Red Hat, thinks we all just need to get along, and for that to happen we need to understand each other better.

With that in mind he’s pulled together a list of 10 tech terms the business side needs to understand. Perhaps you’ll want to print this out and hand it to your product manager or line of business person.

  1. DevOps: “At the end of the day it’s about devs and ops getting along better and having Ops architecture embedded in the dev process so that what devs put in to production already works right,” McCarty explained. It should be flexible, but it should also be sure to reward the ops people — the maintainers — as much as the developers — the creators — are rewarded.
  2. DevSecOps: All of the above plus security people actually working with developers and operations people. “They’re not there to say no, they are there to help the business,” McCarty said.
  3. BizDevOps: “This is the next logical step, bringing the business in with dev and ops and fine-tuning it all.” The bottom line: dev and ops need to be doing what the business needs so they all need to work together. And that’s BizDevOps.
  4. Linux containers: “These are my babies,” McCarty joked. But he’s serious about the need for business to understand the benefits of containers. “Containers make it easy to move the code and provision or update it in different places and that allows the business flexibility. But what they need to understand is it does take some investment to make it happen.”
  5. Microservices: “This is completely driven by the developers,” McCarty said. “This does nothing for the ops side.” Basically microservices break an app in to pieces making it easier to divide up the work and/or bring a new hire up to speed more quickly. “This is something that enables BizDevOps.”
  6. Automation: “This is a confusing one sometimes,” McCarty admitted. “This really enables business flexibility, like BizDevOps.” But it can be a two-edged sword. “Automation doesn’t necessarily make a project happen faster and it can throw a monkey wrench in to the works.”
  7. Orchestration: “Orchestration is to help ops teams in production manage their resources efficiently,” McCarty said. “It’s not about scaling headcount but scaling the business.”
  8. CI/CD: Continuous integration/continuous delivery builds on everything else that’s going on and brings in testing to the process, McCarty said. “Most companies are doing CI, but not many are truly doing CD. CI makes it a simple decision to put something in to production vs. waiting 10 hours, and that gives the business flexibility.”
  9. Agile everything: “I see business people abuse the word ‘Agile’ all the time,” McCarty complained. “Most business people aren’t Agile. Don’t call a process Agile without understanding what it really means.” In other words, if there aren’t standups, sprints and reviews, it’s probably not Agile.
  10. Infrastructure as Code: “This is another piece of DevOps,” McCarty said. The ability for programmers to manage data center provisioning through high level coding gives an organization a big leg up. “From the business side infrastructure as code costs a bit more in time and money to do but the benefits are massive.”

August 4, 2017  2:41 PM

Is Agile stuck? Looking for answers at Agile2017

Valerie Silverthorne Profile: Valerie Silverthorne

It’s hard not to ask the “Is Agile still relevant?” question today. And it’s harder to still to hear some of the answers, ranging from straight up “No” to “too much focus on process” to “they’re their own worst enemies.”

That’s why, in advance of Agile2017 next week, I reached out to Ronica Roth, adviser and team lead for agility services excellence at CA.

Roth says the negativity is inevitable (though she’s quick to add she’s eternally optimistic). “There are too many people who’ve hung out their shingles as consultants and focused too much on the process and gotten stuck there,” she said.

Her solution is simple: get back to basics, which in this case means have a clear idea of what your goal is before you start anything. “Our message to customers lately: go in knowing what outcome you have in mind. Have a clear hypothesis why you want to be ‘Agile.’ You need to apply some lean principles to it and be clear about what aspects of Agile you need to leverage to get better results.”

And no matter what, don’t listen to the naysayers and particularly to those who hold your feet to the fire because your “process” isn’t sufficiently Agile.

“If a consultant or coach says you’re not doing Agile right I don’t want them to work for us,” Roth said flatly.”Agile is all about being learning driven and not plan driven. It’s about paying attention to what’s working and to customers.”

In fact, Roth says she sees a time when we won’t be calling anything Agile, or Lean, but rather just “modern software development.”

Her advice for what to attend at Agile2017, besides her own session of course? “You want to go to anything related to culture and leadership because that’s going to transcend whatever process you’re focused on.”

July 12, 2017  1:59 PM

Is the future of Agile actually BizDevOps?

Valerie Silverthorne Profile: Valerie Silverthorne

It’s easy to think every organization has DevOps on the corporate brain but in reality, interest in — and commitment to — Agile remains high, particularly in the enterprise space. Of course, that doesn’t necessarily make it easy to do. And it doesn’t mean DevOps isn’t having an impact.

With Agile2017 less than a month away I interviewed AgileCraft CEO Steve Elliott about the company’s 10X product release and the ongoing efforts enterprises are making to be more Agile/agile, in all senses of the word. Elliott’s seeing strong demand for a way to tie Agile efforts in to the business side, something the new 10X is designed to help with. But here’s what struck me as really interesting: in a weird way, what large enterprises are looking for sounds a lot like what some would call BizDevOps, or DevOps 2.0. It’s the idea that the business side, developers and operations are all working together with biz integrally involved in every step of the process up to and including setting the agenda.

Here’s how Elliott explains it: The key is to get developers to understand why they’re building the software they’re building (i.e., understand the business case) and to let the business side know, in a granular way, exactly what works about the software in design and production and what doesn’t. And then replicate that across 20 (or more) Agile teams. AgileCraft’s 10X is designed to tackle that problem from a technology side, but of course there’s the culture shift implied in all of this as well. “I still think the hardest thing for us to build and deliver on is the business agility piece,” he said. “The developers need to know the why, the context is important, and the business side needs to understand everything that’s going on with the technology. The companies that can bring those two sides together are the ones that are going to win.”

Elliott sees his product as a way to marry the speed of DevOps with Agile processes and ensure a communication flow from all sides. So whether it’s SAFe Agile, or BizDevOps, or digital transformation it’s another sign that enterprises are realizing things have to change.

April 30, 2017  3:01 PM

We’re not as automated as we think we are

Valerie Silverthorne Profile: Valerie Silverthorne

Test automation is not as far along as we’d thought, Agile and DevOps aren’t making software development easier and management is still everyone’s biggest problem.

Those are just some of the results of a survey done by software test company LogiGear. And this wasn’t just any survey — 10 years ago the company did exactly the same survey asking the same questions. So today’s results can be compared point by point with how testers were feeling 10 years. That is where things start to get really interesting.

“What was really surprising was that in general most things were the same,” said Michael Hackett, a senior vice president and co-founder of LogiGear. Case in point: the number one problem with testing automation today — and ten years ago — is that management doesn’t understand how it works. And then there’s the “have things gotten better since you started doing Agile?” question of ten years ago (where the answer was largely “no”) was updated to include DevOps this year and the answer was still largely “no,” Hackett said. Just 20% of testers said things were better. Automation’s not really moving forward either. A full 75% of testers said just 25% of their testing is automated; 20% said their company had no automated testing in place at all. “One in five said they had zero automation in 2017,” Hackett said. “It’s not going to be good when they finally wake up and want to make a digital transformation.”

So what’s the problem? Hackett’s explanation — that not enough attention is paid to all the important details — was interesting. “I think a lot of people have a bad definition of done,” he said. “They build up technical debt and that is turning in to a bigger problem then people thought. The concept of ‘release and fix it later’ really has a ripple effect with testers that really impacts their schedule.”

There is one bright spot though. Over the last ten years, companies have started to use ALM tools, and now everyone has access to test cases. No more using spreadsheets or word docs thanks to ALM.

But as for the rest…there is work to be done.

April 10, 2017  2:23 PM

Software salaries — it’s still very good news

Valerie Silverthorne Profile: Valerie Silverthorne

Job site just posted its top 25 highest paying jobs in America and 11 of those jobs were in high tech. And more than half of those, 7 actually, were software related.

It’s a really good time to be in development, clearly, with software salaries rising almost as fast as demand. But before you feel too good about your career choice, a quick look at the healthcare profession might bring you down to earth. Salaries for jobs in that field — physician, pharmacist, nurse practitioner, medical science liaison, pharmacy manager — are as high or higher than many software dev jobs and demand for them — based on the number of open positions at the time the report was released — is actually higher.

One lesson we can take from this is that someone with so-called hybrid skills, like a programmer who is also a nurse practitioner, can really name his or her own ticket.

But the picture is still bright even if you don’t have hybrid skills. An application development manager, the 8th highest paying job in the report, can expect a median base salary of $112,045. But a peek at the actual jobs available show potentially much, much higher paychecks, like upwards of $180,000.

What are the other winners? Enterprise architects have a median base salary of $112,560, while software engineering managers can expect $109,350 and software architects, $104,754. UX managers can look forward to a median of $98,353, while a scrum master can ask for at least $95,167.

Interestingly, despite the mad scramble for “DevOps” professionals, no job with the word DevOps in its title was in the list. Software testers and AI engineers didn’t make the list either. Data scientists did.

So, are you underpaid, overpaid, or paid just right? And did your job make it on the list? Should it have? Let me know.

February 22, 2017  2:14 PM

Another perspective on H-1B reform

Valerie Silverthorne Profile: Valerie Silverthorne

As is widely know, the White House is considering making sweeping changes to the H-1B visa program. These changes could make it far more difficult for companies to bring foreign workers over to the US, perhaps by making it too costly to do so.

There’s no question about it. The H-1B program is quite controversial. Those opposed to it say it takes American jobs away; those in favor feel it helps deal with a shortage of American workers in particular fields, including software development.

Several weeks ago I wrote a story that suggested any changes to the H-1B program really aren’t the problem but that automation might be the much bigger issue.

Now a new survey is out from Spiceworks showing that a majority are in favor of changes to the H-1B law. A total of 429 IT professionals participated and a sizeable majority — 67% — said they favor changing the H-1B law. Their reasons? The current rules favor large employers, respondents said, and the way the law is written makes it too easy for employers to abuse the rules. And there was certainly a concern that bringing relatively lower-paid workers in had the potential to get in the way of American-born employees seeking those same opportunities.

But this was most interesting…71% of those surveyed said the H-1B visa situation didn’t affect their organizations at all.

So it’s a little hard to know what to think about all of this. Will tightening the rules really help Americans? But what about the very real software developer’s shortage? As our story suggested, it can be hard for many companies to find skilled IT professionals today.

Where do you stand? Let me know.

February 13, 2017  2:24 PM

Red Hat’s 8 rules of successful Open Source

Valerie Silverthorne Profile: Valerie Silverthorne

Everyone wants to use and participate in an open source software environment but sadly not everyone knows how to do it right. This is the perspective of Matt Hicks, vice president of engineering for Red Hat’s OpenShift. So he reached out with his 8 unwritten rules of Open Source. “These are just really good life rules but they work if you apply them to open source too,” Hicks said in a recent interview.

The rules seem straightforward enough:

*Get to know the community and the people who participate in it
*Put technology before individual business goals
*Also put the community “first” first
*Beware of “pay for play” and unbalanced communities
*Be open
*Think “derivatives,” not “forks”
*Contribute wisely
*No crying

What drove him to come up with these rules is the growing popularity of Open Source, which brings with it numbers of people who really don’t know how it works. “Here’s what makes really good communities thrive and how to have more influence when you work with it all day,” he explained. “People get frustrated. They came in, submitted a patch and no one listened to them. I spent my time and built this thing and Open Source doesn’t want me. I felt the impetus to break down the rules. It’s great that we’re getting contributions in but it takes more than just writing the code and submitting it to GitHub. These are commonsense type rules but it’s surprising how many get missed.”

I asked him about my favorite of the rules — no crying. Hicks explained that the “maintainers,” who have the job of overseeing any and all proposed changes, can be “terse and dismissive” of suggestions that don’t fit or won’t work. And that new contributors simply cannot take that personally. Maintainers are busy, and newbies need to understand it can take time and patience and understanding of the bigger picture for their suggestions to be heard.

Hicks’ favorite rule? Putting the community first. “We see someone who’s done really good work but it breaks a lot of other things,” he said. “Sometimes we just can’t take them because the cost of addressing other edge cases is too high. Don’t just think of the things you want to get in. Think of the other things that might break.”

January 24, 2017  5:16 PM

Development problem solving, the LinkedIn way

Valerie Silverthorne Profile: Valerie Silverthorne

For those wondering what it’s like to be on a 3×3 mobile release schedule, look no further than LinkedIn which has 3 releases a day and a plan to never let code be older than 3 hours before committing to it. Even if your company is the size of LinkedIn, that’s a big enchilada to get through daily and for it to happen everything — including testing — has to move along like clockwork.

But even with these good intentions, the company hit a wall when it came to automating iOS UI testing. Off the shelf solutions weren’t cutting it, and without an easy fix, the idea of 3×3 was not going to be a reality.

The solution? A DIY open source solution — called “Bluepill” (think The Matrix) — has just been released for all to use, and it’s already saved LinkedIn thousands of developer hours.

Bluepill will let you run tests from multiple simulators in parallel and will pack the tests in to similar groups. A junit report is produced afterwards. Find more details about Bluepill, from LinkedIn’s blog, here.

What did it take for the LinkedIn team to pull this off? Oscar Bonilla, one of the LinkedIn engineers working on this project, explained: “The first commit happened on Aug. 12 and we had it working on the LinkedIn Continuous Integration system by Nov. 1.,” he wrote. “From there we continued to polish the project and address a few bugs. So in total it took about 10 weeks to build Bluepill and another 10 to refine it.”

And the goal was always to make this open source. Want to see for yourself? Find it on GitHub.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: