Buy My Product: How to Get Your Audience Interested

Ribbon cuttingIf you’re a highly technical and introverted person like me, then marketing falls well into the area of things you don’t want anything to do with. But whether we like it or not we all gotta do it at some point; whether it be selling ourselves as employees to an employer or, in the context of this blog entry, marketing your product to the consumer.

If your development team has been using an Agile-like development process, then this is where we start to see some big benefits from following the doctrine of Agile. Just to reiterate what I’ve said in past entries, Agile projects can adapt to change and one of these types of changes can be consumer input (Fogelström, 2010).

Now it may sound a little weird to give, or even in some cases sell, the consumer a product that isn’t done yet. But this has become a popular trend among game developers as of late, although they often refer to it as beta-testing or early-access. The great thing about these early-access opportunities for consumers is that they can give the developers input as the product is being developed based on a tangible product rather than what incremental information your marketing team is putting out onto social networks. That’s not to say that, just because the consumer can’t use the product means you shouldn’t value their input, on the contrary their input should still be extremely valued and considered by your development team (Fogelström, 2010), because if they’re giving you input then odds are they’ve already developed some degree of interest in your product and could be a potential customer when you do reach a release point.

Steve Jobs

A true master of marketing

Another important factor to look into is that, although your marketing software, your audience may contain people of varying technical background. It is for this reason that you have to shoot for a healthy medium when unveiling of presenting your product so that you don’t get to bogged down in technical details such that the low technical audience doesn’t know what you’re talking about, but also so that the highly technical audience can still sate their thirst for knowledge about how your product works. Even as a die-hard Android fan and lifelong Windows user, I must give credit to Steve Jobs for perfecting this art, he managed to capture the appeal of both non-technical and highly-technical users with the products he marketed because he knew how to appeal to both groups, and of course the truckload of charisma he carried with him during a big Apple unveiling didn’t hurt.

So there you have it, use Agile’s ability for change to incorporate consumer input into your product and everyone will benefit from it.



Brice, A. (2013, March 19). The brutal truth about marketing your software product. Retrieved December 1, 2014,



Fogelström, N. D., Gorschek, T., Svahnberg, M., & Olsson, P. (2010). The impact of agile principles on market-driven

software product development. Journal Of Software Maintenance & Evolution: Research & Practice, 22(1), 53-


Ribbon Cutting [Image]. Retrieved November 23, 2014, from:

Steve Jobs [Image]. Retrieved November 23, 2014, from:


Handing off the Project

baton-handoffYou can’t hold the client’s hand forever, eventually they need to be setup with the tools and the knowledge to be self-sufficient. Handing off a project to the client is no small task, it essentially requires slowly disseminating all the latest information (status, issues, backlogs, etc.) to the client. Such procedures often gets referred to as “mind-melding” in my workplace.

The most important thing is to make sure that this hand-off is as thorough as can be. Everything from email records, meeting notes, and any materials that are associated with the project’s development need to be assimilated (Curnow, 2003). This is where good file-keeping habits really pay-off. When handing off a software project, it is also particularly important to hand over the pre-compiled files to the client. Obviously that includes the source-code, but it also entails graphics, videos, pictures, or any other kinds of media that are incorporated into the finished product, so that the client can easily hand-off the project to another developer in the future (Curnow, 2003). The goal is to make sure that the client does not have to be dependent upon you after this hand-off is 100% complete, unless otherwise agreed upon.

Communication is a big part of these hand-offs, both parties need to understand what the other’s role will be during the transition period and after the transition period. Will be involved with any kind of maintenance or future upgrades to the software? Will the contractor provide any kind of training for the client? These are the kinds of questions that should be brought up when the transition is being planned. It is recommended to make these hand-off periods take place over a period of time, a rushed hand-off is just asking for trouble down the line. Taking the transition slowly will ensure that everyone is on the same page when it comes to an end.

The big risk at the end of the hand-off, especially for software, is the possibility of something going wrong afterwards. If a major bug is found within a software product after it has been handed off, the client needs to have all the materials they need to either get their in-house developers on the job or hire another contractor to the deal with it. Either of those options require that the client has things like source code, documentation, a list of known issues, meeting notes, or anything else that could give the new developer insight into the inner-workings of the software so that they can pick up where the previous developer left off.


Agile Lifecycle [Image]. Retrieved November 16, 2014, from:

Baton Handoff [Image]. Retrieved November 16, 2014, from:


Curnow, B. (2003). Handing over and moving on. The International Guide to Management Consultancy: The

