I’ve heard that it’s not very often that a software dev team actually delivers a “start-from-scratch” project on time. I mean, let’s face it. There are a lot of moving pieces and if just one gets out of place, the entire project is thrown out of whack. So, how then can a dev team possibly complete something on time? Well, since my dev team just accomplished a huge project and delivered it on time, I think I may have some insight.

It’s all about having team work, being vocal, timing, early demo, realistic planning, work ethic and, of course, respect.

Let me explain.

Team Work

From the mob programming sessions and the group Skype calls, to off-the-cuff team “water cooler meetings”, there was a whole team understanding of what the project was and the plan to complete it. Daily stand-ups kept each member on board with what the other was working on (and in what environment to reduce the likelihood of code being overwritten). Problems were mentioned in stand-up and often led to an after-stand-up Skype call to discuss and address the issue. It really helps when the whole team applies KISS to stand-ups. ūüėČ

Being Vocal

My actual coding skills aren’t the strongest so, when my team included me in the mob programming sessions, I was a little on edge. I mean, what could I possibly help with?! But wow. What an enriching experience for a tester to be in a room and hear the thoughts of these code geniuses and, as a team, contribute to the project as a whole. I cannot begin to tell you how awesome this was. And one of the best things that came out of those mobbing sessions for me was that when I didn’t understand a part of the solution, my team would explain it to me. If I don’t understand something, I’m not afraid to ask for clarification. And that alone enables me to become a better tester. My testing effectiveness is only as good as my understanding of what I’m testing, right? So, speak up and speak up early. This leads me to my next point.


I feel one of the most important things to do to deliver a project on time is to be early. Ask questions early: after a project is specked out, take a few minutes to read the project plan and jot down any (no question is a stupid question) questions that come to mind. No matter how insignificant you think it may be, ask it! As the project develops and code and testing are done, continue to re-read the project plan and ask more questions. We all know that once you dive into something, certain things start to make sense and more questions arise. Code early. As soon as it was possible, these devs began putting all the background pieces in place that they knew they’d need to get this project off the ground. Test early. Using KANBAN as the method for managing all items assigned to the team has been the “oil that made the engine run smooth”. I cannot speak highly enough about how the Kanban process helped this team work together EARLY and enabled us to deliver the product on time.

Early Demo

Sometimes what looks good on paper, makes a terrible user experience during execution. That’s why it is super important to demo everything as early as possible. On my team, we were all in charge of demoing whatever was available to the PM. I enjoy taking the lead on the task to demo because I get to add my UX advice on what I thought as a user when the steps are completely non user-friendly. When caught early, this can lead to lower dev costs and a better UI experience all together!

Realistic Planning

It helps to have a team (PM included of course!) full of reasonable people who don’t want to bite off more than they can chew. You definitely need your dev team to be “small bite takers”. When the project plan is delivered to the dev team and they commit to only what they know they can accomplish, timely expectations are met. And having the whole team included in the planning process keeps everyone on the same page and keeps a certain degree of team spirit going where everyone feels they are contributing to the solution. This is another crucial piece to getting software out on time.

Work Ethic

A dev team who wants to deliver on time, will deliver on time. Make sure the drive to accomplish the end goal is there across the team. If even one person is slacking, the whole deliverable date is in question.


Everyone is creative. And in a team of intelligent minds, the last thing to do is limit creativity. There must be an enormous amount of respect within the team so that the way a solution is written is owned by the person writing the code. And if another team member has a different opinion, everyone should listen and work together on the best solution for the business. Respect one another’s work. Respect one another’s creativity. The open respect everyone had for one another on this team is another major reason why the flow of this project was continual.

So, there you have it. Seven helpful tidbits that I learned through experience about how to deliver software on time. If you use these suggestions and your project doesn’t ship on time, perhaps I forgot to document one. Either way, these suggestions are sure to help the flow of a software project to be smooth, consistent, and constant.

#ARSpotLightSpeakers Michelle Ward ‚Äď Application Security – AppRiver

Michelle Ward opens our 2017 Spot Light Speakers Series with a conversation about Application Security. Enjoy!

Michelle Ward is the founder of Cyber Safe Workforce LLC, a company that helps workplaces teach employees computer security basics. Before starting her own company, she worked 11 years in the defense space building web applications area as a software engineer. Always part of a small team, Michelle learned to wear many hats: leading projects, interfacing with stakeholders, designing, building, testing, deploying and maintaining her applications in a secure environment.

Michelle received her B.S. in Computer Science from the University of West Florida and is a Certified Information Systems Security Professional (CISSP¬ģ), a Certified Secure Software Lifecycle Professional (CSSLP), and has had training from BlackHat and DerbyCon in Web application insecurity and hacking web applications using the Open Web Application Security Project (OWASP) Top Ten. Her former career includes a small stint in¬†penetration testing.

Michelle is a passionate advocate for information security and believes that each person has an important role to play. Her volunteer efforts include Cyberthon and the Armed Forces Communications and Electronics Association (AFCEA) Summer Cyber Camps.

#ARSpotLightSpeakers Greg McMenimen – Teammates and Trust


Greg McMenimen continues our Spot Light Speaker Series with a conversation about Teammates and Trust. Enjoy!

Greg is married to his beautiful and loving wife of 19 years. They have one daughter who is committed to playing D1 volleyball at the University of Minnesota and is ranked #1 in the nation this coming year. He grew up in Minnesota playing hockey and even played in college for a short time. He left college and joined the U.S. Coast Guard in 1982, where he served for 20 years. He was a rescue swimmer the first 8 years and then joined the National Strike Force (Atlantic Strike Team).