Evolution, Practice and Structure of Management Consultancy Worldwide, 1, 227.


Ferris, B. (2012, June 7). How to Hand Off a Project Successfully. Retrieved November 17, 2014, from



Employers: What are they looking for?

job-interviewAnyone who has sat down to tailor a resume has asked themselves a question along the lines of “what will create the best impression?” or “what will optimize my chances of getting this job?” Ultimately the employer will weight skills above all else.

Let’s split up skills into two categories, technical skills and soft skills. Technical skills tend to be specific and easily quantifiable; application development, speaking a second language, or the ability to operate heavy machinery can all be considered technical skills. Soft skills on the other hand are a little more broad and are skills that you can find in most jobs; communication, leadership, or teamwork are some common soft skills.

The top desired technical skills vary depending on what industry you’re seeking entrance into, a company seeking an engineer might be interested in their experience with computer-aided design modeling programs whereas a company seeking a programmer could be interested in the programmer’s experience with PHP, MySQL, etc. These are generally the kind of skills that people learn in school and/or specialize in.

Programming skills, technical support, networking, project management, and database administration top the charts in terms of employer demand for these skills. This list is not all that surprising either, most modern businesses rely heavily upon software to an extremely heavy degree, so much so that having technical experts in-house is essential. Within my own job as a software tester, although I consider myself to very skilled with the usage of computers, if one of those technical skills on the top five list weren’t present within our organization, it would be very hard to get our jobs done. Most companies are coming to this same realization that they need technically skilled people with sometimes very specific areas of expertise in order to keep their operations running smoothly (Zwieg, 2006).
Soft skills on the other hand, tend to be far more universal across most positions that you’ll come across. The top soft skills that employers want are communication, teamwork skills, flexibility, problem solving skills, and leadership kills. The reason why these skills are so desired is because, no matter how many technical skills you posses, not having these skills can serious hinder your ability to function within the workplace.

Communication is by far the most desired of all of these soft skills (Zwieg, 2006), many jobs require you to work with others and, in the process of doing so, be capable of clearly articulating what’s on you’re mind in a way that minimizes miscommunication. Even within a highly technical job, such as my own job as a software tester, these is a need to be able to communicate very clearly in order to keep things running smoothly. If I were report a software bug and not clearly describe the steps to replicate it, this could mean having to take an extra half-hour in a meeting in order to explain each individual bug to the developer. I could easily have saved that time by just writing it out clearly to begin with.

Both soft skills and technical skills play important roles within the workplace, lacking one or the other will seriously hinder your chances of an employer choosing you for the job over someone that already has these skills developed.


Employment Stats [Image]. Retrieved November 09, 2014, from:

Interview Sign [Image]. Retrieved November 09, 2014, from:


Mason, B. (2014, June 1). Top 10 Soft Skills in Demand. Retrieved November 10, 2014.


Zwieg, P., Kaiser, K., Beath, C., Bullen, C., Gallagher, K. P., Goles, T., … & Wion, R. (2006). The information technology

workforce: Trends and implications 2005-2008. MIS Quarterly Executive, 5(2), 47-54.



The Evolution of Computer Game Development: Modding

PongAll my prior blog posts have been about Agile development and selling yourself to employers. So this entries’ subject may come as a bit of a surprise. Today I am going to enlighten my readers on a different form of development that occurs within the computer game software industry.

This form of development is known within the gaming community as “modding.” For those of you who are unfamiliar with the term, modding typically refers to user-created content (ranging anywhere from physics engine tweaks to visual texture redesigns) that is made post-release for commercial computer games.

That term “user-created content” can be found in a variety of software, Google Chrome for example gives community developers the ability to develop extensions for the browser that provide additional functionality. The idea with computer game modding is very similar, the developers ideally design the game with a modding API so that community developers, sometimes small teams but often individuals, can write a “mod” that tweaks some aspect of the game with the intent of making it better, fixing something the  developers won’t fix, or just for the sake of humor. If we look at the modding community behind the vast multitude of mods for the computer game “The Elder Scrolls: Skyrim,”  we can see that there are mods made for improving the combat system, fixing software bugs that the official development team never got around to fixing, and mods that add things that are just down right silly; such as replacing the appearance dragons commonly found throughout the game with children’s cartoon characters that fly around breathing fire onto the player.

Silliness aside, encouraging an active modding community has some major benefits for development studios that choose to employ it. For starters, the game will grow long past its development life span. This varies depending on how extensive the modding api is, if the modding api only allows access to visual textures then the modding community won’t have much to work with and it will fizzle out very quickly. However by granting the community nearly full-access to the game’s capabilities, the modding community can create new missions for the player, new stories and plot-lines, new dialogue, gameplay, sounds, graphics, scripted events, and a plethora of other possibilities that were probably excluded from the original game due to development budget constraints.

Thruster Comparison

(Figure A) Left: Standard thruster options in Space Engineers. Right: User-made option alongside standard options. Screenshot credit: Sean Vail

Modders can even go one step further than small additions; in 1998 the Valve Software corporation released the computer game Half-Life. Half-Life’s game engine was easily moddable and the community eventually created such comprehensive mods that the result splintered off into a separate game, known as Counterstrike, and eventually was sold as a retail game itself (Sotamaa, 2003). This active modding community can also alleviate demand for new features from the developers. We can see an example of this in the title “Space Engineers” in which there used to be only two options for thrusters in the game for players to build spacecraft with, the modding community reacted quickly to this void and added a variety of new thruster options to the game, as can be seen in Figure A.

Developers stand to gain quite a lot by building game-engines capable of supporting these user-generated additions, and it ultimately leads to a far more pleasing experience for the user when the game they purchase is continuously improved upon by the community long after the developers have stopped supporting it.


Pong [Image]. Retrieved November 2, 2014, from:


Scacchi, W. (2010). Computer game mods, modders, modding, and the mod scene. First Monday, 15(5). doi:10.5210/fm.v15i5.2965


Sotamaa, O. (2003). Computer game modding, intermediality and participatory culture. New Media, 1-5.


Getting LinkedIn to the Industry

A little over a decade ago networking with colleagues and potential employers was done directly for the most part. As part of our society’s transition into the digital era, we have digitized this process into what we call social networks. One of these networks in-particular has emerged as a professional networking tool that connects potential employees with prospective employers and gives the employee a chance to sell themselves via a digital profile. This is, of course, LinkedIn which launched in 2003 and serves as a professional network to over 259 million users as they last reported.

The basic functionality of LinkedIn is available to anyone, so making your profile standout among the others competing for your position is worth putting effort into. Researchers at the University of Brussels recently conducted a study, on the influences that social networks have on recruitment and selection procedures, in which they found that nearly 71% of employers use LinkedIn to find additional information on potential employees. Knowing how to maximize the positive influence your profile could have on your prospective employer could be a huge benefit if done properly.

So how do we make the most of our LinkedIn profiles? The first thing that should be done is completing the basics of the profile (i.e. your industry, current/past positions, education, profile picture, etc.), LinkedIn itself walks the user through this part, so there is no excuse to not have this completed. While filling out these details, your profile should be as detailed as possible, don’t be coy, show off your qualifications to your employer, your LinkedIn profile is your chance at marketing your skills and experience (Caers, 2010). Your profile may also serve as a indication of your personality to the employer as well; this is why you’ll want your profile picture to be a simple and professional head-shot that establishes the perception that you are professional.

Making the profile look good is half the battle, if you want to truly optimize your LinkedIn profile, making it visible will greatly increase its benefit. Part of this is growing your network out via friends, past and present coworkers, or other people you know on LinkedIn. Connecting to all these people makes you more relevant in their search results, a good position to be in if they ever need your advertised skills. In terms of visibility, having a fully completed profile helps us out once again, by having all this detailed information completed; search engines are more likely to pick out keywords relevant to your area of expertise in your profile and far more likely to populate the search results, of a search query by a recruiter possibly, with your profile as one of the results.

So there you have it, building an effective LinkedIn profile is worth the relatively small time investment, getting your skills and experience out onto the internet for employers to see could connect you with many opportunities that could have otherwise eluded you.



Caers, R., & Castelyns, V. (2010). LinkedIn and Facebook in Belgium: the influences and biases of social network

sites in recruitment and selection procedures. Social Science Computer Review, 0894439310386567.

LinkedIn Members [Image]. Retrieved October 26, 2014, from:

Networking [Image]. Retrieved October 26, 2014, from:


Seiden, J. (2013, July 17). How to Create an Effective LinkedIn Profile. Retrieved October 19, 2014.



Another task bites the dust

As was outlined in earlier entries; the sprint backlog contains requirements. Requirements could mean expected outcomes of pressing a button, what the GUI should look like, or multitude of other things. The requirements themselves, cannot always be converted straight into functioning features, this is why we create task lists.