He retired in 2002 and began his career as a Government software engineer contractor in D.C., but eventually moved to Destin because it was too cold. He started working on Mission Planning software, developing AWEs for various aircraft at Eglin Air Force Base, FL. He moved to Heidelberg, Germany with the U.S. Army European Command, where he worked as a Web Developer for a Geospatial-Intelligence group, painting the picture for down-range Special Operations teams from Joint Special Operations Command (JSOC). Greg moved back to Eglin AFB, where he was offered a position as the Chief of Software Engineering on a new Mission Planning tool and worked to re-engineer a Flight Calculation Engine for aircraft and weapon systems. He was then offered another position back in Stuttgart, Germany working for U.S. European Command, a major intelligence systems command. He provided real-time geospatial intelligence data for the Joint Operations Command that oversaw operations in all of Europe and the Middle East, while providing mentoring to the teams in Agile methodologies.

He eventually moved back to the states and left government contracting to take a position as Development Manager for the mature startup, iSirona. They developed server solutions for medical device connectivity and data collection/reporting on medical device alarm fatigue. He took a position as Director of Software Development at E-lead CRM and began implementing Agile methodologies while also building up a software development group of over 60 developers, automation engineers, and product owners. From there, he left E-lead and started work with Dave Dyell, CEO of Jellyfish Health and former CEO of iSirona.

Greg enjoys hobbies such as mountain biking and running races. He swims laps for workouts and enjoys watching his daughter play indoor and sand volleyball.

AppRiver Ignite Talks March 2017 Sudoku & You

One of the main links between theoretical computer science and discrete mathematics is the topic of Graph Theory. Graph Theory is the science of how things are connected and the combinations of connections when certain conditions are in place. A subset of graph theory is the study of Latin Squares. Latin Squares can be used as a method of procedure when it is desired to control or allow for two sources of variability, while investigating a third. With simple conditions, a Latin square can be viewed as a Sudoku puzzle.

In this talk, we review some basic graph theory concepts to solve a Sudoku puzzle in terms of a mathematical graph. We hope to demonstrate how graph theory can be visualized and applied to puzzles.



More Information on Latin Squares


I’ve recently started working on a personal project and one of my goals for this project is to learn how to use Release Management in TFS/VSTS to deploy to an Azure VM. As a QA Test Engineer, naturally, I wanted my project to have automated tests built in. I started creating my project by setting up the project repository in VSO and creating my build.¬†I wrote my first bit of code and associated unit tests. I then committed and pushed my code, expecting everything to go fine because it worked on my local dev environment. I spent several frustrating hours afterward trying to figure out why it didn’t work. I want to share the solution in hopes that I can save some hair pulling and head scratching for anyone else trying to accomplish what should be a fairly simple¬†task.

My first mistake was assuming that using Chrome to run my tests would also work in VSO. It doesn’t work, and for reasons that should have been obvious. If you look at the installed software for the VSO Hosted Agents¬†here, Chrome is not in the list. No surprise! I should have known that from the start. I knew that I could install PhantomJS locally in my project using npm¬†so I went about doing that.

I’m also using gulp¬†and karma¬†to run my unit tests so I added the necessary bits to get the tests running using PhantomJS:

And in the karma config:

I ran the tests locally and everything looked fine so I pushed again, fully expecting the build to pass this time. It failed again. Here is a log snippet from that failed attempt:

Wait…what? The tests just ran fine on my local machine. Why couldn’t it capture the browser? Honestly, I have no idea why this doesn’t just work right out of the box. I couldn’t find any good explanation but I do know how to fix it. I spent several hours and multiple failed builds trying to get it to work before I finally figured it out. The hardest part was that there really isn’t a ton of information online about how to do this so it took a lot of digging around to find the solution.

The first thing you have to do is add a PHANTOMJS_BIN variable to your build definition in VSO and point it at C:\NPM\Modules\PhantomJS.cmd. This worked to get my tests running but then I ran into another problem. The tests executed and passed just fine. However, the build agent stalled on the test build step and I eventually had to cancel the build.


Ok, now what? This doesn’t happen locally so there is no way to debug it to see what’s wrong. Thankfully, the solution is pretty simple. You just have to tell the gulp task to exit the process when it’s done. I updated the gulp task, pushed, and the build FINALLY¬†succeeded. Here’s how I changed the gulp task to get it working:

Honestly, I spent several hours searching for a solution. I even started down the path of configuring TFS Express in a VM to use as¬†an on-prem build controller. After reading the prerequisites for that task, I decided that I really didn’t have the patience to install all the software¬†needed for that. The solution is actually very simple but oddly there isn’t much information out there on how to do it. A few people mentioned that changing the agent from Hosted to Hosted VS2017 seemed to do the trick for them but the results were the same for me regardless of the agent I used. The agent always stalled on the test step.

One other thing to mention is that I noticed a lot of recent posts stating that something had changed recently with the hosted agents, and test tasks that used to work were now failing or stalling. This made me think about what would happen if, for some reason, Microsoft ever decides to remove PhantomJS from the hosted agents. I figured that my builds would start failing again so, just for kicks, I changed PHANTOMJS_BIN¬†to point to my project’s local copy of phantomjs to see what would happen. It worked!

It appears that you can use either C:\NPM\Modules\PhantomJS.cmd or $(Build.SourcesDirectory)\<MyProject>\node_modules\.bin\phantomjs.cmd. I’m inclined to use the latter since it means I depend less on software that Microsoft installs, updates, or removes from the hosted agents.

So just to recap, the solution has three steps:

  • Setup your karma config to use PhantomJS as the browser.
  • Setup your gulp task to exit the process when it’s done.
  • Add the¬†PHANTOMJS_BIN¬†build variable and point it at phantomjs.cmd.