Task lists are essentially the way agile teams take a big idea, such as a feature, and break it down into smaller and more specific detailed tasks. Interestingly this breakdown can be done in a recursive fashion, meaning that if the team breaks down a task and finds that it is still too broad of an idea to translate into code, they can do it again and again until it is. All that matters is that, however many tasks you have, completing them eventually results in the original user story or requirement. Kelly Waters, author of the book All About Agile and esteemed member of the agile community in the UK, notes that it is important for tasks to be measurable, such that the task is a description of what will be delivered versus what will be done.

Now we have a list of tasks that need to be done, this is where we run into another would-be obstacle. When someone, say a programmer, checks off an item as done; what did he mean by that? This question may sound silly, however I assure you that it is very relevant. The word “done” can be interpreted by two individuals differently. Person A’s definition of done could entail things aside from implementation, like testing, whereas person B’s definition may not include such things. Therefore, it is important to creating a definition of done (Waters, 2007), when creating tasks on the task list such that the team can feel confident that they are all on the same page when an item gets marked as done.

So how do we go about creating a definition of done? The tasks themselves, as stated earlier, should be descriptions of what will be delivered. So a good question to ask ourselves should be, can we ship it as a deliverable as is? This question brings up a couple more: Has the client approved it? Has it been tested? These questions could vary greatly depending on the organization in which this project is taking place (Waters, 2007), but the overall the definition of done should be comprehensive enough such that your team can feel confident that they will not have to waste time coming back to this feature in future and can move on to the next feature.


Agile Task Table [Image]. Retrieved October 12, 2014, from:

Checklist [Image]. Retrieved October 12, 2014, from:


Eberlein, A., & Leite, J. C. S. P. (2002, September). Agile requirements definition: A view from requirements

engineering. In Proceedings of the International Workshop on Time-Constrained Requirements Engineering (TCRE’02) (pp. 4-8)


Waters, K. (2007, April 8). Agile Principle 7: Done Means DONE! Retrieved October 12, 2014, from

The Sprint Retrospective: A Time For Critique And Praise

Thumbs-Up-and-DownI have already stressed numerous times already that Agile contains many mechanisms that stress the importance of flexibility and change. One of these mechanisms, the sprint retrospective, is worth looking into a little more deeply due to the positive impact it has upon the development processes.

In essence, the sprint retrospective is a time for the team to identify things from the previous sprint that are either less than ideal and need to be improved or that are good and should be done more often. A time for constructive critique and praise in order to improve the productivity and results of the next sprint. Chris Mann and Frank Maurer have done an extensive study on opinions regarding the Agile process as a whole and found that the sprint retrospective is generally given praise by developers that utilize the Agile methodology. However, Mann and Maurer found in their study that there is one critique that the developers have regarding the conciseness of the meeting: They often find that the client, scrum master, and project-manager tend to be under-prepared for the meeting and veer off the topic, which causes meetings to drag on. I feel that I must second this critique as someone who works in software testing. Meetings with developers and project managers tend to get sidetracked when the two go off on long tangents discussing possible features they can add to the software in future versions, I find it necessary to reel them back into the primary discussion topic from time to time, a relatively simple fix to the issue.

Something people new to agile tend to get confused about is what kind of topics should be discussed during the sprint retrospective. Allow me to clarify this for the reader; the retrospective is all about the details of the process itself that need to be improved rather than features and bugs, those topics are reserved for the preceding the sprint review. A good example of such a topic is found in Mann and Maurer’s study; during one of the retrospective meetings the clients and developers agreed that they would no longer do extended sprints when they found that they needed more time to complete a task. They’re rationale for this was that the developers would end up not knowing what they needed to do and they agreed to instead either trim down the work or move it to the next sprint.

Once again we can see that agile gives developers a way to refine the process by which they create quality software and optimize their productivity. Critique and praise of the processes being used is important, not all teams function identically and it is therefore important to be critical of what processes are working in any given project. The retrospective is the time for teams to facilitate this critique at the end of each meeting.



Mahnic, V. (2011). A Case Study on Agile Estimating and Planning using Scrum. Electronics and Electrical

Engineering, 5(111), 123-128. Retrieved September 29, 2014, from


Mann, C., & Maurer, F. (2005). A Case Study on the Impact of Scrum on Overtime and Customer Satisfaction. Agile

Conference, 2005. Proceedings, 70-79. Retrieved September 28, 2014, from

Retrospective Table [Image]. (2013). Retrieved Sepetember 28, 2014,


Thumbs Up & Down [Image]. (2013). Retrieved Sepetember 28, 2014, from: